Re: btrfs raid1 metadata, single data

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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

On 2015-08-07 06:40, Mike Fleetwood wrote:
> On 7 August 2015 at 10:47, Sjoerd <sjoerd@sjomar.eu> wrote:
>> While we're at it: any idea why the default for SSD's is single for meta data
>> as described on the wiki?
>> (https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Filesystem_creation)
>>
>> I was looking for an answer why my SSD just had single metadata, while I
>> expected it to be DUP and stumbled on this wiki article. Can't find a reason
>> for why a SSD would be different?
>>
>> Cheers,
>> Sjoerd
>
> I would assume that it is because some SSD drives controllers
> deduplicate by default [1].  The developers probably think that when
> it comes to your data the truth, no mater how ugly, is preferable to a
> false sense of security.  (Btrfs thinking it has 2 copies of metadata
> when the SSD drive only actually has stored 1 copy).
>
> [1] How SSDs can hose your data
> http://www.zdnet.com/article/how-ssds-can-hose-your-data/
> "Researchers found that at least 1 Sandforce SSD controller - the
> SF1200 - does block-level deduplication by default. Which can be a
> problem.
>
> Many file systems - NTFS, most Unix/Linux FSs, ZFS are some - write
> critical metadata to multiple blocks in case one copy gets corrupted.
> But what if, unbeknownst to you, your SSD de-duplicates that block,
> leaving your file system with only 1 copy? "
>
And of course there's the counter-argument from the manufacturers that 
do this:
"But we use ECC, so only having one copy of the data is still safe!"
which is obviously something from their marketing department and not the 
people who actually understand how this works, most SSD's only do SECDED 
(Single error correction, double error detection) ECC, which is very 
much insufficient if it's MLC flash, as losing a single cell causes 
multiple bits to go bad.

The other reason, which applies to all SSD's, is that the oisk layout is 
very different from how things are actually stored on the flash chips 
themselves, and most firmware will group writes temporally, likely 
causing both copies of the metadata to be put on the same erase block, 
which in turn means that the duplication provides essentially zero 
protection beyond having a single copy.



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