Hi, On Mon, Mar 10, 2003 at 11:19:39PM +0100, Jeremie Koenig wrote: > On Mon, Mar 10, 2003 at 09:23:42PM +0100, Emile van Bergen wrote: > > > I think that there is a whole class of problems that would benefit from > > /mem; every small file whose contents are only valid in the context of > > the currently running kernel, which must now be explicitly cleaned at > > startup. > > > > I.e. everything that refers to processes (locks and pidfiles), network > > interfaces (ifstate), mounted filesystems (mtab), nfs export states, > > etc. etc. > > Well, I think this boils down to splitting /var in two pieces : sharable and > non-sharable between systems (is this what you mean ?). I think it would > make sense and be useful. Storing the non-sharable part in a ramdisk > seems reasonable and a good default for most situation. But the > underlying media should only be required to have some properties (being > mountable early in the boot process, for instance). Shared vs. non-shared is not the point; everything may currently assume /var is non-shared and I see little benefit in making it possible to share parts by splitting /var into a shareable and non-shareable part. (To avoid confusion: "shared, ie. used by multiple machines" and "mounted over the network" have very little to do with each other). The point is that /mem is writable early in any storage scenario, even with no writable local filesystems, even with a read-only NFS root and /var not yet mounted because it resides on a different network, which we can access only after doing ifup. If you go for a /earlywritable that must be on real storage during normal operation, it may initially still have to be on an in-memory filesystem in order to satisfy the early writable requirement, so that the contents must be copied, the directory unmounted, removed and subsequently symlinked during the startup procedure to satisfy the requirement that it is on real storage during normal operation. The word "brittle" springs to mind here. All this trouble, different per storage scenario, just to get a directory of which the sole distinguising property is that it is writable before /var, is not worth it IMHO. There is only very little work that needs something writable before /var itself is mounted read/write. I assert that it is always OK for a writable directory that is used for this work to be small and held in main memory. I assert that a directory that is held in main memory during normal operation is useful. It is useful because it has the property that it is guaranteed to be cleared on startup, which makes it better suited than /var for things that are now cleared manually. A small in-memory filesystem has the property that it won't spin up your disks, so a laptop administrator can move things that are frequently written to there, even if they must be preserved across reboots if you add a cp as part of your startup- and shutdown procedures -- as long as they are not important enough to be preserved if the system crashes. An in-memory filesystem has the property that it's fast, so if you have the memory available, you can create a /mem/tmp and set TMPDIR to it before running TMPDIR-intensive things such as sort(1) or cc(1). > > That you can make /mem available immediately when the kernel is up and > > you can access /bin/mount is basically just a nice bonus that happens to > > solve the writable-ifstate-before-networked-var-online problem. > > I think i'm starting to get the point. Let's have a try : > > We want a directory that hold file that need to be changed automatically > by the system, just as /var does. However, it would contain the part of > /var that is directly related to the local system and can't be shared. I hope you aren't using "shared" as "networked", although I'm starting to worry that you do. By definition, /var holds machine-specific data and therefore cannot be shared. Of course it can still be mounted over NFS. The point is that /earlywritable can not be networked on a network that requires ifup. That's the reason why you'd need it on a local disk or a writable NFS root. It has nothing to do with it being shared or not. [SNIP] > > /mem is a simple, general thing with an easily defined lifecycle, an > > obvious name (resides in memory, part of it is preserved) and is IHMO a > > useful addition to any *n*x. > > > > And, it solves the ifstate problem in a cleaner way than copying parts > > of /var between different flavours of /var during startup/shutdown. No > > copying is needed and the semantics are very clear: > > > > * mounted (readwrite) as soon as possible > > * as soon as /var is available, a cp -Rp /var/mem /mem is done > > * at shutdown, a cp -Rp /mem/preserve /var/mem/preserve is done > > Well, the "resides in memory" part still sounds bad for me. I agree that > it would be meaningful to require /mem (or whatever it sould be called, > that's not the problem) to be storable onto a ramdisk. I don't think it > would be fair to require it to _be_ stored in memory. Why? It's not required, but a natural match, and it's handy if you know a certain directory to be on a memory fs. I agree that the only required properties for something that's useful for ifstate, pidfiles, locks, mtab, temporary fifos, sockets, et al. are that it's * writable early, before /var is online; * always cleared at bootup - at least part of it. However, if you look at a few other desireable properties of a directory that's always on a memory fs: * not dependent any writable local disks; * not dependent on a writable (NFS) root filesystem; * all writable real filesystems directories may be on networks that use ifup and therefore need a writable ifstate; * part of it is saved at shutdown, a possibly larger part restored at startup; * you get a directory that is known to be fast and to generate no I/O if it exists, regardless of your storage configuration. > Maybe swapping the preseved/volatile parts may be meaningful, too : > - /mem/volatile (or something) is not preserved. > - anything else in /mem is > This way it would be possible to mount a ramdisk/shmfs into > /mem/volatile, and leave /mem in the root filesystem. Since everything > readonly until disks have been checked is not a big problem, /mem > readonly until / has been checked shouldn't be one either. It's not a big problem, but it does require you to make / readwrite eventually, quite early even. Mounting shmfs on /mem allows you to have a writable filesystem before and while / is checked or repaired. I see your point, but I see volatile as the rule here, and preserved as the exception. Also, a /mem of which only /mem/volatile is indeed in main memory is named a bit inappropriately IMHO. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgp5ZBJM5kEMP.pgp
Description: PGP signature