shiny new next-generation filesystem? [LWN.net]

shiny new next-generation filesystem?

Posted Feb 17, 2007 1:15 UTC (Sat) by cantsin (subscriber, #4420)
In reply to: shiny new next-generation filesystem? by JohnNilsson
Parent article: Avoiding the tar pit

The question is whether these API changes don't break Unix semantics and introduce security/stability issues, see the discussion on Reiser4 on lkml. And shouldn't filesystem/VFS plug-ins be done in userspace? Unless I am missing something, it appears that FUSE implements this functionality in a safe, clean and filesystem-transparent way. Last not least, it's a solution that works today instead of a rather vague future promise. (I first heard Hans Reiser talking about ReiserFS plug-ins in ca. 2001.)

(Log in to post comments)

shiny new next-generation filesystem?

Posted Feb 17, 2007 1:52 UTC (Sat) by brouhaha (subscriber, #1698) [Link]

The earliest I'd heard of file systems with plugins (to create virtual directories or files) was around 1986 in the development of the Intel/Siemens "Gemini" project, which was in a sense a successor to the Intel iAPX 432, and which they attempted to commercialize under the name "BiiN". The original specification for the Osiris operating system had this capability, though I'm not sure if it was present in the delivered release. BiiN was ultimately a commerical failure, as had been the iAPX 432.

The suggested applications were things like integrating revision control into the file system, and making archives (e.g., tar files) into virtual directories.

Although these ideas are great in theory, and perhaps even of some value in practice, I agree with cantsin that they are better implemented above the filesystem interface, rather than having plugins that can only work with one filesystem but not others. This could be done in the kernel above the VFS layer, but as cantsin suggests, user space (e.g. FUSE) is probably best.