On Thu, Mar 14, 2013 at 10:09 PM, J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote:
>
> "no inodes at all"?
> Are you assuming the implementation in dcache only (with a new d_type
> flag)? And it is up to the real fs (layer or branch) whether it consumes
> inode or not?
Yes. That would be lovely. And trivial for most filesystems to support.
Sure, you could have an inode if you need to (not all filesystems may
have a flag in the directory entry), so it would look like "mknod()"
for the filesystem. But the filesystem might decide to never actually
create the inode at all if it reconizes the node as a whiteout node.
I think we should do this. Yes, it requires filesystem work, but in
the long run it's the right thing to do, and the filesystem work is
likely very very simple. Besides, we probably only need to support a
few filesystems for it to be already useful. What filesystems do the
people who use unionfs actually use today?
Also note that it's only the "upper layer" filesystem that needs
whiteout nodes. So it's not "all filesystems involved with overlayfs",
it's only the upper ones. And they have to already support xattr, so
I'm assuming in practice we're talking only a few cases, right? Just
tmpfs, ext3, ext4 probably covers most cases..
And it would get rid of all the horrible security check changes for
xattrs, no? So we'd really end up with a noticeably cleaner model.
Linus
--
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
