Posts

Showing posts with the label write hole

Write speed in Storage Spaces

People note that write speed on mirror or parity volumes in Storage Spaces is slower as compared to a traditional RAID1 or RAID5. Indeed, parity and mirror volumes of Storage Spaces are not identical to a regular RAID1 or RAID5 in terms of maintenance costs. The ReFS driver that manages the filesystem structure on the Storage Spaces volumes must also calculate checksums over data to avoid the write hole issue.

Can I has a write hole?..

Image
in a RAID 6? Actually, yes. All it takes is large number of disks in array, intensive I/O, a power failure, and some bad luck.

"Write hole" in filesystems

Unsurprisingly, filesystems are also suspectible to damage when the power failure occurs during write. The most simple example is the file being deleted. If the clusters are deallocated (marked free) first, and then a power failure occurs before the file record is removed, then we got a file having its data stored in free clusters on the disk. If a new file is subsequently created and uses the same cluster, the cross-link siutation occurs, potentialy leading to data loss. There are several ways around this problem. Careful write ordering . The sequence of operations can be ordered in such a way that the damage due to the incomplete write is predictable, easy to repair, and confined to a single file. This is the cheapest option. It does not require any change to the on-disk structures if you want to implement it on the existing filesystem. Multisector transfer protections (used e.g. in NTFS). If several sectors are to be written out as a group, each sector in a group stores a sp...

Write hole in RAID 1

Actually, RAID 1 has the same write hole  problem as RAID 5 does. Should the power fail after one disk is updated, but the other is not yet updated, and then the first disk fails, there will be data corruption. As usual, scheduled synchronizations of the array reduce probability of this effect causing any practical trouble.