pwm

You could use the Dynamix File Integrity plugin.

But how much do you value the time it takes to get the box to regularly run SMART and mail out any problem notifications?

There are two relevant things to test here: 1) Can this machine boot any other USB-booting OS - lots of repair software, non-install Linux etc available that can be used to test. 2) Can the unRAID drive be used to boot any other computer. The link you posted indicates that some people failed because the drive itself wasn't properly configured. And some failed because of brand/model of drive. And some failed because the BIOS menu system was too complicated. And some failed because of other USB equipment connected at the same time (such as keyboard/mouse).

No use waiting very long. The message is common if there is some troubles with the hardware (memory modules, PCI cards, ...) or the BIOS can't locate any disk etc. It might be an idea to try to reset the BIOS settings and see if that makes a change - but that requires that you have kept track of any important settings that you want/need to restore.

The parity checking tries to cram out all read capacity the drives can manage. So anything else you do will result in one or more disks having to constantly seek between the parity read position and the read/write position of whatever you are doing. If your writes then also happens to be to the same disk(s) that Plex needs, then you suddenly have three concurrent jobs fighting for the attention of the same drive. Please head over to the feature requests subforum and wish for manual or automatic pause of parity checking when other tasks needs the disk capacity.

What can be seen here is that most of the time, the machine was managing 100 MB/s or more. It was actually the larger disks that ended up with the lowest transfer rates at the end. But for most of your storage capacity, you can almost fill the bandwidth of a gbit network interface (about 110 MB/s) when reading a single stream from a disk.

Right now, I'm seeing ridiculously slow posting. Often 7-15 seconds to submit new posts. But not slow to loading pages.

I have never done any refills. That might be why I have never suffered any significant slowdowns for directory-tree reads as done by unRAID user shares. All my RFS (unRAID or other Linux machines) have been used for basically archival storage. Work disks have either used ext2/3/4 or Btrfs.

RFS doesn't have preallocated inodes. The advantage is that you can add a ridiculous number of small files. But the disadvantage is that the inodes gets spread all over the surface. And the more add/delete that are performed, the more fragmented the inodes becomes. And as the disks becomes larger, we can store more files on them - so using more inodes that can be fragmented over more disk blocks. So RFS is a very bad FS to use for new disks. But an archival disk that has just been filled with files can work very well without any urgent need to move the data.

I have not seen any such behavior. I have a number of rather full RFS disks, but with 100% static content. I can read out data from them at full gbit network speed. I will wait with replacing the FS until it's time to replace all drives. Are you talking about user shares that doesn't have minimum free space configured? Because I have never seen any full RFS disk with static content be slow at reporting free space. It sounds more like you are talking about a RFS that has been allowed to create a very fragmented inode "table", in which case it takes lots of disk seeks to read in the directory tree and inode contents to present the merged user share content. But I haven't seen these issues for one-time fill-up of archival data to RFS. I have only seen it when data has been added/removed for an almost full RFS volume.

ReiserFS is notorious for becoming slow to handle new updates when close to full. If filling them once and then just reading out the data, then it's ok to cram them full. But not if you want to modify some of the content - then ResierFS spends huge amounts of time trying to optimize the internal structures. But strictly speaking - for most FS you should think twice about filling over maybe 95%. If a newer version of the file system is released that adds new functionality or optimizations, then the meta-data may need to grow. XFS for example have introduced support for checksumming of meta-data. And it isn't impossible that they may want to continue and see if they can introduce checksumming for file data too. Leaving a bit of free space also makes it easier to change to a different file system that might require a different amount of metadata. Easy but slow - you need to move all data to other disks. In the array or outside of the array. Then reformat. Then restore the content. Then repeat for the other data drives. Easiest is to do this when upgrading to larger drives. One new 8 TB disk can handle the content of two older 4 TB disks. So much less copying around of data.

Some TRIM performs like zeroing - so a RAID machine can recompute the parity as if the data was zeroed (which means all disks needs to be online or the original contents needs to be read before TRIM is sent). But the parity drive can never make use of TRIM, since it doesn't have a file system with unused portions to TRIM. This means that a RAID should be designed in a way where TRIM isn't needed for it to work well. So the way to use SSD in a RAID is to have overprovisioning. Either enterprise disks that is delivered with a significantly large, hidden, amount of overprovisioning. Or high-end customer drives that can be configured so parts of the user space of the drive is reserved for overprovisioning. But note that large HDD (especially helium-filled models) are quite efficient when used for a home media server, since you can often manage with a single disk spinning. So best is a tiered solution where data files and audio is stored on SSD and movies and TV-series are stored on big HDD. This is what I am currently doing. So mirrored SSD for often used data. Mirrored 2.5" HDD for next tier of data. And then multi-disk RAID with dual-parity for bulk storage. And backup to drives that are allowed to spin down between each backup run, with new data "rolling" over multiple drives so backup drives doesn't need to spin up every night.

Don't fill the system using a cache drive. It isn't faster to first copy to the cache drive, then move the data to the array then fill more to the cache. Turn on turbo write and you may get transfer speeds close to the speed of the gbit network interface. It is when unRAID uses read/modify/write for parity (which means it's enough to have just one data disk + parity spinning) that you get really slow write speeds because the drives needs to do a read and a write for every block saved to the array.

And this is even possible on unRAID itself by downloading to a data disk and extracting to the flash. So not storing the download in RAM and not having two extracted copies on the flash. Then it's possible to reboot.

If you make a rebuild, then unRAID fills the disk with recomputed data. But this requires that all the other drives produces valid data - if one of the disks reads out incorrect data for a sector, then one recomputed sector will contain wrong data that gets written to the rebuilt disk. If you never did any rebuild, but copied the data from the old disks to some scratch storage. And then replaced the disk and copied the data back, then you only end up with broken content if that scratch storage produced errors - or if the machine goofed because of memory issues or similar. So it's only if disk 18 was involved in recreating contents on disk 5, 7 and 13 that read errors on disk 18 would introduce errors to content on disk 5, 7 and 13.

Good post. It's easy to believe that the maintainers of the bigger Linux distributions have companies and sponsorship deals to make sure they can live a decent live while spending their time on their pet projects.

The only real downside to XFS is that they don't have data checksums. For the old drives, you could compute the checksum for each and every file and compare with the checksum for the disks in the array. Or just copy the data from the old disks on-top-of the data in the array, which will overwrite both correct and broken files, but will reduce the number of broken files you have. The good news is that for media files, it often doesn't matter so much if you have a bit of corruption - many video file formats are designed to be quite robust. So you get one or more broken video frames and then the video playback can return to play good data again.

Looks like a possible cable issue or power glitch where you got a transfer error between machine and disk. It decided to try a slow PIO transfer instead of the normal fast UDMA. Then it later reported to use UDMA/133 again. Keep an eye on this to see if it happens again.

As noted in your other thread, you need to program back an address for the card.

When you have too little space on the drive to do an over-the-air update, then you can shutdown the machine and insert the original drive in a Windows machine and install the newer version that way - same as when installing unRAID the first time. Just remember that whenever you do some fancy work, you should make sure that you make a backup copy of the configuration directory of the thumb drive so you don't accidentally overwrite it.

UDMA CRC is normally a problem with the cable.

No stranger than having Plex decide that it needs to transcode.

That's basically "the manufacturer don't think they need to do a warranty replacement of the drive." The SMART data contains much more information than that - for example lots of nice counters. Some of which unRAID checks as default, and some that might be meaningful to add in yourself. But since you haven't posted full diagnostics information, I have no idea if they are problematic values in the SMART data.

No. With cable issues you would get UDMA CRC errors and the machine would either manage to read out correct data by retrying the read - or would try to reset the link to the drive if it isn't possible to communicate with the drive. You only posted the server log but you should take a close look at the SMART data for your disks.

Have you set up notifications for the machine?