User: Password:
|
|
Subscribe / Log in / New account

The two sides of reflink()

The two sides of reflink()

Posted May 6, 2009 14:25 UTC (Wed) by wilreichert (subscriber, #17680)
In reply to: The two sides of reflink() by martinfick
Parent article: The two sides of reflink()

How is this different from deduplication at the filesystem level?


(Log in to post comments)

The two sides of reflink()

Posted May 6, 2009 15:09 UTC (Wed) by dlang (subscriber, #313) [Link]

it sounds like it's one mechanism to use for deduplication.

The two sides of reflink()

Posted May 6, 2009 17:03 UTC (Wed) by elanthis (guest, #6227) [Link]

To the filesystem, a cp isn't a copy -- it's one process reading from one file and writing to another. Figuring out that that is supposed to be a copy is very non-trivial and expensive, especially when taking into account metadata operations which aren't part of the regular file stream. I'm not sure it's even plausible to do without a second pass, e.g. a "combine files" daemon, which would still just be extra overhead.

If on the other hand cp says "this is a copy" to the kernel then the filesystem can just do the right thing. Of course, other applications will need to be modified to take advantage of the new feature, but such is the truth of most progress.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds