Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Btrfs currently lacks fsck, risking corruption if there's a power failure. To what extent, if at all, would creating a btrfs filesystem within a RAID5 array mitigate this?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

AFAIK it would make no difference.

RAID is an abstraction layer for physical disks, it makes multiple disks/partitions look like a single "block device" to the file system. Some RAID levels (including RAID1 and RAID5) can handle physical disk failures transparently: Remove a disk, and for the file system it looks like nothing has changed.

But the file system works on top of the "block device" abstraction layer. Using a RAID5 as the block device helps dealing with physical disk failures, but it does nothing for the file system itself, so the risk of file system corruption remains the same.

RAID blocks (mdadm 'chunks' with default size 64kB) differ from file system blocks (ext4 default size 4kB) and are designed to detect a different kind of corruption.

RAID5 works by splitting data from the file system and writing one chunk to each of N-1 disks and a checksum to the Nth disk. RAID5 is designed to detect "corrupt data" in the sense of bad sectors, in which case the original can be restored from the checksum and the N-2 remaining good chunks.

But if the FS updates the metadata and dies before it has time to write the files, the file system may be corrupt without the RAID being any wiser: What was written to disk is the same as what is read back from disk, as evidenced by the checksums matching. The RAID cannot know that important pieces are missing from the perspective of a higher level application.

See this paper (pdf) for examples of corruption that goes undetected by RAID. In the context of file system corruption, I guess "torn writes" (only some of the data that were supposed to be written actually are) is particularly relevant.

share|improve this answer
    
That was my initial thought too, but RAID5 will also compensate for bad blocks not just bad disks, and if an area is unclean area because of a power-off during a write, it should be restored during recovery. From the wiki: "When you have multiple copies of data, you can use data scrubbing to actively scan for corrupt data and clean up the corruption by replacing the corrupt data with correct data from a surviving copy." The question is how this recovery would interact with the filesystem journaling and the kind of corruption that could occur. –  Mark Dayel Apr 28 '11 at 21:39
1  
@Mark See my updated answer. In short, the RAID error recovery is designed for bad physical sectors and can recover if what is read back from disk is different from what was written. But no RAID level knows about file systems and journaling and the kind of corruption that can happen there - RAID can't help if what was written was wrong or incomplete in the first place. –  j-g-faustus Apr 28 '11 at 22:20

Linux software RAID5 would actually make the power failure situation worse - much worse - for the reason already addressed. Even on ext3/4, replaying the journal after a power failure will not fix the RAID5 inconsistency which invariably arises due to the software RAID not having a nonvolatile "journal" of its own to play back. The result is corruption of not only user data but also filesystem data in the event of a power failure during a write operation. Dedicated hardware RAID controllers with battery-backed cache do not suffer from this, but that still doesn't make up for the lack of being able to run fsck on btrfs.

If you care about your data integrity then do not run btrfs without an fsck tool, and do not run RAID5 (or any parity RAID level) without nonvolatile cache or a UPS.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.