Re: [nslu2-linux] SlugOS 5.3: /var/volatile same as ramfs?
- Jan wrote:
> Bump :)Unnecessary with recent SlugOS releases, including 5.3-beta.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of obi_jan
> Sent: Tuesday, June 09, 2009 2:32 PM
> To: firstname.lastname@example.org
> Subject: [nslu2-linux] SlugOS 5.3: /var/volatile same as ramfs?
> As previously mentioned, I just advanced from SlugOS 3.10 to 5.3 and am
> exploring this new world. Being a creature of habit, I immediately started
> setting it up the same way I did under 3.10. In that regard, I always used
> to apply the method to move /dev and /var to a ramfs, as described further
> down in this Wiki article here:
> The rationale behind this is to minimize the writes to the memstick I amYes. The major difference is that the "volatiles" mechanism is managed
> booting off. However, I realized that in 5.3, most sub directories in the
> /var tree actually reside in /var/volatile (sym-linked). After further
> reading online and in this forum, I have come to the conclusion that
> /var/volatile is in fact already an in-memory filesystem, is that correct?
by a startup script and a config directory. This allows fine-grained
control over what is in RAM, vs what is persistent. Read the comments
in the "volatiles" file in /etc/default/ for details for your
configuration. (The configuration is selected based on how you did the
"turnup" command (turnup memstick vs turnup disk, for example) -- in
addition to selecting a different syslogd configuration, turnup also
selects different volatiles configurations.)
> How much memory does it take away from the RAM, and do I now need to employHow much RAM it takes depends solely on how much you store in the
> log rotation and archiving strategies to make sure the volatile fs never
> fills up?
filesystem, but it will not exceed 1/2 of the physical memory available
(which works out to 16MB on an unmodified slug). It is commonly abuse
of the /tmp directory that will fill up the space, so it is not usually
necessary to rotate logs and all that. But feel free to do so if you wish.
>Correct. And it will be cached in any case, so unlikely to cause any
> Also, is it still worthwhile to try to move /dev to a separate ramfs to
> further minimize access to it? I guess it's not necessary, as the access to
> /dev is mostly read-only, which is not a problem for solid state memory, is
> that correct?
> Under 3.10, I was actually booting off an external HDD, so itI'm glad you won't be going down that path any longer; spindown of HDDs
> was important for me to minimize both reads and writes to it to allow for it
> to spin down after some idle time.
is a bad solution to whatever it is the real problem might be, and in
the end it solves nothing. If you cannot live with a spinning HD, then
a solid-state device (USB memory stick or even an SSD) is the better