John Gilmore wrote: >On Wednesday 26 October 2005 22:40, Nate Diller wrote: > > >>File-as-Directory >> The issue with file-as-directory (FaD) is that it removes the Acyclic >>property of the namespace graph. This is because anything which contains >>file data can be hard-linked, even if that item is also a directory. It >>would be unreasonable to discard hard links entirely, they are quite useful >>and would be much more useful, in fact, with FaD enabled. So the new >>namespace would be a directed graph, with cycles. Since unix operating >>systems are responsible for deleting unused data in file systems (garbage >>collection), any algorithm used for that purpose has to satisfy strict >>requirements, for CPU and memory use, but more importantly for reliability. >> The algorithm must not fail the deletion unless the system is OOM, and it >>must always free the file's resources. Reference counting has always been >>used for this task. It's been awhile since I took graph theory, and I got a >>C in it anyway, but the algorithms I have seen for determining graph >>connectivity end up traversing to every node in the graph in the worst >>case. This means that the file system would potentially have to read in >>the directory data for every link to every file in the system, for a single >>deletion operation. >> >> > >If the issue is really the matter of removing the acyclic property, wouldn't >that be solved by requiring that the file contains no non-dynamically >generated subdirectories? > More precisely, that a file with two hard links contains no non-dynamically generated subdirectories. Hmmm. Yes, that works I think....
> That way, the graph is still acyclic, making >reference counting work again. > >I had understood that a big part of the issue with file-as-directory was the >same as the issue with hard links to directories. Which I thought is that if >you move one directory into another, you can lose the connection to the root >of the filesystem -- I.E. ../../.. etc is no longer guaranteed to get you >to / -- And of course this also means that there is no way to get from / to >your freshly moved files, and you've just lost a chunk of disk space to >complete inaccessibility. fsck would have to be made smarter specifically to >be able to figure that one out, too. > >Forbiding subdirectories in file-as-directory solves that problem too, because >a normal file cannot be moved into anothers' file-as-directory. You could >make it lose its meta-data, I suppose, but that's potentially lossy, which mv >isn't allowed to be. > >Actually, when I had first read about file-as-directory, I had assumed that >the content was either dynamically generated from the on-disk metadata (like >uid, gid, etc) or stored as a "sideband" type stream in the file itself, like >some of the MAC OS file systems (and others) do, or generated via a plugin >connecting to user-space, for ID3 tags on mp3 files and other information >which can easily be obtained from the file itself. > > > > >
