enfs-devel Mailing List for enfs - A user level VFS layer (Page 2)
Brought to you by:
tramm
Menu
▾
▴
enfs-devel — enfs development discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(20) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tramm H. <hu...@sw...> - 2001-11-08 14:55:54
|
Tramm Hudson wrote:
> Here is an interesting project that is implemented via an NFSv3 servo:
^^^^^
I must have helicopters on my mind...
Trammell
--
o hu...@sw... O___|
/|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_
<< KC5RNF H 505.315.5133 \ \/\_\
0 U \_ |
|
|
From: Tramm H. <hu...@sw...> - 2001-11-08 14:50:50
|
Folks, Here is an interesting project that is implemented via an NFSv3 servo: http://www.fs.net/sfs/new-york.lcs.mit.edu:85xq6pznt4mgfvj4mb23x6b8adak55ue/pub/sfswww/index.html # On the client side, SFS implements a file system by pretending to be an # NFS server and talking to the local operating system's NFS3 client. # The program sfscd gets run by root (typically at boot time). sfscd spawns # two other daemons--nfsmounter and sfsrwcd. They have a neat way of sidestepping most PKI issues by embedding the key in the path: # The key difference between SFS and any previous file system is that # SFS always provides security over untrusted networks, but does not # perform any key management. SFS accomplishes this by naming file systems # by their public keys. Every SFS file server is accessible under a # self-certifying pathname--a file name of the form: # # /sfs/Location:HostID # # Location is the server's DNS hostname or IP address. HostID is a # cryptographic hash of the server's public key. SFS uses a # collision-resistant hash function to compute HostID. Thus, HostID # effectively specifies a unique public key. (The client can ask a server # for its public key, hash the key, and ensure that the key returned by # the server matches the HostID in a pathname). Self-certifying pathnames # are automatically created, or "automounted", the first time they are # referenced. Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Tramm H. <hu...@sw...> - 2001-11-02 16:41:11
|
Folks, Lee mentioned that there was an experimental procfs style interface for configuring enfs. I'd like to explore the possibilities that we can do with such a system and try to gauge how long it would take to implement some features: - Module loading / unloading - Namespace building - Metadata presentation - Per-module configuration and performance tuning - Per-module output - SWIG interface ----- The first case is fairly easy. Module lists can be presented in a fashion similar to the /proc/modules file under Linux. It lists the module name, the size in bytes, the use count and other modules that are using it. The only complexity comes in relative file paths. In a secure environment enfs should run chrooted to nowhere, which could make accessing the modules difficult. There is unfortunately no form of fd_dlopen() or the like. We could read the module on an fd and write it to a temp file, but then we lose the ability to let ld do the hardwork of dependency management. We can probably punt on the security issues, although that always bothers me. I have rarely seen any of those "later" items get fixed. ----- The namespace building can be done by presenting the metadata tree in this filesystem and implementing the link or symlink calls to setup mount covers. I think this would work and free the mount call from dealing with the complexity of setting up and tracking covers; we would just push the details elsewhere in the code base. I'd like to whiteboard this sometime because there are probably tricky details that need to be worked out. ----- Statistics gathering is also easy. We just need an easy way for a module to create a file or tree in /proc and map datastructures to it. Providing some simple templates for char*, int, int[], char*[] would be good. This does require some namespace code, although it could be in the proc module rather than the kernel. I like Perl's tie mechanism, but it's a bit too difficult to map into C very well. Performance tuning is similar to statstics gathering in reverse. If we have the above, then we can get parameters into modules in the same manner. ----- If we have a SWIG interface then modules can be written in a variety of languages. I think PerlFS would be cool, despite the legal encumberances (cf Applesoft). The other advantage of making a Perl interface is that many of the Perl data structures map very easily to filesystem trees. When combined with the tie magic the code could transparently make Perl hashes appear in the filesystem. That's way cool. ----- Lots of random ideas, folks. With the exception of the module loading, none of them are on the critical path to either of our organizations' goals. But most of them are things that I think we need for ease of use should we start getting outside users. Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Tramm H. <hu...@sw...> - 2001-11-01 05:24:25
|
Lee wrote:
> Tramm wrote:
> > Scott lifted the dtree code from Linux's procfs for the most part, but
> > it is all embedded in the skelfs module.
>
> Hmm. Lifted? I hope not straight? You mean "inspired by" I hope, since
> we're thinking it's 100% Sandia copyright.
Well, the comment in dtree.h sounds clear:
/*
* the tree-link structure, lifted from Linux procfs.
*
* presumably, the name space used in file systems based
* on this abstraction will be small. if larger name spaces
* are required, a more efficient core storage mechanism will
* be required.
*/
I can not find anything in the current 2.4 kernels that resembles
it, however.
> I would have thought that all the external modules would need to supply
> would be the read/write routines. He's got it all in there though? Ugh.
I would have to look through the code a little more, but it appears
that he has a full VFS, including symlinks, etc.
Trammell
--
o hu...@sw... O___|
/|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_
<< KC5RNF H 505.315.5133 \ \/\_\
0 U \_ |
|
|
From: Lee W. <le...@sa...> - 2001-10-31 23:37:46
|
Tramm Hudson wrote: > > Folks, > > Scott lifted the dtree code from Linux's procfs for the most part, but > it is all embedded in the skelfs module. Other VFS layers have directory > operations available in the "core" since most every filesystem needs > some form of tree management. Should we move it into the enfs kernel? Probably. I asked Scott about moving it there once and he said it was somehow dependent on pieces in the skelfs directory that probably shouldn't be moved into the kernel. Can't say I looked though. > > On a related note, Lee and I discussed the 4.3BSD and 4.4BSD layers > and discarded most of the 4.4 ideas. One of the main changes that they > have made is to put the naming system into a separate layer from the > presentation and filestore. For Ruth, and posterity, more properly the decision was deferred until we had a need or alot more time on our hands than right now. > > Trammell > -- > o hu...@sw... O___| > /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ > << KC5RNF H 505.315.5133 \ \/\_\ > 0 U \_ | > > _______________________________________________ > Enfs-devel mailing list > Enf...@li... > https://lists.sourceforge.net/lists/listinfo/enfs-devel |
|
From: Lee W. <le...@sa...> - 2001-10-31 23:23:53
|
Tramm Hudson wrote: > > I wrote: > > Scott lifted the dtree code from Linux's procfs for the most part, but > > it is all embedded in the skelfs module. > > And as I read through it, I see that it has implemented its own VFS > internally. That's not really efficient... Hmm. Lifted? I hope not straight? You mean "inspired by" I hope, since we're thinking it's 100% Sandia copyright. I would have thought that all the external modules would need to supply would be the read/write routines. He's got it all in there though? Ugh. > > Should we consider integrating it to use the enfs VFS layer instead? > It could be written as a module, which when combined with the stackability > provides naming ontop of a simpler system. Have to get Celera's needs covered first. That doesn't require a name space, right? If so, I suggest we defer the topic until we get the 1st phase for Celera done? I'm not opposed to doing it. I'm just thinking priorities right now. As well, I'm getting senile, you know, and if we discuss it now I'll forget :-) > > One thing it does not appear to address is writing the dtree info > to a store. That would have to be added before it could be used for > the naming of a persistent filesystem. True. > > Trammell > -- > o hu...@sw... O___| > /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ > << KC5RNF H 505.315.5133 \ \/\_\ > 0 U \_ | > > _______________________________________________ > Enfs-devel mailing list > Enf...@li... > https://lists.sourceforge.net/lists/listinfo/enfs-devel |
|
From: Tramm H. <hu...@sw...> - 2001-10-30 19:52:49
|
I wrote: > Scott lifted the dtree code from Linux's procfs for the most part, but > it is all embedded in the skelfs module. And as I read through it, I see that it has implemented its own VFS internally. That's not really efficient... Should we consider integrating it to use the enfs VFS layer instead? It could be written as a module, which when combined with the stackability provides naming ontop of a simpler system. One thing it does not appear to address is writing the dtree info to a store. That would have to be added before it could be used for the naming of a persistent filesystem. Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Tramm H. <hu...@sw...> - 2001-10-30 19:41:48
|
Folks, Scott lifted the dtree code from Linux's procfs for the most part, but it is all embedded in the skelfs module. Other VFS layers have directory operations available in the "core" since most every filesystem needs some form of tree management. Should we move it into the enfs kernel? On a related note, Lee and I discussed the 4.3BSD and 4.4BSD layers and discarded most of the 4.4 ideas. One of the main changes that they have made is to put the naming system into a separate layer from the presentation and filestore. Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Tramm H. <hu...@sw...> - 2001-10-29 20:41:50
|
Rith, > The checkout worked, after I set CVS_RSH to ssh and did an ssh > cvs.sourceforge.net to create my home dir on the server. I should have mentioned that. There is a good guide to using the CVS services on SourceForge, although you've already gotten past the difficult part: https://sourceforge.net/docman/display_doc.php?docid=765&group_id=1 Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Ruth K. <rk...@sa...> - 2001-10-29 20:35:00
|
The checkout worked, after I set CVS_RSH to ssh and did an ssh cvs.sourceforge.net to create my home dir on the server. Ruth Tramm Hudson wrote: > > Hi, Lee and Ruth! > > Since we're moving onward with the GPL codebase of enfs, I've setup > the mailing list and sourceforge project site for it. You can see > the website here: > > http://enfs.sourceforge.net/ > > The mailing list is "enf...@li...". You should > have received an automated welcome message with info on how to get off > the list. > > There is also a list for just the CVS commits to the code base. I've > subscribed both of you, but if you prefer not to receive that level of > detail then go ahead and unsubscribe. I like seeing what everyone > is doing and it gives me a good grasp of how the code base is changing. > > You can check out the latest code from CVS: > > cvs -d use...@cv...:/cvsroot/enfs checkout nexus > > Ruth -- I believe that you have write access to the respository if > necessary. Lee has to ask one of us to check in his changes since > he can't seem to get an account setup. > > Trammell > -- > o hu...@sw... O___| > /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ > << KC5RNF H 505.315.5133 \ \/\_\ > 0 U \_ | > > _______________________________________________ > Enfs-devel mailing list > Enf...@li... > https://lists.sourceforge.net/lists/listinfo/enfs-devel |
|
From: Tramm H. <hu...@sw...> - 2001-10-29 18:37:07
|
I'm working on the shadow filesystem, something that sounds far more exciting than it is. It's the first code to really stress the stackability of the VFS layers, so we might uncover some race conditions. I've junked some of the bad code that I wrote over the past month and have started anew. You'll probably see a good number of checkins related to it, but since we also have the modular code in place we're free to modify our own file systems without affecting the others. That's the idea, at least... Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
|
From: Tramm H. <hu...@sw...> - 2001-10-29 18:35:20
|
Hi, Lee and Ruth! Since we're moving onward with the GPL codebase of enfs, I've setup the mailing list and sourceforge project site for it. You can see the website here: http://enfs.sourceforge.net/ The mailing list is "enf...@li...". You should have received an automated welcome message with info on how to get off the list. There is also a list for just the CVS commits to the code base. I've subscribed both of you, but if you prefer not to receive that level of detail then go ahead and unsubscribe. I like seeing what everyone is doing and it gives me a good grasp of how the code base is changing. You can check out the latest code from CVS: cvs -d use...@cv...:/cvsroot/enfs checkout nexus Ruth -- I believe that you have write access to the respository if necessary. Lee has to ask one of us to check in his changes since he can't seem to get an account setup. Trammell -- o hu...@sw... O___| /|\ http://www.swcp.com/~hudson/ M 240.476.1373 /\ \_ << KC5RNF H 505.315.5133 \ \/\_\ 0 U \_ | |
