Re: ditto blocks on ZFS

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Martin <m_btrfs@ml1.co.uk>, linux-btrfs@vger.kernel.org
Subject: Re: ditto blocks on ZFS
Date: Thu, 22 May 2014 07:10:46 -0400	[thread overview]
Message-ID: <537DDB36.8070104@gmail.com> (raw)
In-Reply-To: <lljbfo$6vm$1@ger.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

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 majordomo@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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]