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

a reflink would be a new type of inode

a reflink would be a new type of inode

Posted May 6, 2009 3:00 UTC (Wed) by xoddam (subscriber, #2322)
In reply to: The two sides of reflink() by martinfick
Parent article: The two sides of reflink()

Hard links are not distinct inodes (as reflinks must be); rather they are multiple directory entries pointing to a single inode. Symlinks are (in most posixish filesystems) a special kind of inode. Reflinks will be yet another special kind of inode; if the filesystem code does not recognise an inode type it will return an error when you attempt to open it (maybe -ENOSYS, I'm not sure).

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.


(Log in to post comments)

a reflink would be a new type of inode

Posted May 6, 2009 8:55 UTC (Wed) by epa (subscriber, #39769) [Link]

There seems to be some asymmetry. If you make another hard link to a file, then the two links are equal in status and you can't see which is the original. But a reflink is to be a special inode type and different somehow from the original version of the file.

a reflink would be a new type of inode

Posted May 6, 2009 9:46 UTC (Wed) by xoddam (subscriber, #2322) [Link]

Yes, like a symlink.

a reflink would be a new type of inode

Posted May 6, 2009 12:24 UTC (Wed) by corbet (editor, #1) [Link]

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. In Btrfs, I believe, things are even less different; the tracking of the shared blocks is done at the extent level.

a reflink would be a new type of inode

Posted May 6, 2009 16:07 UTC (Wed) by masoncl (subscriber, #47138) [Link]

It is more accurate to say (for both btrfs and ocfs2) that the result of the reflink is an entirely new file. It has a known starting point (the contents and permissions of the original).

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.

a reflink would be a new type of inode

Posted May 6, 2009 19:40 UTC (Wed) by adj (subscriber, #7401) [Link]

That leaves the "link" part of the interface name sounding terribly misleading.

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.

madcow()?

Posted May 6, 2009 21:47 UTC (Wed) by AnswerGuy (subscriber, #1256) [Link]

magically-allocated-data-copy-on-write ... :)

a reflink would be a new type of inode

Posted May 7, 2009 10:12 UTC (Thu) by epa (subscriber, #39769) [Link]

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.
Ah, so it is symmetric, somewhat like making a hard link with 'ln'.

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?

a reflink would be a new type of inode

Posted May 7, 2009 22:59 UTC (Thu) by dlang (subscriber, #313) [Link]

I believe that one of the features of a reflink is that it tells you what else it's linked with, so that you can find it to break the COW

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


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