|
From: Anton A. <ai...@ca...> - 2003-04-23 13:11:57
|
Oh and I remembered some of the funnier requirements: The fh (file handle) has to uniquely identify the file AND has to be persistent across remounts, reboots, renames(!!!), and I think moves as well. With ntfs that is just purely impossible to guarantee... Note that readdir() return values have simillar requirements which we can't guarantee either. Unix requirements just don't map onto ntfs. To make it work in the usual case (both client and server stay up and no remounts happen) it is easy. Just use default nfs operations pretty much. I have done it before. Once you know what you need you won't spend more than an hour getting it to work and creating a patch but I am not convinced that having it "just about work" is good enough which is why I never bothered with nfs any more assuming noone in their sane mind would ever want to reexport ntfs via nfs but of course now we found someone that wants to do just that. *sigh* If anyone cares feel free to submit me a patch to enable it "just working" and I will apply it... Anton On Wed, 23 Apr 2003, Anton Altaparmakov wrote: > On Wed, 23 Apr 2003, Szakacsits Szabolcs wrote: > > On Tue, 22 Apr 2003, Anton Altaparmakov wrote: > > > Nobody ever expressed interessed in it which is why noone ever bothered > > > working on it... Now that someone is interested I will consider working > > > on this in the near-ish future. But note that we may well only do it for > > > 2.5.x kernels as 2.4.x kernels handle nfs completely differently (unless > > > > I've looked 2.4.20 _quickly_ at that time. nfsd/export.c states > > > > /* There are two requirements on a filesystem to be exportable. > > * 1: We must be able to identify the filesystem from a number. > > * either a device number (so FS_REQUIRES_DEV needed) > > * or an FSID number (so NFSEXP_FSID needed). > > * 2: We must be able to find an inode from a filehandle. > > * either using fh_to_dentry (prefered) > > * or using read_inode (the hack). > > */ > > > > The new ntfs driver satisfies both, still it's not exportable. However I > > didn't look it further why. > > You have to define a structure to enable this to happen explicitly. That > is easy if you use the default nfs provided operations... > > > > To implement properly pretty much impossible as there just isn't enough > > > > You mean for a read-write ntfs driver? IMHO that's a bit far ... For the > > read-only one it's much-much more simpler. > > No. Read-only is affected in the same way. I can't quite remember the > details any more but I think it was something along the lines of: Because > of hard links and short/long/posix file names it is impossible to find the > path to an inode only given the inode and this is precisely what we need > to be able to do. (I may be remembering wrong... but something like that > was the reason.) > > The need arises when an nfs server restarts while the client has a file > open. The next access to the server then needs to reestablish the open > file which for ntfs is impossible to do accurately. > > Anton > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Linux-NTFS-Dev mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev > Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
