tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Implementation Proposal for Subfile GSoC

On Sun, May 25, 2008 at 02:29:07AM -0700, Adam Burkepile wrote:
> I'll be implementing subfile support and wanted to get some feedback  
> on what the community thinks of the additions/design decisions my  
> mentor and I have been thinking of making. Any questions and/or  
> comments are welcome.
> Changes that need to be made to the file system
>           o Add a flag to the file system superblock to show if  
> subfiles are supported on the filesystem
>           o Add two new inode types ( IFSFDIR and IFSFREG )

I don't think this is the right way to go. FreeBSD already has extended 
attribute support for which we've added VOPs. Whatever you do needs to be 
compatabile with them.

Actually, let's take a step back. NetBSD has, in the past, been a solid 
file server platform. SMB and AFP export support for named streams or 
subfiles or whatever you want to call it. For them to work right, the file 
server applications have to be able to make calls into the kernel that 
will do the right thing regardless of the underlying file system.

We also need to be able to copy files from what you do to UFS/FFS to NTFS 
and UDF. And we need to be able to copy from those file systems to FFS.

The upshot is that having named streams/subfiles in a separate space from 
UFS extended attributes will cause LOTS of complications. So your named 
streams have to exist in the same namespace as extended attributes.

Either that or we have to give up being a good file server platform. 
Keeping subfiles/named streams in a separate namespace from EAs will 
complicate things from here on out.

I'm not sure how exactly EAs are kept on disk in FFS now, but my 
suggestion is to extend that so that you can hang inodes off the EA 
namespace. Thus the EA namespace is your IFSFDIR.

> * is referenced by exactly one base inode, add a back pointer to the  
> inode struct
> * contents are same as normal directory, struct direct.
> * contains a ?.? entry that references the IFSFDIR.
> * contains a ?..? entry that references the base inode
> * entries may only reference IFSFREG there may be no subdirectories or  
> device nodes
> * is instantiated on demand
> * is removed when the base inode is removed
> * does not have independent access control (uid, gid, mode), refer the  
> the base inode
> * is just like an IFREG
> * could (should?) contain a back pointer to the IFSFDIR

If regular files don't contain back pointers to their parent directories, 
then this doesn't need a back pointer either.

> * can only have a link count of 1
> * can be deleted explicitly (see subfile_remove(), below)
> * is deleted when the base inode is deleted
> * does not have independent access control (uid, gid, mode), refer the  
> the base inode
> When a base inode is deleted, the subfile tree has to be deleted also.  
> Changes to remove() would be needed.
> OS Level - System Calls
>     * o int subfile_fdopen (int basefilefd, char * subfilename, int  
> open_flags);
>                 + subfile_fdopen acts much like regular fdopen(2)  
> except it is passed a basefile fd to open then opens the subfile of  
> the basefile.

Please just steal the API from Solaris. Don't invent your own for 
something when there's existing art.

>        o int subfile_open (char * basefilename, char * subfilename,  
> int open_flags);
>                 + subfile_fdopen is the same as subfile_open except  
> it uses a file descriptor to reference the basefile.
> Both of these open functions would return a normal file descriptor to  
> the subfile upon a successful open, a fd that can be used with normal  
> read, write, close, etc.
>    *     o opendir -modified to open the sub_file folder of a file if  
> the file?s inode contains a sub_file folder reference
>           o int subfile_stat (char * basefilename, char *  
> subfilename, struct stat * sb);
>           o int subfile_fdstat (int basefilefd, char * subfilename,  
> struct stat * sb);
>           o int subfile_remove (char * basefilename, char *  
> subfilename);
>           o int subfile_fdremove (int basefilefd, char * subfilename);

As above, other OSs have APIs for this already. Please use them.

Note: there is some confusion in the naming around all of this. Linux and 
FreeBSD have extended attributes which are small blobs of atomicly-written 
data. NTFS has named streams, which are files-within-the-file. Solaris has 
extended attributes which are also files-within-the-file, just to confuse 
things. My understanding is that NFSv4 has added "extended attributes" 
which are files-within-the-file.

So there's a lot going on in this space, and coming up with something 
entirely new will, in my opinion, not serve NetBSD well. Also, since there 
is so much that has been done, there is a lot of prior art to look at.

Take care,


Attachment: pgpVd8RQ51pjW.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index