For reference, we were using QNAP TS-639 Pro with six WD20EADS disks.
After about half a year of use, the web-interface was running slower, so that we needed to wait for several minutes to obtain the list of the disks. Gradually, we noted that the array performance decreased significantly.
It seemed obvious to assume that one of the member disks has been dropped from the array and a RAID5 was working in the degraded mode. However, all the member disks were marked as GOOD in the web-interface.
It was suspicious that LEDs on the disk bays indicating the state and activity of the disks were blinking unevenly. Logically, for RAID5 one should expect almost symmetric load on the disks, but in fact, one of the disk LED was blinking much more frequently.
Once we had run the bad blocks check on this disk through the web-interface, the disk dropped from the array in less than half an hour and its bay LED turned red. At this point, the web-interface began to work properly again. The disk taken from …
It is known that filesystems that you will probably use on Storage
Spaces, namely NTFS and ReFS, support TRIM. We have no information
about FAT but it is unlikely that someone will use FAT in conjunction with
Storage Spaces. So, if you delete a file on a volume located on a virtual Storage Spaces
disk, the filesystem driver sends a TRIM command to the Storage Spaces driver.
The latter uses the same mechanism as TRIM uses in order to free slabs, i.e. to return slabs that are marked as unused by the filesystem to
the pool of free slabs. Returning slabs to the pool of free slabs will take
place if: a file being deleted fully occupies one or several slabs; a file being deleted is a single file in the slab meaning that after its deletion this slab would contain no data at all. Once a slab is withdrawn back to the pool of free slabs, it is
impossible to easily identify the slab - what volume it belonged to, what location
it had in the volume. Therefore, regular data recovery from the filesystem…