On 02/12/10 16:11, Chris Mason wrote:
Excerpts from Arne Jansen's message of 2010-12-02 04:49:39 -0500:
Josef Bacik wrote:
1) Scrap the 256 inode number thing. Instead we'll just put a flag in the inode
to say "Hey, I'm a subvolume" and then we can do all of the appropriate magic
that way. This unfortunately will be an incompatible format change, but the
sooner we get this adressed the easier it will be in the long run. Obviously
when I say format change I mean via the incompat bits we have, so old fs's won't
be broken and such.
2) Do something like NFS's referral mounts when we cd into a subvolume. Now we
just do dentry trickery, but that doesn't make the boundary between subvolumes
clear, so it will confuse people (and samba) when they walk into a subvolume and
all of a sudden the inode numbers are the same as in the directory behind them.
With doing the referral mount thing, each subvolume appears to be its own mount
and that way things like NFS and samba will work properly.
What about the alternative and allocating inode numbers globally? The only
problem would be with snapshots as they share the inum with the source, but
one could just remap inode numbers in snapshots by sparing some bits at the
top of this 64 bit field.
The global inode number is possible, it's just another btree that must
be maintained on disk in order to map which inodes are free and which
ones aren't. It also needs to have a reference count on each inode,
since each snapshot effectively increases the reference count on
every file and directory it contains.
The cost of maintaining that reference count is very very high.
A couple of years ago I was suffering from the problem of different
files having the same inode number on Netapp servers. On a Netapp device
if you snapshot a volume then the files in the snapshot have the same
inode number as the original, even if the original changes. (Netapp
snapshots are read only).
This means that if you attempt to see what has changed since your last
snapshot using a command line such as:
diff src/file.c .snapshots/hourly.12/src.file.c
Then the diff tool will tell you that the files are the same even if
they are different, because it is assuming that files with the same
inode number will have identical contents.
Therefore I think it is a bad idea if potentially different files on
btrfs can have the same inode number. It will break all sorts of tools.
Instead of maintaining a big complicated reference count of used inode
numbers, could btrfs use bit masks to create a the userland visible
inode number from the subvolume id and the real internal inode number.
Something like:
userland_inode = ( volume_id << 48 ) & internal_inode;
Please forgive me if this is impossible, or if that C snippet is
syntactically incorrect. I am not a filesystem or kernel developer, and
I have not coded in C for many years.
--
David Pottage
--
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
