Josef Sipek wrote:
On Wed, Jan 17, 2007 at 01:04:22PM -0500, Shaya Potter wrote:
Josef Sipek wrote:
On a more general level, what has higher priority a whiteout or a file?
whiteout, if it's 'valid' (i.e. serves a purpose) to exist, as all my
code does is skip whiteout searching if it doesn't matter if it exists.
If whiteout is the higher priority object, then readdir should not display
the file created under these circumstances. => pushing the "problem" to
readdir :)
true, though readdir could ignore it in the right situations as well :)
I would like to find an alternative way to do whiteouts - not as separate
files. The only thing I can think of short of modifying the lower fs, is
using xattrs.
would this work on NFS?
No :-/ It wouldn't also work on other fs that don't support xattr like vfat.
Another option (suggested by Ted Tso) which would fix persistent inode
numbers as well, is to create some minimal on-disk format and pass a file
containing this to mount.
This would give us:
1) persistent inode numbers
2) whiteouts that work on all filesystems
3) whiteouts not poluting the namespace (as it is the case with .wh. and
even the way BSD does things with modified lower filesystems)
except (from my experience) this is significantly slower than regular
unionfs today. However, that could also be related to my inexperience
w/ efficient directory management. Though one advantage of it would be
that you could handle hard links w/ copyup correctly (if you had a
mapping of inode #->{name,name,....}
Whiteouts should be associated with the union, not the branch (which we do
now). The current setup breaks things if you want to share the same branch
between several unions, or even stack unionfs on top of unionfs :)
the same branch can be shared between unions (I do that), just not
read-write. sharing the same branch read-write hits page cache issues
before it hits whiteout issues.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
