On Fri, Jul 20, 2012 at 04:38:59PM -0600, Wendy Cheng wrote: > On Fri, Jul 20, 2012 at 12:36 PM, Goffredo Baroncelli > <kreij...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
