On Friday 09 February 2007 22:47, paddy@panici.net wrote: > superb, I've wanted one of these for a long time :-) > > Other scenarios might include having a working system if the binary > images are not acccessible for some other reason such as h/w failure ?? If the kernel umounts a filesystem because of IO errors then you can't execute the program without a directory entry. However if you have a running program and memlockd had kept it in ram then it should keep running after a drive fails (unless of course it's data pages had been swapped out). To keep a program running after a failure the mlockall() system call might be the best option. > I had thought that the sticky bit had once been used like this? > but I went away and read just now that it was a bit different. The sticky bit was apparently aimed for better performance during regular operation. Shared objects and aggressive disk caching made it less useful so it was never implemented in Linux. > How does it interact with the filesystem? I imagine that if I rm > /bin/bash then I can no longer simply execute it in the usual way, > even if the pages are still locked in memory (and do you unlock > the pages when the underlying file is removed ?) My program won't notice a file removal unless you kill -1 it. > Is there any guarantee that the various directories and inodes needed > (are they needed??) will be in memory ? No. > Where can I get the code ? :-) As it's only 1K compressed I've attached an early version of the source (consider it version 0). -- russell@coker.com.au http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
Attachment:
memlockd.cpp.gz
Description: GNU Zip compressed data