Messages in this thread |  | | | From | "Towers, Tim (London)" <> | | Subject | Re: Suggestion: a garbage-collected file system | | Date | Wed, 12 Jan 2000 10:20:56 -0000 |
| |
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/
|  |