Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] On Btrfs raid and odd-count disks



On 4/11/2013 9:28 AM, Derek Atkins wrote:
> The reason I'm looking at a filesystem here is that the WAY writes occur
> can affect the write-holes you get in RAID5 and RAID6.  For example, ZFS
> does not overwrite the existing block, it will write to a new block and
> then after the write succeeds will it change the block-pointer.

COW does not prevent write holes.

ZFS prevents write holes by enforcing atomicity of all writes to
storage. It does this by controlling all of the I/O caching involved in
the write process from system RAM down to the write acceleration cache
on the disks themselves. ZFS updates the file system only after all
cache points have confirmed being flushed.

If any of these points lie about their status then write holes can
appear under power fault conditions. The RAID level does not matter. If
the hardware does not provide for the required write atomicity then you
can suffer write holes under power fault conditions.

Both ZFS and Btrfs provide facilities for automatically "erasing" write
holes. The process is called "scrubbing". The scrubbing process walks
through the entire file system tree, recalculates all file and metadata
checksums, and compares them to the stored checksums. Errors are
repaired using replica data. Oracle's documentation recommends a weekly
scrubbing schedule for consumer-grade disks and a monthly scrubbing
schedule for server-grade disks.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org