Hi Ted,
Theodore Tso wrote:
On Sat, May 02, 2009 at 11:15:01PM -0700, Joel Becker wrote:
int reflink(const char *oldpath, const char *newpath);
The reflink(2) system call creates reference-counted links. It creates
a new file that shares the data extents of the source file in a
copy-on-write fashion. Its calling semantics are identical to link(2).
Once complete, programs see the new file as a completely separate entry.
How should quota handle reflinks? Since there are separate inodes,
the two files could be owned by different user ID's. Since the data
blocks exist only once, I can imagine a number of different ways of
handling it:
1) When the reflink is created, the owner of the new reflink is not
charged the number of blocks of the file against his/her quota. If
the original inode is deleted, the original owner continues to have
the cost of the file charged against his/her quota until the last
reflink disappears.
2) When the reflink is created, the owner of the new reflink is NOT
charged the number of blocks of the file against his/her quota. If
the original inode is deleted, the owner of the reflink is charged the
number of blocks against his/her quota. If that drives the owner over
quota, the quota subsystem will enforce the soft and hard quota limits
as per normal. If there are more than one reflink against the file,
the system will randomly choose one user and charge the blocks against
his/her quota.
3) When the reflink is created, the owner of the new reflink is
charged the number of blocks of the file against his/her quota. The
original owner of the inode continus to also have the blocks of the
file charged against his/her quota, so in effect the blocks are
"double counted".
4) When the reflink is created, the owner of the new reflink is NOT
charged the number of blocks of the file against his/her quota. The
original owner of the inode continues to also have the blocks of the
file charged against his/her quota; if the file is deleted the blocks
associated with the file will not be charged against any users' quota.
All of these have various problems; and maybe the answer is that
reflinks aren't really compatible with quotas, so pick something least
bad (say #3), and we can just move on.
yeah, agree. So I will pick #3 in my ocfs2 reflink implementation.
Thanks.
Regards,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
