

GCFS: a Garbage-Collected Filesystem for Linux   - spooneybarger
http://www.madore.org/~david/linux/gcfs/

======
drdaeman
Unfortunately, the necessity to distinct between files (and lack of
filesystem-level transactions) and directories led to inability to have a lot
of fancy filesystems. There are tons of research papers and projects, which
just cannot be implemented on GNU/Linux in non-kludgy way.

For example, there would be no need in archivers (like tar), when you could do
`cp ./directory archive.tar` (OS X has something similar this with dmg HFS
images). Or you could have `/etc/foo.config` as a text file, but also access
separate options as `/etc/foo.config/section/option`. Or you could have
versioning built-in into a filesystem. `./foo.txt` is a current version,
`./foo.txt/history/` is a directory with a list of revisions, and
`./foo.txt/history/2010-01-23T16:24:00Z.001` is an old version snapshot.

~~~
adbge
> There are tons of research papers and projects, which just cannot be
> implemented on GNU/Linux in non-kludgy way.

Do you recall any of these offhand? Thanks.

~~~
drdaeman
Well, I was able quickly remember and find just this: "The Box: A Replacement
for Files", Francisco J. Ballesteros et al.
(<http://lsub.org/ls/export/2kblocks/index.html>)

While I was writting the comment above I was mostly thinking of Plan 9 and GNU
Hurd. Couldn't quickly remember exact names, but you should look in direction
of those two OSes. They were made to address the shortcomings in UNIX design,
and had some fancy concepts.

------
rwmj
Not that it makes a lot of difference, but this page is from 2000.

~~~
bdonlan
It would also have been quite impractical before the development of affordable
solid state drives - GCs tend to involve quite a lot of random access, after
all...

That said, I'm far from convinced allowing cycles in a directory structure
would actually be useful for anything.

~~~
rwmj
Yeah, I was wondering if it would allow applications to create "detached"
filesystems. I could see that being (sorta) useful: a filesystem which is
automatically cleaned up when the application exits.

Of course you can already do that easily enough with /tmp, but /tmp has its
own problems: if it is shared between all users then it is a well-known source
of security problems, and if your OS has private /tmp then that has its own
problems too (ie. it's _not_ shared between users of the same application).
The other problem with /tmp is that it isn't "garbage collected" very quickly
-- on my Fedora server, unreferenced /tmp files stay around for up to 10 days.

With GCFS it looks like you could get rid of /tmp altogether. Applications
could just create a directory anywhere (eg. some random name under $HOME) and
then "detach" it by removing "..", and then keep it open for as long as they
need it, after which time it gets GC'd quickly and automatically.

~~~
jrockway
_The other problem with /tmp is that it isn't "garbage collected" very quickly
-- on my Fedora server, unreferenced /tmp files stay around for up to 10
days._

Technically, apps using temp files are supposed to unlink them after opening
them, so that they get cleaned up as soon as they are closed. This is
sometimes true of things that are shared, like UNIX sockets, too.

------
aidenn0
This is an old article. Mount --bind solves the directory hard-linking problem
for root, and there is no compelling reason to allow users to hardlink
directories.

Also, making a file-system not a tree adds a lot of complexity for
questionable gains.

------
robbyt
The Posix-Breaking Party that the author describes could be implemented by
using any COW file system for the backing store. For example, the new SCSI
Unmap support in ZFS: [http://gdamore.blogspot.com/2011/03/comstar-and-scsi-
unmap.h...](http://gdamore.blogspot.com/2011/03/comstar-and-scsi-unmap.html)

------
tobias3
Does anybody know how they implemented directory hardlinks in Mac OS (they use
them for time maschine I think)?

~~~
SoftwareMaven
I just tried to do a directory hard link and it failed.

    
    
      $ ln ~ hardlinkdir
      ln: /Users/travis: Is a directory
      $ ln -s ~ hardlinkdir
      $
    

My guess is that they have implemented something like soft links with cleaner
shell support, so you can't tell they are something like soft links.

~~~
wzdd
The ln command just doesn't expose the functionality.

[http://stackoverflow.com/questions/80875/what-is-the-bash-
co...](http://stackoverflow.com/questions/80875/what-is-the-bash-command-to-
create-a-hardlink-to-a-directory-in-os-x)

~~~
tobias3
hmm I guess you can do too much damage with directory hardlinks. Like link the
root into your home directory. A recursive delete on the home directory would
then delete all files...

------
rbanffy
I wonder what happened to it...

------
joe_the_user
What exactly would be the advantages of this for a user? (I can think of lots
disadvantages.)

My suspicion is anyone deleting a directory either _wants_ the information
within it destroyed or doesn't want to delete the directory after all.

Certainly, more "fuzzy" relations and storage could have their uses - like a
downloaded music directory where the least listened songs go away
automatically when you need more space. But you would not want to make your
entire file system "fuzzy" in the sense that you don't know what's gone and
what isn't.

The trashcan/recycle-bin is a great interface for undoing what you _thought_
was the deletion of a file. This, not so much.

~~~
Groxx
Then it seems you haven't used symlinks or hardlinks very much. I do it to
organize my code, because it's useful to have more than one way to get to
folder X (I have things organized by language, then they all go to a master
code folder which reorganizes them in versioned/not, mine/downloaded, etc). It
makes finding what I'm looking for very easy, it's easy to script changes /
restrict searches / update everything in one go.

But using symlinks means I can't reorganize without great cost, because they
don't follow movements around. It also means some of my folders look like
shortcuts while some don't, stepping into one causes my path to change wildly
(no backing up, usually), and in order to protect my data I have to make sure
I never delete (or move) the _originals_ , only the symlinks.

Or say you want to organize your images in two photo applications at the same
time - hardlinks mean each can have full control over where they place their
file, without interrupting the other, and without duplicating what could be an
enormous amount of data.

OSX attempts to solve this with Aliases - essentially, "smart" symlinks that
follow changes. If you alias a file and then move the original, the alias will
still work. The downside is that essentially no command-line tools handle them
in any way, because they're decidedly non-standard. Being able to hardlink
folders would allow filesystem organizations not possible before, with safety,
tool-compatibility, and efficiency.

