Messages in this thread | | | Date | Fri, 12 Dec 2003 14:56:09 +0100 | From | Jörn Engel <> | Subject | Re: Is there a "make hole" (truncate in middle) syscall? |
| |
On Fri, 12 December 2003 07:39:25 -0600, Rob Landley wrote: > On Friday 12 December 2003 06:55, Jörn Engel wrote: > > > > Yes, the obvious and stupid implementation has a ton of problems. > > Most likely the right approach is some sort of background deamon > > (garbage collector, defragmenter, journald, whatever you may call it) > > that does exacly this even after the fact for the last unchecked > > writes. Asyncronous under load, possibly even synchronous when almost > > idle. > > Actually, I'd planned on implementing a cron job that could do it. We're > talking a dozen lines of Python code (which can be optimized to only look at > files with timestamps since the last time it ran). And doesn't need anything > from the kernel but the syscall...
...and it sucks. Same problem as with updatedb - 99% of all work is bogus, but you don't know which 99%, because the one knowing about it, the kernel, doesn't tell you a thing.
Maybe a simple notification mechanism would sufficiently solve this as well, so all the rest can be done in userspace. Basically a file with a simple format like this: #path offset len /tmp/foo 0 12
Meaning that bytes 0-11 of /tmp/foo have changed in whatever way.
Something like that, the details don't matter too much.
Jörn
-- When you close your hand, you own nothing. When you open it up, you own the whole world. -- Li Mu Bai in Tiger & Dragon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |