Pawel Jakub Dawidek <[email protected]> wrote: > > Note that if you don't mount snapshots as separate items with separate file > > system ids (st_dev), you will violate POSIX filesystem semantics. > > When we export file system and its snapshot as one NFS export we do > violate this as collision is possible. > > I was hoping we could split 64bit inode number and use its top part to > store snapshot identifier to avoid collisions, but 64 bits are not that > much.
There is another problem: There are 32 bit programs that may not run in large file mode. Those programs would not be able to access files with inode numbers in the range above 32 bits. And if you like to have an "unlimited" number of snapshots for a specific filesystem, you may need a lot of bits for such a modification. > > BTW: What is the problem with mounting from inside the kernel? > > We have to use some global root credentials to mount the snapshot or > credentials of the user that who the mount (in case of delegated > administration). Not the credentials of the user who triggered snapshot > mount. It gets even messier when the process triggering the mount is > chrooted, etc. Separate set of issues I had with NFS, which didn't use > VFS_LOOKUP() in some places (file handle->vnode method was used), so > mounting wasn't happening. I remember changing that to use VFS_LOOKUP(). OK... But in general, I believe that there is a need to define which source files are part of a "whole" ZFS implementation. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
