On 2014-05-21 19:05, Martin wrote: > Very good comment from Ashford. > > > Sorry, but I see no advantages from Russell's replies other than for a > "feel-good" factor or a dangerous false sense of security. At best, > there is a weak justification that "for metadata, again going from 2% to > 4% isn't going to be a great problem" (storage is cheap and fast). > > I thought an important idea behind btrfs was that we avoid by design in > the first place the very long and vulnerable RAID rebuild scenarios > suffered for block-level RAID... > > > On 21/05/14 03:51, Russell Coker wrote: >> Absolutely. Hopefully this discussion will inspire the developers to >> consider this an interesting technical challenge and a feature that >> is needed to beat ZFS. > > Sorry, but I think that is completely the wrong reasoning. ...Unless > that is you are some proprietary sales droid hyping features and big > numbers! :-P > > > Personally I'm not convinced we gain anything beyond what btrfs will > eventually offer in any case for the n-way raid or the raid-n Cauchy stuff. > > Also note that usually, data is wanted to be 100% reliable and > retrievable. Or if that fails, you go to your backups instead. Gambling > "proportions" and "importance" rather than *ensuring* fault/error > tolerance is a very human thing... ;-) > > > Sorry: > > Interesting idea but not convinced there's any advantage for disk/SSD > storage. > > > Regards, > Martin > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Another nice option in this case might be adding logic to make sure that there is some (considerable) offset between copies of metadata using the dup profile (all of the filesystems that I have actually looked at the low-level on-disk structures have had both copies of the System chunks right next to each other, right at the beginning of the disk, which of course mitigates the usefulness of storing two copies of them on disk). Adding an offset in those allocations would provide some better protection against some of the more common 'idiot' failure-modes (i.e. trying to use dd to write a disk image to a USB flash drive, and accidentally overwriting the first n GB of your first HDD instead). Ideally, once we have n-way replication, System chunks should default to one copy per device for multi-device filesystems.
smime.p7s
Description: S/MIME Cryptographic Signature
