[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP memlockd

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 

> 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 ?


> 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).

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

Reply to: