Re: btrfs raid1 metadata, single data

[Austin S Hemmelgarn]

On 2015-08-07 06:40, Mike Fleetwood wrote:

On 7 August 2015 at 10:47, Sjoerd <sjo...@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.

smime.p7s
Description: S/MIME Cryptographic Signature