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/