Hi, On Wed, Mar 12, 2003 at 11:01:20AM -0600, Steve Langasek wrote: > On Wed, Mar 12, 2003 at 03:47:47PM +0100, Emile van Bergen wrote: > > > > - need to put info somewhere that doesn't have to be kept between > > > boots? /var/run > > > - same but need it before /var is mounted? /run > > > - same but need it even when / is read-only ? /run, setup by the > > > sysadmin to be on a tmpfs > > > So what do I do when I'm writing an application or script that likes to > > use a ram-based fs if any is available? Test for /dev/shm first, then > > see if we're lucky enough to be on a system that has /run on tmpfs, > > otherwise bug the admin to create a separate tmpfs? It's messy, and > > requires each application to do these tests in order to take advantage > > of an already mounted tmpfs. > > In Debian, the answer is: none of the above. You should not be > second-guessing the admin's storage decisions. For that matter, we > shouldn't be shipping code that's so badly written that it doesn't > work right with non-memory-based filesystems. Completely true. That's also why I never said /mem is *required* to be memory-based, only likely to be so. Code that can only work if /mem is indeed in RAM instead of just mmap'able and writable is indeed very much broken, and I can't even imagine right now how to do it on purpose ;-) > > Again, your proposal is fine, but I still think offering a generic > > ram-based fs is more elegant. > > It is not elegant, it's second-guessing the admin. On the contrary, if applications categorize their data according to likely persistance and volatility, it allows the admin to make better storage decisions. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpWOFrfTxf22.pgp
Description: PGP signature