Dear David,
My first thoughts on a gc filesystem would be a tie into the unlink
call, when the FS came back with ENOSPACE (or whatever) the inodes
marked for unlinking would be reclaimed in some order and the write
retried without the application having to know about it. That could
be carried out by a daemon in userspace, but there are other problems:
My problem with this is how to mark something as deletable? in
such a way as you can undelete it when necessary
You also shouldn't be using a deleted file - though should you
see it in its old place? Changing its owner & permissions
(uid=-4,perms=0x1000) could do that, but whilst we can trap
the unlink in user space changing ownerships and enabling
a special "overwrite" case would require kernel changes (since
anyone should be able to overwrite a deleted file). Contrariwise,
a user-space application could be used to retrieve the old file
permissions, effectively restoring the file.
Following the huge digression you started with discussing the linking
of directories (which I see as a red herring, and un-unixy to boot)...
I think I can see where Sean maybe has the wrong end of the stick.
I don't think you can get rid of '..' or reference counts but handling
them would be tricky:
A move is regarded as a relink and unlink - but with the garbage-collected
file system the unlink wouldn't take place until later (when rules allow).
so...
> mkdir a
> mkdir a/b
> ln a/b c
now b and c are the same directory
> mkdir c/d
> mv a c/d
I understand you to mean a link/copy of 'a' will be put into a/b/d
but the root directory will still contain 'a' because it hasn't
become empty.
If you were to cd /a/b/d/a/.. would you be back to root?
If you were to 'mv /a/b /b' then 'a' would later disappear
leaving /b/d.
Intriguing but not impossible.
.> D, A and B all contain themselves. Very Zen. This will send just
> about every unix tool known to man in an infinite loop. Export _that_
> via NFS, if you think you're hard enough.
If you 'ln -s . foo' currently, and export it though
samba to a NT box you also get an infinite loop.
Using loopback mounts inside an exported NFS
mount can also cause infinite loops.
> Now try
> mv c/d/a c/d/a/b
In this case I would think it would copy 'c/d/a' to 'c/d/a/b/a'
the directory 'b' would have two links to its parent, '..'
and 'a'. The unlink of 'a' can't take place because the
directory is not empty.
What saves us in normal UNIX is that if this is done using symlinks
there are a maximum number of symlink traversals carried out when
resolving a path, when you use them up it pops out with an error.
You may find that trying to keep track of how many times you've
been through an individual directory is too time-consuming (list
of [inode,count]?).
More importantly though, applications can currently choose whether
they see a link or resolve it - which is an option they will lose if
all directories are equivalent. This currently allows applications to
avoid recursion by avoiding all symlink traversals (e.g. tar)
For this reason I suggest working with current UNIX semantics-
store permissions for deleted files in a per-partiton data area,
indexed by inode.
On unlink tell a root-enabled daemon which will store the permissions
and make the file unreadable.
If someone overwrites the file, the kernel needs to pretend it's not there,
likewise with "test -f filename" - this will maybe require kernel mods.
Should this
destroy the old version or rename it with a revision c.f. VMS.
Should anyone with write access in the parent directory should be able
to restore the file, or just the owner?
Should this feature be enabled per-partition?
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:20 EST