Re: Recommended filesystem for RAID 6

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

 



On Sat, Aug 22, 2020 at 1:25 AM Peter Grandi <pg@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> >> [...] Note that it IS a shingled drive, so fine for backup,
> >> much less so for anything else.
>
> It is fine for backup especially if used as a tape that is say
> divided into partitions and backup is done using 'dd' (but
> careful if using Btrfs) or 'tar' or similar. If using 'rsync' or
> similar those still write a lot of inodes and often small files
> if they are present in the source.
>
> >> I'm not sure whether btrfs would be a good choice or not ...
>
> > [...] btrfs did NOT play well with raid 5/6. It may be old
> > info, but:
> > https://superuser.com/questions/1131701/btrfs-over-mdadm-raid6
>
> That seems based on some misunderstanding: native Btrfs 5/6 has
> some "limitations", like most of its volume management, but
> running over MS RAID 5/6 is much the same as running on top of a
> single disk, so fine. MD RAID 5/6 takes care of redundancy so
> there is no need to have metadata in 'dup' mode.

True but dup metadata is a small cost to have self-healing file system
metadata. While read errors mean md will reconstruct from parity, and
Btrfs would be none the wiser, Btrfs is more sensitive to certain
kinds of metadata loss than other file systems.

Where dup is pointless is the case of deduplication by SSDs with
concurrent writes, and dup metadata uses concurrent writes - i.e. it's
not going to delay writing one of the copies which is what it'd take
to thwart common internal SSD optimizations. Even those that don't
dedup, concurrent writes end up on the same erase block. And if
there's a hardware failure, it tends to affect an entire erase block.

> Using RAID 5/6 with SMR drives can result in pretty huge delays
> (IIRC a previous poster has given some relevant URL) on writing
> or on rebuilding, as the "chunk" size is very likely not to be
> very congruent with the SMT zones.

At least hmzoned Btrfs will disable features considered incompatible
with SMR: raid56, nodatacow (overwrites), and fallocate which also
implies overwrites.

-- 
Chris Murphy



[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux