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

The two sides of reflink()

The two sides of reflink()

Posted May 6, 2009 17:44 UTC (Wed) by nybble41 (subscriber, #55106)
In reply to: The two sides of reflink() by iabervon
Parent article: The two sides of reflink()

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().


(Log in to post comments)


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