lkml.org 
[lkml]   [2013]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/9] overlay filesystem: request for inclusion (v17)
Date

Al Viro:
> Sure - btrfs happens to have an interesting limit on the number of
> links to the same object located in one directory.

It doesn't matter.
On every filesystem, the link count has its upper limit eventually. When
vfs_link() for whiteout returns EMLINK, aufs removes the whiteout-src
file and creates a new one internally and asynchronously. Completing a
new whiteout-src, aufs will go back to the link approach. The actual
link count when EMLINK returned does not matter.

Some filesystems don't support link(2). For such fs, user should tell
aufs that the layer-fs has no link, and aufs will always create whiteout
as a size-zeroed regular file instead of hardlink. Otherwise user cannot
remove a file logically (rm(1) will return ENOTSUP or EPERM.).


> And yes, it is an independent primitive. What I really don't understand
> is WTF is so attractive about not having to touch individual filesystems;
> it's not particulary hard to do for any fs we might care about...

Hmm, aufs might have lived too long time as outside mainline. The
whiteout approach aufs took is non-modifying the underlying fs. And I
thought it is essentially important for new fs, otherwise it would be
harder to be merged.


J. R. Okajima


\
 
 \ /
  Last update: 2013-03-16 15:21    [W:0.109 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site