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. > An 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 > > An IFSFREG: > * 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, Bill
Attachment:
pgpVd8RQ51pjW.pgp
Description: PGP signature