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

The two sides of reflink()

The two sides of reflink()

Posted May 6, 2009 16:03 UTC (Wed) by iabervon (subscriber, #722)
Parent article: The two sides of reflink()

I don't see why the reflink-as-copy idea wouldn't work for snapshotting. Sure, a snapshot of a file wouldn't include the metadata, but a snapshot of the directory containing a file would presumably copy the metadata (and would presumably require all sorts of interesting authorizations so that users can't squirrel away copies of setuid binaries and wait for security holes to be found in them). The difference in design seem to me only to affect where exactly the boundary between the part of the filesystem that gets snapshotted and the part that doesn't is for a particular choice of arguments.

Of course, being about to copy directories with this sort of mechanism is probably trickier to implement, but any good snapshot mechanism would have to handle this sort of thing.


(Log in to post comments)

The two sides of reflink()

Posted May 6, 2009 17:44 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

Most metadata is part of the inode, not the directory entry, so snapshotting the directory wouldn't have any effect on the metadata (apart from the filename). In the reflink-as-copy scenario the owner, group, permissions (e.g. setuid), and the like would be tracked separately for each reflink. Presumably the limitations concerning these attribute would be the same as for creating new files; e.g. the reflink would be created with the owner, group, and umask of the current user, and only the data would be shared (COW).

Given their small average size, it probably makes more sense to just copy the directories themselves outright rather than implementing them as COW. Recursive copies would be similar to "cp -dlR", just with reflink() in place of symlink().


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