Re: [PATCH] Btrfs-progs: detect if the disk we are formatting is a ssd V2

[Josef Bacik <jbacik@fusionio.com>]

On Fri, Jul 20, 2012 at 04:38:59PM -0600, Wendy Cheng wrote:
> On Fri, Jul 20, 2012 at 12:36 PM, Goffredo Baroncelli
> <kreijack@libero.it> wrote:
> > On 07/20/2012 09:15 PM, Josef Bacik wrote:
> >> SSD's do not gain anything by having metadata DUP turned on.  The underlying
> >> file system that is a part of all SSD's could easily map duplicate metadat
> >
> > If I understood correctly you are stating that because an SSD *might*
> > "eliminates the benefit of duplicating the metadata"  mkfs.btrfs *must*
> > remove _silently_ this behaviour on all SSD ?
> >
> > To me it seems too strong; or almost it should be documented in the man
> > page and/or issuing a warning during the format process.
> 
> I'll have to second this .. this is my first time looking into btrfs -
> do feel free to correct me if my reading is not correct.
> 
> Based on https://btrfs.wiki.kernel.org/index.php/Glossary, I assume
> the DUP is a flag to ask for meta-data duplication within the same
> device entity. This implies whenever an FS (meta-data) block is
> updated, the duplicated FS block needs to be modified as well (true
> ?). So within a conventional SSD firmware implementation, it is true
> that both FS blocks could end up in the same SSD block that get erased
> and re-allocated together. Similar thing could happen with disks that
> have embedded de-duplication feature turned on.
> 
> However, this should have been a task for the admin (or whoever types
> this mkfs command). It is not a filesystem's job to assume how the
> firmware works and silently ignore the DUP request, *unless* there is
> a standard specification clearly describes linux devices that claim to
> be not "rotational" should behave this way.
> 

The admin can still use -m dup if he wants the added possiblity of protection,
this just makes the default not dup.  Thanks,

Josef