Re: [enfs-devel] Hello world..
Brought to you by:
tramm
From: Lee W. <le...@sa...> - 2002-02-22 16:57:05
|
Johan Rudholm wrote: >=20 > Hi! >=20 > I have been thinkin about what a great idea it would be to have a FTP > filesystem (similar to what Alex was), which would provide a local > filesystem view of FTP-servers similar to the /net-filesystem provided = by > (solaris only?) automount. I don't know if it's solaris only but it's certainly not there under freebsd or Linux. >=20 > I was thinking of using NFS for this. My primary platform would be > FreeBSD. >=20 > Re-inventing the wheel seemed unnecessary so I have been looking around > for similiar projects and came upon, amongst others, yours. >=20 > I haven't studied any of your code so with the risc of sounding > un-initiated, do you think enfs could serve as a wheel for my project? Probably... One piece of core infrastructure is missing that I think you will need. It's also an open argument between Tramm and myself. You will need the full path to the file, for each file. We do not now have anything that will implicitly support that. Under Linux, one has the dinode tree which will deliver this, trivially. In the *bsd variants one could lock entries into the system dcache I suppose, though that would be dangerous. In this, ENFS, project, so far the file system is expected to keep that information itself if needed. For instance, if you look at the skelfs and procfs code, they do it by maintaining a tree. The nodes in that tree become the "private" info field in the vnode record. Tramm and I do have a kind of tentative agreement that this implicit maintenance of full path support will be added when needed. If you are serious about pursuing enfs then your project, together with the existing procfs/skelfs code, would be enough to sway me. I think your biggest problem is going to be that NFS is stateless while FTP is stateful. Whether you choose ENFS or something else you'll be faced with this problem I think. If the NFS server goes down, all the state you will need to keep will disappear. For instance, say the NFS client is reading file data and the server reboots or somebody blasts the nfsd and restarts it, then the client will persist in trying the request. When enfsd returns to service all it has to go on is the file handle. For NFSv2, thats 20 bytes (in enfsd) of information. For the, in progress, v3 that will be 42 bytes (in enfsd again). You are going to have to keep full pathnames for active files as well as the server and any leading path components for the sub-export external to the nfs server. An external flat-file or (g)dbm instance? BTW, I was at a party with Richard Stallman a few years back and he was mentioning that someone had done a VFS implementation supporting an FTP file system such as you describe. I don't know if it was exportable via NFS though. I don't have any more information than that. It was a 2 minute conversation and we switched topics to something more appropriate to a birthday party. You might look for that project (maybe in the HURD?) or drop Thomas Bushnell (or whomever maintains the HURD now) and/or Stallman a note asking about it. Maybe it'll save you some effort. --Lee >=20 > // Johan >=20 > -- > Johan Rudholm <ch...@ed...> Systems Administrator > Tel: +46 31 772 58 63, Call: SM6XLV Chalmers University of Techn= ology > PGP fingerprint: 4D47 9C3F F1D8 8AF5 10B3 66BF 8876 17BB EBC2= 9708 > Visit me! N57=B0 41'30'' O11=B0 58'65'' >=20 > _______________________________________________ > Enfs-devel mailing list > Enf...@li... > https://lists.sourceforge.net/lists/listinfo/enfs-devel |