Thread: [enfs-devel] Hello world..
Brought to you by:
tramm
Menu
▾
▴
enfs-devel
|
From: Johan R. <ch...@ed...> - 2002-02-22 14:38:35
|
Hi! 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 was thinking of using NFS for this. My primary platform would be FreeBSD. Re-inventing the wheel seemed unnecessary so I have been looking around for similiar projects and came upon, amongst others, yours. 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? // Johan --=20 Johan Rudholm <ch...@ed...> Systems Administrator Tel: +46 31 772 58 63, Call: SM6XLV Chalmers University of Technolog= y PGP fingerprint: 4D47 9C3F F1D8 8AF5 10B3 66BF 8876 17BB EBC2 970= 8 Visit me! N57=B0 41'30'' O11=B0 58'65'' |
|
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 |
|
From: Johan R. <ch...@ed...> - 2002-02-26 16:58:47
|
Hello! On Fri, 22 Feb 2002, Lee Ward wrote: > 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? Okay. I was thinking of mounting the filesystem over the loopback interface, so that each client acts as it's own server... I attended a tutorial on unix network programming at last year's USENIX conferance in Boston and got the idea that it might be a good idea to use parts of NFS for this (ftpfs) kind of project. I'm still in the process of formulating what it is that I want and the best way of going about it. I appologize for being somewhat sluggish in my response, but please bear with me. Currently I haven't got the time that I'd like to spend on this project (work+studies...), I will however keep in touch and will let you know when I have given the idea more thought. Cheers, // Johan --=20 Johan Rudholm <ch...@ed...> Systems Administrator Tel: +46 31 772 58 63, Call: SM6XLV Chalmers University of Technolog= y PGP fingerprint: 4D47 9C3F F1D8 8AF5 10B3 66BF 8876 17BB EBC2 970= 8 Visit me! N57=B0 41'30'' O11=B0 58'65'' |
|
From: Lee W. <le...@sa...> - 2002-02-26 13:12:09
|
Johan, Haven't heard back from you. I was hoping you would keep in touch. I am interested to know what your decision will be regarding an FTP filesystem. I could make good use of such a thing here at Sandia. We use HPSS as our central archive solution and the best (only for us, right now) interface to that is FTP. A re-export through our ENFS solution would be a "good thing". Especially since I've been promising some sort of linkage to HPSS for more than a year :-) Anyway, keep in touch won't you? Let us know what you're thinking. Thanks. --Lee 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. >=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? >=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 |
Thanks for helping keep SourceForge clean.
X