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. - Ted -- 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
