SlugOS 5.3: /var/volatile same as ramfs?

[Jan-116]

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: http://www.nslu2-linux.org/wiki/FAQ/SpinDownUSBHarddisks

The rationale behind this is to minimize the writes to the memstick I am 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? How much memory does it take away from the RAM, and do I now need to employ log rotation and archiving strategies to make sure the volatile fs never fills up?

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 it was important for me to minimize both reads and writes to it to allow for it to spin down after some idle time.

Jan

[Jan-116]

Bump :)

-----Original Message-----
From: nslu2-linux@... [mailto:nslu2-linux@...] On
Behalf Of obi_jan
Sent: Tuesday, June 09, 2009 2:32 PM
To: nslu2-linux@...
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:
http://www.nslu2-linux.org/wiki/FAQ/SpinDownUSBHarddisks

The rationale behind this is to minimize the writes to the memstick I am
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?
How much memory does it take away from the RAM, and do I now need to employ
log rotation and archiving strategies to make sure the volatile fs never
fills up?

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 it
was important for me to minimize both reads and writes to it to allow for it
to spin down after some idle time.

Jan

[Mike Westerhof (mwester)]

Jan wrote:

> Bump :)
>
> -----Original Message-----
> From: nslu2-linux@... [mailto:nslu2-linux@...] On
> Behalf Of obi_jan
> Sent: Tuesday, June 09, 2009 2:32 PM
> To: nslu2-linux@...
> 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:
> http://www.nslu2-linux.org/wiki/FAQ/SpinDownUSBHarddisks

Unnecessary with recent SlugOS releases, including 5.3-beta.

> The rationale behind this is to minimize the writes to the memstick I am
> 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?

Yes.  The major difference is that the "volatiles" mechanism is managed
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 employ
> log rotation and archiving strategies to make sure the volatile fs never
> fills up?

How much RAM it takes depends solely on how much you store in the
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.

>
> 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?

Correct.  And it will be cached in any case, so unlikely to cause any
real concern.

> Under 3.10, I was actually booting off an external HDD, so it
> was important for me to minimize both reads and writes to it to allow for it
> to spin down after some idle time.

I'm glad you won't be going down that path any longer; spindown of HDDs
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
choice. :)

-Mike (mwester)