NLS

I am not. And this is getting tiresome.

Yeah good for you.

I prefer to wait for the release this time around.

I hope for detailed guides with the new release. (which should probably NOT be named 6.12)

I am here just to follow the thread - my only post in this thread will probably be this one. I wanted ZFS for a long time, although just to be an "option", a "feature of the system" (as not having ZFS actually has left unRAID out of many discussions of NAS systems - which is unfair to unRAID and I am sure Tom is aware of this happening). The only thing I really care about as a long time user and customer is - ...deduplication (because by the nature of the data I keep - emulation data - I do have many duplicates), - ...transparent compression-decompression officially supported (not "under-the-hood" tricks), - ...have a "self-healing" FS on my data disks, not just the cache, and all these WITHOUT losing - ...the ability to have various size disks, - ...able to replace one by one disk with larger size, - ...easy recovery even when I go OVER the limits of RAID4 that unRAID practically is (i.e. I want to be able to recover the files from the healthy disks even if two disks die with a single parity). Can I have those things when ZFS is incorporated to unRAID? (or some other way?) I don't really care if the underlying FS is ZFS or whateverFS, as long as I get those and not lose the current benefits of unRAID. Keep evolving!

good to see the cogs moving

Thank you! Very interesting. So it is probably a viable solution to get more space. Hope it gets evaluated by UNRAID team and gets actual GUI support.

I was actually going to "attack" @lackingdev that in his first post questioned the people that actually maintain the "well being" of UNRAID plugin crowd. BUT he is right. Seems that @jonp actually did make an update 16 days ago supposedly FOR 6.11. Maybe the plugin need to be re-evaluated? And why didn't the author of this plugin himself comment?

OK will do what I ask in the next update it "hits" the container. I don't quite understood the reasoning behind not letting the container run if an update fails. I am talking if an update DOWNLOAD fails (then the "old" version is untouched and working) - then why not let it just run? If a download is broken and there is no mechanism to just (re)try to finish the download, then don't extract (there is a test for gz to check if the archive is ok), so it won't break the existing install. In my case the download was there (and downloaded by the system, not by me) and it was complete. But for some reason the update system never used it and reported the error. Anyway, I guess we'll see what happens next time.

Yes I restarted the container several times. Always same message (and no GUI coming up). In fact, this container (and several others) are usually stopped and I only start them when I need them. When I found that .16 was already there, I extracted it manually over the other files and this updated it. No errors in the extraction. Next container restart it verified I am running latest version, so the container worked fine. BTW... keeping the container offline because it (thought it) failed to update to latest version, is bad practice by itself. Its should allow the container to run, even if it failed to update it.

But I already showed you my folder contents and .16.tar.gz was in there... I didn't put it there. The system did. I used that one to extract (so it wasn't a broken download). So the report that it fails to download was wrong. (is there no check that it is already downloaded?)

After the last update (or last few? Not sure), the web GUI changed (nicer icons) but I have this issue (broken icons): ...any ideas?

like that EDIT: Note that I used to use this container. It did work in the past. I didn't touch it, except possible updates. EDIT #2: What if I manually extract 0.18.16 and drop it over the existing? EDIT #3: I did what I say above and it worked. Wonder what will happen in next update though. "Something went wrong" is not very informative, as it seems to BE able to download .16, but doesn't extract it. Could it be a security issue?

I have an issue with UnMiNeD... It reports: ---Version Check--- ---Version missmatch, installed v0.18.14 0.18.16, downloading and installing latest v0.18.16...--- ---Something went wrong, can't download uNmINeD-GUI, putting container in sleep mode--- ...and doesn't work. I guess it needs an update?

Yes I know. Problem is how we fight it from within UNRAID. A functionality to ignore brief spikes before reporting... EDIT: Found this and will try the solution proposed...

So I got a new M.2 to replace my previous cache and I noticed that from time to time it just (at idle) "spike" to exactly 84 degrees celcius. But this happens briefly and then it is back to its real idle temp of around 36 degrees. As a result, I get repeated pop-ups and even repeated email reports. Now I can raise the warning level for this disk to be 85 degrees (as 85 is not-perfect-but-survivable for an IC) and be done with it, but is there any other way to resolve this? Like not reporting anything unless it remains for a set time? Help?

No I haven't left it on, on any Android devices. Only two Windows devices (also probably on server's own desktop). A reboot solved it, but still, rebooting for such a thing a production server (esp. with the other issue of huge time-outs during boot for devices with unavailable DNS), is not the best...

So I clicked to see the log (no real reason, nothing seemed out of the ordinary, just clicked it)... And I keep having this in repeat: Nov 24 23:05:33 <my server> nginx: 2022/11/24 23:05:33 [crit] 10373#10373: ngx_slab_alloc() failed: no memory Nov 24 23:05:33 <my server> nginx: 2022/11/24 23:05:33 [error] 10373#10373: shpool alloc failed Nov 24 23:05:33 <my server> nginx: 2022/11/24 23:05:33 [error] 10373#10373: nchan: Out of shared memory while allocating message of size 8539. Increase nchan_max_reserved_memory. Nov 24 23:05:33 <my server> nginx: 2022/11/24 23:05:33 [error] 10373#10373: *1092948 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Nov 24 23:05:33 <my server> nginx: 2022/11/24 23:05:33 [error] 10373#10373: MEMSTORE:00: can't create shared message for channel /disks EVERY SINGLE SECOND! Any ideas? EDIT: Found this: from A YEAR AGO... I do leave dashboard tabs open all the time, both at home and on my work computer... Is this an issue? EDIT #2: And this FROM 4 YEARS AGO! I did have parity check, but it has finished and the entries keep stacking!

There is enough space. I will try. But before I try, is there a way to see real vs claimed size? (to see if I actually succeeded) EDIT: Found it.

I know that, but I don't know how to do it using MC. Also, I don't know what to do NOW that I already copied the files (and already using them). Can I re-shrink them? EDIT: Well, something happened (I also deleted "docker-old" that was the residue of the file copy I did originally, but I don't think this is where the size difference comes from)... and now it is at... 188GB used (probably less than what was on my old disk!). I still want to know if it is possible to shrink down "un-sparsed" VM disks.

OK, thanks (again).

I did, yet I still get an around 5 minute delay in the same place (as shown in my opening post).

I used Midnight Commander as pre-installed on the host machine concole. I am not sure of the parameters it uses when moving and not sure it explains the 120+ GB difference (I have just two VMs on my cache disk). If this is the issue, is it possible I can "re-sparse" the vdisks? On other news, some (but only some) containers presented issues after all, so I re-installed all of them and now it tries to delete the old docker folder (I just renamed it, because it takes WAY too much time to delete - so will delete later)...

I think this has happened before to me, back when I again replaced my cache - but I don't remember how it got resolved (itself?) and can't find any relevant thread. (back then it was from a 500GB SSD to a 500GB NVMe) I am scared if the solution back then was to re-install all my containers... I cannot remember though. So I moved from a 500GB cache drive to a 1TB cache drive. Process went fine (I actually did it my own way, which is just a bit different from the documented ways), which worked fine. My VMs work OK, my dockers too. Thing is, used space in my old 500GB cache, was 47%. So it should be LESS than 250GB of data, right? No new files were written on the cache and it is not from new system files either because I saw the space reported even before enabling VM and docker systems. Even the copy itself (from old to new cache) reported something around 350GB+? Indeed new cache is 39% and reports 388GB of data! (more than 100GB more than the old used space!) Note that I know that 47% (and less than 250GB used) of my old cache were for real, as I happened to use my empty cache space with big file copies that indeed exceeded 200GB (so I was for sure less than 300GB used). Both disks formatted by UNRAID with btrfs. I even scrubbed the new disk. What exactly happened? Is it some kind of deduplication that btrfs will do by itself? Some kind of compression? Something scheduled by filesystem itself? (and in that case can I force it?) Use of "inline" files or sparse files? (note that I use a docker FOLDER not a docker FILE - which means thousands of tiny files) Something else? Any ideas?