Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
The two sides of reflink()
Posted May 5, 2009 23:31 UTC (Tue) by martinfick (subscriber, #4455)
Posted May 6, 2009 0:05 UTC (Wed) by adj (subscriber, #7401)
Posted May 6, 2009 0:09 UTC (Wed) by clugstj (subscriber, #4020)
Posted May 6, 2009 0:14 UTC (Wed) by martinfick (subscriber, #4455)
Posted May 6, 2009 0:49 UTC (Wed) by JoeBuck (subscriber, #2330)
Posted May 6, 2009 5:59 UTC (Wed) by tialaramex (subscriber, #21167)
It also contains per-inode flags, so that implementations can be warned that they're missing a feature needed to read or update a particular file, in this case the implementation should fail open() for that file.
Of course poor quality implementations from third parties may be missing some or all of these checks. Fortunately the worst implementation I'm aware of as of this moment is read-only, so any problems only occur when reading files with that implementation and if/when they reboot into Linux everything is fine again.
Posted May 6, 2009 19:31 UTC (Wed) by clugstj (subscriber, #4020)
a reflink would be a new type of inode
Posted May 6, 2009 3:00 UTC (Wed) by xoddam (subscriber, #2322)
You could also specify flags in the superblock as others have suggested, so as to prevent a filesystem with reflinks from being mounted at all by a kernel which does not support them.
Posted May 6, 2009 8:55 UTC (Wed) by epa (subscriber, #39769)
Posted May 6, 2009 9:46 UTC (Wed) by xoddam (subscriber, #2322)
Posted May 6, 2009 12:24 UTC (Wed) by corbet (editor, #1)
Posted May 6, 2009 16:07 UTC (Wed) by masoncl (subscriber, #47138)
The two files can be changed independently without affecting each other. One could be deleted, truncated, expanded, chmoded, have new acls set, etc.
The actual block sharing is just an implementation detail...it could be implemented as a lazy copy for example.
Posted May 6, 2009 19:40 UTC (Wed) by adj (subscriber, #7401)
Surely there's a better name for a make-a-copy-of-this-inode-and-all-its-data-and-maybe-do-some-cool-COW-magic system call. It's too bad that the "dup" family of system call names is already used for something with a completely separate meaning.
Posted May 6, 2009 21:47 UTC (Wed) by AnswerGuy (guest, #1256)
magically-allocated-data-copy-on-write ... :)
Posted May 7, 2009 10:12 UTC (Thu) by epa (subscriber, #39769)
A reflink would be a new type of inode only in so far as the filesystem must track the fact that it has blocks shared with another inode. There is no difference, though, between an inode created by a reflink and the file's original inode; they both become reflink inodes.
If one of the two reflink inodes is then removed, does the other one revert back to being a normal file? If not, is there any difference between a lone reflink inode and a normal one? Couldn't all files be reflinks?
Posted May 7, 2009 22:59 UTC (Thu) by dlang (✭ supporter ✭, #313)
if this isn't the case, it should be, for just this reason.
as I understand things, if a file is changed it may break the linking entirely (copying the entire file), or it may break the link partially (still sharing the common parts of the file, but with the differences being separated) at the option of the filesystem
Posted May 9, 2009 14:25 UTC (Sat) by sdbrady (guest, #56894)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds