On 07 Nov 2006 12:30 PM or thereabouts, Roy Marples wrote: > On Tuesday 07 November 2006 11:56, Roy Marples wrote: > > A net benefit of this is that we would could remove around 60 lines of code > > which handle the moving of $svcdir to disk whilst the system is active > > (handles locking, timeouts, nice messages, etc) > > Attached is the patch that does this and shows exactly what's involved here. > As you can see, the code that currently handles the locking, saving back to > disk, and stuff is very hairy. So this would be a good argument for the > $svcdir always on a ramdisk option.
Yeah, I've tried to write patches that allow disk placement of service state in /var, without damaging too many 'what if' use cases, and they are pretty damn ugly at the moment. Maybe the future will lend the required brillance. Actually, Debian has started to take this ramdisk approach as well, with a tmpfs filesystem mounted on '/lib/init/rw'. They're not maintaining service state, but other boot and shutdown tmpfiles and device nodes. The only configuration var is for configuration of the ramdisk size. A var to allow ramdisk size tweaking on memory constrained systems (256K?), or systems will *huge* deptrees (4M?) would be nice. 1M looks like a good default. I still think the location is unfortunate (and actually prefer something like /etc/init.d/state, even as a ramdisk), but the technical issues you raise are real, and you've got a working solution... so thanks for listening to the other arguments. --Matthew [EMAIL PROTECTED] -- [email protected] mailing list
