Hi all,

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ? That is, when mounting /var/cache/apt as seperate harddisk partition, later on - i'd like to keep the d/l packages for some time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22.10.18 10:02, Michael wrote:

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ?

/var contains huge amount of data that keep changing but must not be lost.

That is, when
mounting /var/cache/apt as seperate harddisk partition, later on - i'd
like to keep the d/l packages for some time.

you can store packages in /tmp by putting this to apt.conf:

Dir::Cache::archives "/tmp";


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Matus,

I don't totally need to make /var a tmpfs, it's just out of curiosity, and for the simplicity of configuration. Since /var/cache and /var/log are already tmpfs for me, and this extendet tmpfs setup works fine since at least 2 years, it seems to be
interesting to check the other top folders of /var for that option too.

On 22.10.18 10:02, Michael wrote:

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ?

/var contains huge amount of data that keep changing but must not be lost.

ok, but shouldn't /var contain no configuration-like files ? In other words, are these all files to read or are they just only re-created everytime, thus only to write ? If so, then perhaps could i live with some extra time for starting services / apps
to re-create things (if it's only within a second).

For example, here are my /var topfolders:

apt -> empty
backups -> write-only; and i did never need these in about 15 years, so i guess i can live without.
cache -> already tmpfs
lib -> don't know XXX
local -> empty
lock -> only a lockfile
log -> already tmpfs for me (if i ever need persistent logs, for specific reason, i'll just revert it. It's a desktop machine, rarely problems.)
mail -> don't need
opt -> empty
run -> already tmpf via Debian
spool -> cron/anacron, cups .... i guess, no need for persistent
tmp -> empty
www -> not used here

That leaves /var/lib as a main candidate for problems, because i don't know the usage of what is stored here.



ps. About /var/cache/apt, it is mounted as separate 5G partition. /tmp already is made tmpfs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

/var/lib contains a huge load of stuff that is not supposed to change
between boots, like dpkg's state (package selections), the calibration constants for the clock, etc.

In general, these days, putting any system partitions besides /var and /home (and maybe /boot) on a different device is just asking for problems without benefit. And the benefits of /var are slim, as Debian doesn't really support readonly rootfs well.

Cheers,

Sebastian



On Mon, Oct 22, 2018 at 03:37:45PM +0200, Michael wrote:

Matus,

I don't totally need to make /var a tmpfs, it's just out of curiosity, and for the simplicity of configuration. Since /var/cache and /var/log are already tmpfs for me, and this extendet tmpfs setup works fine since at least 2 years, it seems to be

interesting to check the other top folders of /var for that option too.

On 22.10.18 10:02, Michael wrote:

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ?

/var contains huge amount of data that keep changing but must not be lost.

ok, but shouldn't /var contain no configuration-like files ? In other words, are these all files to read or are they just only re-created everytime, thus only to write ? If so, then perhaps could i live with some extra time for starting services / apps

to re-create things (if it's only within a second).

For example, here are my /var topfolders:

apt -> empty
backups -> write-only; and i did never need these in about 15 years, so i guess i can live without.
cache -> already tmpfs
lib -> don't know XXX
local -> empty
lock -> only a lockfile
log -> already tmpfs for me (if i ever need persistent logs, for specific reason, i'll just revert it. It's a desktop machine, rarely problems.)
mail -> don't need
opt -> empty
run -> already tmpf via Debian
spool -> cron/anacron, cups .... i guess, no need for persistent
tmp -> empty
www -> not used here

That leaves /var/lib as a main candidate for problems, because i don't know the usage of what is stored here.

ps. About /var/cache/apt, it is mounted as separate 5G partition. /tmp already is made tmpfs.

--
Best regards, | Theoretische Physik 1, 02.573
Sebastian Kapfer | FAU Erlangen
| Staudtstr. 7, 91058 Erlangen, Germany
| Phone: +49.160.9577.6436
| https://theorie1.physik.fau.de/people/skapfer/
| GPG: ED891239B22DD0D516F2D9247554541B84406C3F

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEGj9D+P3to0vcF6iVw1egbnFSWecFAlvN3KMACgkQw1egbnFS WeeQcQ//a/VFhpcUqCwwugeuamL4RN+Nf0nVlzvcvVetoHOgM6109ESPSv+yEJtk 2RAwAucNIMajnzzlrukGU5Y+fFTlcnf22DuHHWygR00E94jVQj+ZvhGrZ1xFO75U DdkfyDzmMI2zXjOQRxGZjrE0+o/gdWjqTrLqcQ4H496I01wgOdj3iwNAVEdT0pzU k8BXYmCPcrx0FIOf70k/fmQ25XOVKBBir/1Q+V7BW7krQJRklLO6j2cmdr6ged9p HdQVRkJhudMZao5xrMys7rRSkim3rGPKhsTM3P0eVR+detBtfYDfFO1LNgZhFujU OLuBH6wbTM1uOjbHdYvFkN07yMTTgzIykrxG6dbHQg5folPz/aV3krvsXGV4oK4N sjyQf2gw/MAlg6W8k5ReW9h+wAizxwR56gkPzXoDduu51Qq8fMhtRD/maltVpPeE kIIbMD1ud13mg7B3N2Q599ibdlfvvB1Nd4PKDpDLvqzj0M8B4K3fqnsLNrtg9eFt
VFYYd

On 22.10.18 15:37, Michael wrote:

I don't totally need to make /var a tmpfs, it's just out of curiosity, and
for the simplicity of configuration. Since /var/cache and /var/log are already tmpfs for me, and this extendet tmpfs setup works fine since at
least 2 years, it seems to be interesting to check the other top folders
of /var for that option too.

On 22.10.18 10:02, Michael wrote:

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ?

/var contains huge amount of data that keep changing but must not be lost.

ok, but shouldn't /var contain no configuration-like files ? In other words, are these all files to read or are they just only re-created everytime, thus only to write ? If so, then perhaps could i live with some extra time for starting services / apps

to re-create things (if it's only within a second).

For example, here are my /var topfolders:

apt -> empty
backups -> write-only; and i did never need these in about 15 years, so i guess i can live without.
cache -> already tmpfs
lib -> don't know XXX

e.g. /var/lib/mysql where mysql databases reside. don't remove.
also /var/lib/dpkg contains information about installed packages. Don't
remove unlesas you want to seriously break your system.

local -> empty
lock -> only a lockfile
log -> already tmpfs for me (if i ever need persistent logs, for specific reason, i'll just revert it. It's a desktop machine, rarely problems.)
mail -> don't need
opt -> empty
run -> already tmpf via Debian
spool -> cron/anacron, cups .... i guess, no need for persistent

crontabs, mail queues, also something no to lose.

tmp -> empty

fiels stored there are temporary, but to be preserved across reboots.

That leaves /var/lib as a main candidate for problems, because i don't know the usage of what is stored here.

every time you install a package, it may use /var for something you wouldn't
be happy wen losing.
Simply said, don't use tmpfs for /var. Maybe concrete separate
subdirectories, but better none than sorry.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Matus, Sebastian ....

... understood :D


Well, ok, these are some good arguments.

I guess with modern large SSDs the whole thing became obsolete now, but i'm still on old hardware.

Actually, i've got a more basic question: If i configure large sizes, but are mostly unused - are these memory shares still no more available for normal RAM operations ?

ok, now i'm going to have /tmp, /var/cache and /var/log, and $HOME/.cache as tmpfs, as it works fine so far.

Then which option is better: One tmpfs for each (this is what i'm doing) or create one big tmpfs and create folders and symlinks ?

The first option needs safety size margin for every FS; while the latter could probably go with less in total ?

For example, i would have

/tmp ...... 3 G (large beause is used for many things, like d/l and extracting archives, to not bother the system HD)
$HOME/.cache ....... 2 G (mainly because googleearth cache, possibly zillions of aerial tiles. Recently turned out Gimp / GEGL are also doing large things.)
/var/cache .... 50 M (with my installation setup, seems to be enough, when /var/cache/apt is on HD)
/var/log ........ 50 M (more than enough if not persistent)

--------------------------------------------------------
Sum: About 5G.

But with only one big tmpfs and symlinks, i could probably go with just 3G total; because it's unlikely that i'll use all the space eaters a time; and if so, could empty caches anyway.

The disadvantage would be, needs to create folders and symlinks, with failsafe checks, in a boot script like rc.local, but then again, this seems to be rather trivial.

But this setup might get tricky, if something goes wrong (for example, booting into single mode).

Hmm, maybe i already answered my onw question here ... i'll symlink only $HOME/.cache, to (or is it: from?) /tmp/cache-user or so. Seems to be a safe bet ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Although I have always allocated enormous elbow room for the ever growing /var recently I don't need near so much sprawl in the slice. Would you guess that the kernel is now cleaning up its own cruft? Guess that 2G should do it in a day and age when you can buy 500 G SSD for less than $100? Completamente Nueva?

Enjoy the deflation! But that is sad about Barbie losing her friends!
:(



Ciao!
///
//////// |(°) . \\\
//////// - | : \\\\
//////// - | : \\\\
//////// |(°) ' \\\
///


---- Matus UHLAR - fantomas <uhlar@fantomas.sk> wrote:

=============
On 22.10.18 15:37, Michael wrote:

I don't totally need to make /var a tmpfs, it's just out of curiosity, and
for the simplicity of configuration. Since /var/cache and /var/log are already tmpfs for me, and this extendet tmpfs setup works fine since at
least 2 years, it seems to be interesting to check the other top folders
of /var for that option too.

On 22.10.18 10:02, Michael wrote:

Recently made a lot of stuff tmpfs (like /tmp and /var/cache and $HOME/.cache) and i'm not sure about this ...:

Is there any reason why /var cannot be completely tmpfs ?

/var contains huge amount of data that keep changing but must not be lost.

ok, but shouldn't /var contain no configuration-like files ? In other words, are these all files to read or are they just only re-created everytime, thus only to write ? If so, then perhaps could i live with some extra time for starting services / apps

to re-create things (if it's only within a second).

For example, here are my /var topfolders:

apt -> empty
backups -> write-only; and i did never need these in about 15 years, so i guess i can live without.
cache -> already tmpfs
lib -> don't know XXX

e.g. /var/lib/mysql where mysql databases reside. don't remove.
also /var/lib/dpkg contains information about installed packages. Don't
remove unlesas you want to seriously break your system.

local -> empty
lock -> only a lockfile
log -> already tmpfs for me (if i ever need persistent logs, for specific reason, i'll just revert it. It's a desktop machine, rarely problems.)
mail -> don't need
opt -> empty
run -> already tmpf via Debian
spool -> cron/anacron, cups .... i guess, no need for persistent

crontabs, mail queues, also something no to lose.

tmp -> empty

fiels stored there are temporary, but to be preserved across reboots.

That leaves /var/lib as a main candidate for problems, because i don't know the usage of what is stored here.

every time you install a package, it may use /var for something you wouldn't
be happy wen losing.
Simply said, don't use tmpfs for /var. Maybe concrete separate
subdirectories, but better none than sorry.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23/10/18 2:37 AM, Michael wrote:

log -> already tmpfs for me (if i ever need persistent logs, for specific reason, i'll just revert it. It's a desktop machine, rarely problems.)

To me, logs are generally useful when I didn't know in advance I was
going to need them. Like, perhaps, after a crash.

If I don't need them persistent, then I probably don't need them at all.

Richard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard,

If I don't need them persistent, then I probably don't need them at all.

You are right. I deinstalled syslog long time ago ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)