pwm

Problems with newly booted machines with lack of entropy for pseudo-random data, resulting in some part of the program hanging waiting for /dev/random to produce enough data?

I have managed quite well to store DVD/BD ISO files to Reiserfs and fill to 99% on older 4 TB volumes. But the special case is that I have only accumulated new files - never erased any existing files. And the total number of files are very low since the ISO images are on average 8 GB for the DVD rips and 44 GB for the BD rips. I also have a few, very small, meta-data files for each rip, but still ends up with a multi-GB average file size. In the general case, 99% is much too high filling level for ReiserFS. RFS starts to spend significant time rebalancing the internal tree structures much earlier, so 90% should be a better general figure - especially if there are important real-time requirements. But just to reiterate: all file systems gets affected when nearly full. It's just a question of how early you start to see significant effects for a specific set of files. Some file systems suffers because the free-space management breaks down. Some, because the FS tries to balance the internal structures. If it's balancing operations that slows down, then it can work quite well to fill the FS to a high level since the rest of the file system life will be reads. But if it's the free-space management that breaks down, then even future reads are likely to become severely affected.

Different file systems behaves differently when nearly full. But in general, you should never fill a file system almost full unless it's an archival disk where you only write to it once and then leave it in that state with no more writes. An almost full disk has a very hard problem figuring out what free space to use for new writes with tends to result in very severe fragmentation. So you can get huge slowdowns accessing some of the files if you make use of all space for a partition. Note that some file systems can allocate a bit of extra space, speculatively, for some files just to allow them to be extended without additional fragments. If you then fill the disk full, then the file system may have to go back and try to get back these speculative allocations and take a huge number of small blocks to store the last files written.

I have had issues where I close notifications and they instantly comes back. And if I close all, they instantly comes back. If I look on the flash drive, all are closed - the "unread" directory is empty and the notifications that comes back are in the "archive" directory. If I navigate to a different page on the unRAID web interface then the problem seems to go away. So it seems like the web interface may sometimes cache incorrect data.

WiFi is quite often fast enough, which is why lots of media players can be run over WiFi. And it allows a backup server to be placed in a room that doesn't have wired networking. The important thing is that different users have different usage cases and different needs.

Windows doesn't check if the USB is bootable - just if it (potentially after a file system repair) seems to be readable. So as @johnnie.black recommends - regenerate the flash drive or possibly replace it. But take care to make a copy of the configuration first.

One more wanting ISCSI.

For a drive you just fill you could go really, really full with most file systems. But note that a file system using copy-on-write (CoW) like Btrfs needs additional disk space even for updating file access times. And you might want to store additional information later - possibly checksum information for the files. Or you might later want to switch to a different file system - different file systems requires different amounts of hidden storage for book keeping. Anyway - having 0.5% free on every drive represents just 0.5% of the purchase cost of the drives and 0.5% of the electricity to run the drive. So there isn't any strong economic incentive to push the limit. Especially since fragmentation issues can become a really big issue way earlier than this, depending on usage pattern.

You want to boot from the USB - that doesn't give any wear and allows all system state to be backed up etc by duplicating the flash content. But the system could make a mirror copy to a cache drive and only verify that the USB stays connected with the license key. And then have the system accumulate a grace timer so if the USB breaks after x days uptime, then you may get a failure mail and a number of days to react and arrange a replacement. Even nicer would be if the replacement drive can be completely empty - just connect an empty drive and click on a menu choice to have the unRAID machine report to lime with the new serial number. Then copy back the full information from the SSD and write down the new key file. So the only user interaction would be to unplug the broken drive, insert an empty drive and click "register USB replacement drive".