The future of the Linux filesystem

The future of the Linux filesystem

Posted Nov 6, 2003 16:45 UTC (Thu) by stevef (subscriber, #7712)
Parent article: The future of the Linux filesystem

Although this decription of WinFS over NTFS is reminiscent of OS/2 Extended Attributes, it misses discussion of the functional requirements in the filesystem. Even without standardization (about a dozen named attributes were standardized across applications historically), Extended Attributes had value because they were useful to the program but transparent to the user (streams are even more valuable). For advanced searching in a traditional filesystem model, an obvious choice would be to leverage Alternate Data Streams (similar in some ways although more flexible than Macintosh Forks, OS/2 Extended Attributes or xattrs). This appears to be the pragmatic approach described - putting database link function in user space that leverages minor NTFS extensions. A straw person list of the filesystem requirements this woud generate are:

1) The API must be invokable from userspace (Sun's "openat" and the existing xattr API may be reasonable)

2) The API must allow for quick search for existing of a particular xattr on a particular object (Microsoft seems to do this mostly by labelling their streams with UUIDs) and retrieval of the value of the xattr

3) The filesystem must support xattrs (or streams) larger than 64K (probably of arbitrary size) - an example from past history shows why this is important - when each stream contains a translation of the program's messages into a different languages.

4) Common utilities must support (ie modified or new ones created) for copying, moving and archiving the file (including all of its streams) as one command (users should not have to write code to list through the file's streams and copy each individually)

5) The VFS layer and at least one :) local filesystem must support a rename operation that rename a file and all of its streams as one operation.

6) The API should consider the requirements of some of the Servers too - not just Samba (which has needed stream support for a while to provide compat. with a few client apps running in a network with Linux servers) but also for NFSv4 (which even in an all Unix/Linux environment should support opcode 19 which is reminiscent of alternate data streams)

All of this can be done [only] in libc or in applications like Apache and Samba if necessary (treating groups of files or stream pseudo-directories with reserved naming conventions ...) but it is much less efficient for file renaming, links and file copy to [solely] rely on userspace changes than it would be with minor extensions to the VFS.

---

(Log in to post comments)