From: Sjoerd <sjoerd@sjomar.eu>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs raid1 metadata, single data
Date: Fri, 07 Aug 2015 22:07:44 +0200 [thread overview]
Message-ID: <3420345.ZbC7yzDDA0@hoefnix> (raw)
In-Reply-To: <CAMU1PDjvc-rBFONt9cxyUatFsKHPibid1F--swBAv6MhuVD3FQ@mail.gmail.com>
On Friday 07 August 2015 11:40:24 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? "
>
> Thanks,
> Mike
Thanks for the explanation Mike...sounds plausible..
next prev parent reply other threads:[~2015-08-07 20:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 8:49 btrfs raid1 metadata, single data Robert Krig
2015-08-07 9:18 ` Russell Coker
2015-08-07 9:47 ` Sjoerd
2015-08-07 10:40 ` Mike Fleetwood
2015-08-07 11:38 ` Austin S Hemmelgarn
2015-08-07 20:07 ` Sjoerd [this message]
2015-08-07 11:13 ` Duncan
2015-08-07 10:26 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3420345.ZbC7yzDDA0@hoefnix \
--to=sjoerd@sjomar.eu \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.