Messages in this thread | | | Date | Thu, 4 Mar 1999 14:40:58 -0500 (EST) | From | "Theodore Y. Ts'o" <> | Subject | Re: EXT2_UNRM_FL |
| |
Date: Thu, 4 Mar 1999 11:00:45 -0500 (EST) From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
This is wrong. Userspace should not need to be aware of mount point crossings. You need one trashcan for each mounted filesystem. (it is not "perfectly fine" for libc to read /proc/mounts every time you want to unlink something)
No, not everytime -- just the first time you want to unlink something. And if someone has changed the mount table, that will cause the rename system call to fail, at which point libc can recheck the mount table. Reading /proc/mounts at most once per process is no bad thing; a number of config files and shared libraries get opened on each process startup already, and it's not a problem.
There is another unrelated reason why the kernel must be involved. You need to really delete files as the disk gets full. Polling is just total crap, with race conditions and extra system load. You can run out of disk space between two polls. That is not allowed.
Polling simply means doing a quick statfs; that doesn't take much system load. And obviously, you want to keep a fairly large amount of free space to make sure the filesystem can do good block allocation --- for example, you might use a high and low watermark of 5% and 10% of the filesystem size. So unless you the user processes can consume that much disk space between the two polls, you'll be fine.
The grand Unix design transition is to try doing things in user space first. If it doesn't work, then put in the minimal kernel hooks to allow the Right Thing to happen. In this case, the smallest hooks would be ones which can automatically wake up the daemon when filesystem space starts getting critical.
Also, please remember that there are plenty of user-space undelete packages out there on the net; they apparently work just fine for most people who have a desire for that kind of protection.
- Ted
- 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/
| |