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