Discussion:
Distribute slackware between hdd and ssd
(too old to reply)
John Forkosh
2019-06-23 10:24:03 UTC
Permalink
My five-year-old 2TB seagate barracuda just died (s.m.a.r.t. check
failure indicating imminent death), rip, so I'm replacing it with
a 6TB hdd and adding a 1TB sandisk ssd. The intent, of course,
of the new ssd is basically to put slackware on the ssd, with
/home and other data symlinked to partitions/directories on the hdd.

But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with
other ssd specs. So it seems wise to symlink /tmp and /var to the
hdd as well.

But I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
Not exactly sure why, but there it is.

So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Clearly /home and /tmp and /var like I mentioned above.
But also clearly some other not-so-obvious stuff.
So what's the best way to distribute slackware between a
"primary" (so to speak) partition on the ssd, and all volatile
stuff symlinked to the hdd, with the intent of minimizing
ssd writes?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John McCue
2019-06-23 14:41:46 UTC
Permalink
John Forkosh <***@panix.com> wrote:
<snip>
Post by John Forkosh
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Clearly /home and /tmp and /var like I mentioned above.
But also clearly some other not-so-obvious stuff.
So what's the best way to distribute slackware between a
"primary" (so to speak) partition on the ssd, and all volatile
stuff symlinked to the hdd, with the intent of minimizing
ssd writes?
I cannot think of any others, but you should add 'noatime'
to your /etc/fstab. But that may be a default anyway
on all mounts unless you specify 'atime'. The man is a
but confusing with 'diratime', so I would add 'noatime'
anyway to all mounts :)

John
John Forkosh
2019-06-27 09:29:31 UTC
Permalink
Post by John McCue
<snip>
Post by John Forkosh
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Clearly /home and /tmp and /var like I mentioned above.
But also clearly some other not-so-obvious stuff.
So what's the best way to distribute slackware between a
"primary" (so to speak) partition on the ssd, and all volatile
stuff symlinked to the hdd, with the intent of minimizing
ssd writes?
I cannot think of any others, but you should add 'noatime'
to your /etc/fstab. But that may be a default anyway
on all mounts unless you specify 'atime'. The man is a
but confusing with 'diratime', so I would add 'noatime'
anyway to all mounts :)
John
Thanks. Done. Now that you've mentioned it, I recall a lengthy
relatime vs noatime discussion somewhere (usenet, stackexchange,
god-knows-where). But it had slipped my mind until you
mentioned it again. My disks thank you, too.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
dillinger
2019-06-23 17:40:10 UTC
Permalink
Post by John Forkosh
My five-year-old 2TB seagate barracuda just died (s.m.a.r.t. check
failure indicating imminent death), rip, so I'm replacing it with
a 6TB hdd and adding a 1TB sandisk ssd. The intent, of course,
of the new ssd is basically to put slackware on the ssd, with
/home and other data symlinked to partitions/directories on the hdd.
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with
other ssd specs. So it seems wise to symlink /tmp and /var to the
hdd as well.
But I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
Not exactly sure why, but there it is.
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Clearly /home and /tmp and /var like I mentioned above.
But also clearly some other not-so-obvious stuff.
So what's the best way to distribute slackware between a
"primary" (so to speak) partition on the ssd, and all volatile
stuff symlinked to the hdd, with the intent of minimizing
ssd writes?
Why not use fstab instead of symlinking?
Also, if you move all of that to your hdd you would end up using at most
15G of the 1000G on your ssd, ever, is that what you want?
Henrik Carlqvist
2019-06-24 21:04:37 UTC
Permalink
I'm replacing it with a 6TB hdd and adding a 1TB sandisk ssd. The
intent, of course, of the new ssd is basically to put slackware on the
ssd, with /home and other data symlinked to partitions/directories on
the hdd.
As dillinger said, instead of using symlinks it would be better to use
fstab to point out different partitions on the two drives.
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with other ssd
specs. So it seems wise to symlink /tmp and /var to the hdd as well.
So far I have not seen much problems with SSDs being worn out and I don't
use any special mount options for SSD drives.

For performance reasons I would instead choose to put partitions with
much writing on the SSD. But if you are really paranoid about loosing
your data in a SSD crash you might want to limit this to unimportant
partitions like swap, /tmp and /var/tmp.

regards Henrik
John Forkosh
2019-06-27 05:19:38 UTC
Permalink
Post by Henrik Carlqvist
I'm replacing it with a 6TB hdd and adding a 1TB sandisk ssd. The
intent, of course, of the new ssd is basically to put slackware on the
ssd, with /home and other data symlinked to partitions/directories on
the hdd.
As dillinger said, instead of using symlinks it would be better to use
fstab to point out different partitions on the two drives.
Actually, he said "why not...?"; i.e., he didn't say "better".
Do you have an actual "better" reason???
Seems about the same to me, since either way you have to wait
for the partition to be mounted (see below) via its fstab entry.
And for my purposes, I don't feel like dedicating a whole partition
to one directory. So my / typically has a symlink /aux --> /mnt/sdb1/slack/
where "sdb1" is some partition on the hdd on which I've mkdir slack.
Then, to move, say, /root over there I just rsync a copy of /root/
to /aux/root/, then mv root root_orig just to save the original,
and finally symlink /root --> /aux/root/ And then I can do more
or less the same for other directories like /tmp and /home .
So they all go under the one slack/ directory on the one sdb1 partition.
And since I usually have three or four separate bootable installs
by the time a box gets retired, all their hdd stuff can go under
separate "aux" directories on that one sdb1 partition.
Very much neater than mounting a separate partition for each
and every / directory for each and every bootable install.
Post by Henrik Carlqvist
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with other ssd
specs. So it seems wise to symlink /tmp and /var to the hdd as well.
So far I have not seen much problems with SSDs being worn out and I don't
use any special mount options for SSD drives.
For performance reasons I would instead choose to put partitions with
much writing on the SSD. But if you are really paranoid about loosing
your data in a SSD crash you might want to limit this to unimportant
partitions like swap, /tmp and /var/tmp.
regards Henrik
Yeah, I did that (as described above) for /var/tmp, but as you
seem to implicitly recognize, I can't do that for the entire /var
since various /var/log/ files like dmesg are written before other
partitions are mounted. (I knew that beforehand, but asked the
question naively just to separate out ignorable replies that
didn't mention it at all.)
And I've tried-but-failed to figure a way around that.
I'd like, say, to symlink /var "with the exception of" /var/log/,
or something like that. You know a way to do that, or some other
mechanism to accomplish the same kind of purpose?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2019-06-27 06:12:57 UTC
Permalink
Post by John Forkosh
Post by Henrik Carlqvist
As dillinger said, instead of using symlinks it would be better to use
fstab to point out different partitions on the two drives.
Actually, he said "why not...?"; i.e., he didn't say "better".
Do you have an actual "better" reason???
You will get slightly better performance with mounted partitions instead
of symlinks. For each opening of a file you will need to open and parse
the contents of the symlink when given an absolute path. Example of a
symlink on Slackware: /var/adm is a symlink pointing to /var/log.

strace -T cat /var/log/debug | & grep debug | grep open
open("/var/log/debug", O_RDONLY) = -1 EACCES (Permission denied)
<0.000005>

strace -T cat /var/adm/debug | & grep debug | grep open
open("/var/adm/debug", O_RDONLY) = -1 EACCES (Permission denied)
<0.000006>

Several runs of those commands will give different times but mostly you
will see that it is a little slower to use the symlink path.
Post by John Forkosh
Seems about the same to me, since either way you have to wait for the
partition to be mounted (see below) via its fstab entry.
Unless you use automount which you probably do not for local drives the
mounting of all partitions will only be done once for each boot.
Post by John Forkosh
Yeah, I did that (as described above) for /var/tmp, but as you seem to
implicitly recognize, I can't do that for the entire /var since various
/var/log/ files like dmesg are written before other partitions are
mounted.
There is no problem having entire /var mounted on its own partition, in
fact I do:

cat /etc/fstab
/dev/sda2 swap swap defaults 0 0
/dev/sda1 / ext4 defaults 1 1
/dev/sda5 /usr ext4 defaults 1 2
/dev/sda6 /opt ext4 defaults 1 2
/dev/sda7 /var ext4 defaults 1 2
/dev/sda8 /tmp ext4 defaults 1 2
/dev/sda9 /home ext4 defaults 1 2
/dev/sda10 /var/images ext4 defaults 1 2
/dev/sda11 /usr/local ext4 defaults 1 2
/dev/cdrom /mnt/cdrom auto noauto,user,ro,comment=x-
gvfs-show 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0

Looking at the startup scripts you will see that /var/log/dmesg is
written in /etc/rc.d/rc.M which is called after /etc/rc.d/rc.S which
mounts the partitions listed in fstab.

regards Henrik
John Forkosh
2019-06-27 09:14:58 UTC
Permalink
Post by Henrik Carlqvist
Post by John Forkosh
Post by Henrik Carlqvist
As dillinger said, instead of using symlinks it would be better to use
fstab to point out different partitions on the two drives.
Actually, he said "why not...?"; i.e., he didn't say "better".
Do you have an actual "better" reason???
You will get slightly better performance with mounted partitions instead
of symlinks. For each opening of a file you will need to open and parse
the contents of the symlink when given an absolute path. Example of a
symlink on Slackware: /var/adm is a symlink pointing to /var/log.
strace -T cat /var/log/debug | & grep debug | grep open
open("/var/log/debug", O_RDONLY) = -1 EACCES (Permission denied)
<0.000005>
strace -T cat /var/adm/debug | & grep debug | grep open
open("/var/adm/debug", O_RDONLY) = -1 EACCES (Permission denied)
<0.000006>
Thanks for the additional info (especially about /var below).
I'm happy with the "time penalty"-versus-"convenience benefit" trade-off,
at least for my personal-workstation purposes. So you've basically
just confirmed my procedure (again, for my purposes), which is
useful to know.
Post by Henrik Carlqvist
Several runs of those commands will give different times but mostly you
will see that it is a little slower to use the symlink path.
Post by John Forkosh
Seems about the same to me, since either way you have to wait for the
partition to be mounted (see below) via its fstab entry.
Unless you use automount which you probably do not for local drives the
mounting of all partitions will only be done once for each boot.
Post by John Forkosh
Yeah, I did that (as described above) for /var/tmp, but as you seem to
implicitly recognize, I can't do that for the entire /var since various
/var/log/ files like dmesg are written before other partitions are
mounted.
There is no problem having entire /var mounted on its own partition, in
cat /etc/fstab
/dev/sda2 swap swap defaults 0 0
/dev/sda1 / ext4 defaults 1 1
/dev/sda5 /usr ext4 defaults 1 2
/dev/sda6 /opt ext4 defaults 1 2
/dev/sda7 /var ext4 defaults 1 2
/dev/sda8 /tmp ext4 defaults 1 2
/dev/sda9 /home ext4 defaults 1 2
/dev/sda10 /var/images ext4 defaults 1 2
/dev/sda11 /usr/local ext4 defaults 1 2
/dev/cdrom /mnt/cdrom auto noauto,user,ro,comment=x-
gvfs-show 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
Yeah, that's way too many partitions when you have several
bootable installs on the same box, although /home is the same
for them all in my case. I only need
/dev/sdb8 swap swap defaults 0 0
/dev/sda1 / ext4 defaults,noatime 1 1
/dev/sdb1 /mnt/sdb1 ext4 defaults,noatime 1 0
with slack initially installed on /dev/sda1, and stuff you have
separately mounted all subsequently symlinked to subdirectories
in a directory slk150x64sda1/ on my mount point /mnt/sdb1/
ls -al /mnt/sdb1/
drwx------ 2 root root 16384 Jun 24 23:46 lost+found
drwxr-xr-x 6 root root 4096 Jun 27 04:15 slk150x64sda1
ls -al /mnt/sdb1/slk150x64sda1/
drwxr-xr-x 6 root root 4096 Jun 26 02:56 home
drwxrwxrwt 8 root root 4096 Jun 27 04:36 tmp
drwxr-xr-x 17 root root 4096 Jun 27 04:18 var
and ls -al / containing the symlinks
lrwxrwxrwx 1 root root 24 Jun 26 02:09 slk150x64sda1 ->
/mnt/sdb1/slk150x64sda1/
lrwxrwxrwx 1 root root 20 Jun 26 02:15 home -> /slk150x64sda1/home/
lrwxrwxrwx 1 root root 19 Jun 27 04:19 tmp -> /slk150x64sda1/tmp/
lrwxrwxrwx 1 root root 19 Jun 27 04:17 var -> /slk150x64sda1/var/
And that could go on for as many more directories as I want
to "offload" from the /dev/sda ssd onto the /dev/sdb hdd.
Post by Henrik Carlqvist
Looking at the startup scripts you will see that /var/log/dmesg is
written in /etc/rc.d/rc.M which is called after /etc/rc.d/rc.S which
mounts the partitions listed in fstab.
regards Henrik
Great! Thanks. As you can see above from that var--> symlink,
I already took advantage of your info, and it indeed reboots
just fine, with dmesg and everything else in /var/log/ containing
everything it/they should. Don't recall where I got my earlier
incorrect info from, but in this case it's good to be wrong.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Chris Vine
2019-06-27 11:47:46 UTC
Permalink
On Thu, 27 Jun 2019 06:12:57 -0000 (UTC)
Henrik Carlqvist <***@deadspam.com> wrote:
[snip]
Post by Henrik Carlqvist
cat /etc/fstab
/dev/sda2 swap swap defaults 0 0
/dev/sda1 / ext4 defaults 1 1
/dev/sda5 /usr ext4 defaults 1 2
/dev/sda6 /opt ext4 defaults 1 2
/dev/sda7 /var ext4 defaults 1 2
/dev/sda8 /tmp ext4 defaults 1 2
/dev/sda9 /home ext4 defaults 1 2
/dev/sda10 /var/images ext4 defaults 1 2
/dev/sda11 /usr/local ext4 defaults 1 2
/dev/cdrom /mnt/cdrom auto noauto,user,ro,comment=x-
gvfs-show 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
Looking at the startup scripts you will see that /var/log/dmesg is
written in /etc/rc.d/rc.M which is called after /etc/rc.d/rc.S which
mounts the partitions listed in fstab.
What a strange approach.

I can see the point of having a separate partition for the /home
directory in addition to a partition for the root directory, because
that might possibly make upgrading the OS easier, but all the the other
partitions on the same disk (/dev/sda) seem pointless. In fact, they
are counter-productive because you can fill up one partition when you
have plenty of space on another which could be used instead.

(The only directory other than /home which I might put on its own
partition is /etc, again for ease of upgrading, but you do not do that.)
Henrik Carlqvist
2019-06-27 19:09:09 UTC
Permalink
Post by Chris Vine
What a strange approach.
I can see the point of having a separate partition for the /home
directory in addition to a partition for the root directory, because
that might possibly make upgrading the OS easier, but all the the other
partitions on the same disk (/dev/sda) seem pointless. In fact, they
are counter-productive because you can fill up one partition when you
have plenty of space on another which could be used instead.
Yes, some partitions like /tmp and /var might get filled without
affecting important partitions like /. I consider that to be a plus.
Another reason for me splitting up the file system in different
partitions is that I separate big partitions like /usr and /home from
write intensive partitions like /tmp and /var. At a power outage you
might get a broken file system and this will more likely happen to a
partition with much writing.
Post by Chris Vine
(The only directory other than /home which I might put on its own
partition is /etc, again for ease of upgrading, but you do not do that.)
As far as I know it is not possible to have /etc on its own partition.
Unless you have it on your root partition you will get trouble booting as
the boot process will need things like /etc/inittab and /etc/rc.d. But
maybe this information is old school knowledge no longer valid for people
using initrd.

regards Henrik
c***@gmail.com
2019-07-04 03:11:15 UTC
Permalink
Post by Henrik Carlqvist
Post by Chris Vine
What a strange approach.
I can see the point of having a separate partition for the /home
directory in addition to a partition for the root directory, because
that might possibly make upgrading the OS easier, but all the the other
partitions on the same disk (/dev/sda) seem pointless. In fact, they
are counter-productive because you can fill up one partition when you
have plenty of space on another which could be used instead.
Yes, some partitions like /tmp and /var might get filled without
affecting important partitions like /. I consider that to be a plus.
Another reason for me splitting up the file system in different
partitions is that I separate big partitions like /usr and /home from
write intensive partitions like /tmp and /var. At a power outage you
might get a broken file system and this will more likely happen to a
partition with much writing.
Post by Chris Vine
(The only directory other than /home which I might put on its own
partition is /etc, again for ease of upgrading, but you do not do that.)
As far as I know it is not possible to have /etc on its own partition.
Unless you have it on your root partition you will get trouble booting as
the boot process will need things like /etc/inittab and /etc/rc.d. But
maybe this information is old school knowledge no longer valid for people
using initrd.
regards Henrik
You should consider using LVM. If you have questions, I normally look at https://www.linuxquestions.org/questions/slackware-14/ MUCH more often than I look at USENET groups.

LVM is a software layer that solves more problems than it creates; at least in my use cases.
Henrik Carlqvist
2019-07-04 06:40:33 UTC
Permalink
Post by c***@gmail.com
LVM is a software layer that solves more problems than it creates; at
least in my use cases.
I have not yet seen any need for LVM. I am aware that you with LVM can
grow file systems, but so far I have not had any need for that. This is
what my mounted partitions look like:

Filesystem Size Used Avail Use% Mounted on
/dev/root 1.2G 650M 424M 61% /
devtmpfs 7.8G 0 7.8G 0% /dev
tmpfs 7.8G 1.3M 7.8G 1% /run
tmpfs 7.8G 569M 7.3G 8% /dev/shm
cgroup_root 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/sda5 29G 14G 14G 51% /usr
/dev/sda6 6.7G 1.3G 5.0G 21% /opt
/dev/sda7 9.5G 3.5G 5.6G 39% /var
/dev/sda8 7.6G 1.4G 5.9G 19% /tmp
/dev/sda9 148G 124G 17G 88% /home
/dev/sda10 158G 60M 150G 1% /var/images
/dev/sda11 104G 18G 80G 19% /usr/local
cgmfs 100K 0 100K 0% /run/cgmanager/fs
sauron:/volume1/homes 3.6T 1.4T 2.3T 37% /net/sauron/volume1/homes

Disk is rather cheap these days so the ones that might get filled are
rather big (/tmp ~8GB, /var ~10GB). If those still get filled there is
some other problem than the partition being too small.

/var/images was used for disk images used with qemu. I moved out from
that partition to a NAS mostly as I wanted to have those images on a
RAID1 disk. One day the home partition might get filled, but that day I
will simply create a newer bigger partition and move home to that.

regards Henrik
Sylvain Robitaille
2019-07-18 16:13:14 UTC
Permalink
Post by Henrik Carlqvist
Yes, some partitions like /tmp and /var might get filled without
affecting important partitions like /. I consider that to be a plus.
I think that one of the key factors that causes some of us to see
things this way, and others to prefer the bulk of the installation
to be on a single disk (with the perceived convenience of not having
any single partition run out of space until the entire disk is out
of space), is experience managing multi-user systems where the users
might (accidentally or otherwise) cause havoc by filling a filesystem
they can write to.
Post by Henrik Carlqvist
As far as I know it is not possible to have /etc on its own partition.
Agreed ...
Post by Henrik Carlqvist
Unless you have it on your root partition you will get trouble booting
as the boot process will need things like /etc/inittab and /etc/rc.d.
But maybe this information is old school knowledge no longer valid for
people using initrd.
Oh yeah ... initrd ... I suppose, but I don't understand what would
be gained by moving /etc to a separate partition.

In my own case, protection from being filled by unprivileged processes
is one consideration for separating certain directories into their
own partitions. Another, perhaps more important, is the ability to
use different mount options. I don't want device (or setuid) files
popping up in user-writable directories (they can still "pop up"
mind you, but you can make the kernel no honour them), and I don't
need executable files in /var, for example. /usr is read-only so its
contents won't be "accidentally" replaced. None of this is fool-proof,
of course, but it certainly helps make compromise more difficult.
Just another thing to keep in mind when considering whether or not
to split things into individual partitions.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Henrik Carlqvist
2019-07-18 19:45:49 UTC
Permalink
Another, perhaps more important, is the ability to use different mount
options. I don't want device (or setuid) files popping up in
user-writable directories (they can still "pop up" mind you, but you can
make the kernel no honour them), and I don't need executable files in
/var, for example. /usr is read-only so its contents won't be
"accidentally" replaced.
Good thinking. I knew that one of the ideas of having /usr on its own
partition is that it can be read-only, but for convinience I mount also
/usr rw to easily run upgradepkg from a cron job which installs patches.

regards Henrik
Sylvain Robitaille
2019-07-25 21:15:39 UTC
Permalink
Post by Henrik Carlqvist
Good thinking. I knew that one of the ideas of having /usr on its own
partition is that it can be read-only, but for convinience I mount
also /usr rw to easily run upgradepkg from a cron job which installs
patches.
It's only slightly less convenient to wrap upgradepkg in a script
that first remounts /usr read-write, runs upgradepkg, restarts any
services that rely on upgraded files, then remounts /usr read-only.

I say "slightly less convenient", but full disclosure dictates that I
admit to having only the first two of those steps scripted, followed
by an attempt to remount /usr read-only which fails if any services
are holding deleted files open, in which case I *manually* locate
and restart those services and remount /usr. About half the time,
/usr just remounts and I don't need to do anything more, though.

It's not perfect, and yes, if I wasn't so lazy I would work out
scripting finding the services that need to be restarted. Still,
ultimately, we have to choose where we trade off (hopefully healthy)
paranoia versus convenience, but hopefully I've given some folks some
ideas they hadn't considered.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Steve555
2019-06-27 00:37:14 UTC
Permalink
Post by John Forkosh
My five-year-old 2TB seagate barracuda just died (s.m.a.r.t. check
failure indicating imminent death), rip, so I'm replacing it with
a 6TB hdd and adding a 1TB sandisk ssd. The intent, of course,
of the new ssd is basically to put slackware on the ssd, with
/home and other data symlinked to partitions/directories on the hdd.
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with
other ssd specs. So it seems wise to symlink /tmp and /var to the
hdd as well.
But I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
Not exactly sure why, but there it is.
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Clearly /home and /tmp and /var like I mentioned above.
But also clearly some other not-so-obvious stuff.
So what's the best way to distribute slackware between a
"primary" (so to speak) partition on the ssd, and all volatile
stuff symlinked to the hdd, with the intent of minimizing
ssd writes?
I've done this as follows:-
I have a 256GB SSD and a 1TB HDD
1. made two partitions on the ssd, one for /root and one for
/home/<myuserid> ; this makes it easy to re-install slackware
from scratch without messing with my userid's home directory,
so preserving all the ocnfig options, browser cache etc
2. I have made a /backup mountpoint for all my infrequently
accessed data (and backups), which I put on a 1TB HDD;
I backup the home dir to the HDD and also put things like movies that
take up a lot of space and are only viewed infrequently o there
--
Gnd -|o----|- Vcc Hey computer, what's the weather in Sydney?
trig -| 555 |- dschrg $ finger o:***@graph.no|tail -1|espeak
o/p -| |- thrsh
rst -|-----|- cntrl Steve555
andrew
2019-07-05 04:41:55 UTC
Permalink
Post by John Forkosh
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with
other ssd specs. So it seems wise to symlink /tmp and /var to the
hdd as well.
The SSD I purchased recently: Crucial - MX500 2 TB 2.5" has a TBW of
700TB which pretty much puts the life of the SSD beyond the useful life
of the entire system. Times are changing with SSD technology...

Andrew
--
Do you think that's air you're breathing?
John Forkosh
2019-07-05 06:55:34 UTC
Permalink
Post by andrew
Post by John Forkosh
But I noticed the ssd has an "Endurance (Total Bytes Written)"
of 400TB, which seems pretty typical after comparing it with
other ssd specs. So it seems wise to symlink /tmp and /var to the
hdd as well.
The SSD I purchased recently: Crucial - MX500 2 TB 2.5" has a TBW of
700TB which pretty much puts the life of the SSD beyond the useful life
of the entire system. Times are changing with SSD technology...
Andrew
Arguably greater, but note that the quoted "workload" for the new
hdd I got (replacing the fried one which started me on this thread)
is 300TB/year, with no quoted overall lifetime upper bound. And since
I'm replacing a failed hdd anyway, maybe that's making me a tad more
sensitive to the fact that [famous novel title...] "things fall apart".
Also, by the way, your 700TB TBW is for a 2TB ssd, whereas mine
is a 1TB ssd with 400TB TBW, so the number of rewrites is slightly
greater for mine. In any case, I typically boot about once a day, and
can easily imagine 1GB volutile stuff written per day -- my ~/.cache/
directory alone is currently 407MB. So that'd be roughly 10 years
ATBF (absolute time before failure:), although closer to 20 for you.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2019-07-05 07:08:21 UTC
Permalink
Post by John McCue
<snip>
Also, by the way, your 700TB TBW is for a 2TB ssd, whereas mine
is a 1TB ssd with 400TB TBW, so the number of rewrites is slightly
greater for mine. In any case, I typically boot about once a day, and
can easily imagine 1GB volatile stuff written per day -- my ~/.cache/
directory alone is currently 407MB. So that'd be roughly 10 years
ATBF (absolute time before failure:), although closer to 20 for you.
Oh, wait, I seem to have dropped a couple of zeroes there.
So probably (much) less of a problem than I'd initially figured.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
andrew
2019-07-05 07:15:59 UTC
Permalink
Oh, wait, I seem to have dropped a couple of zeroes there. So
probably (much) less of a problem than I'd initially figured.
This area was covered in an interesting LQ thread (which I started btw):

https://www.linuxquestions.org/questions/slackware-installation-40/upcoming-fresh-installation-with-ssd-4175652052/

Might be some useful info there for you?

Andrew
--
Do you think that's air you're breathing?
Sylvain Robitaille
2019-07-17 21:36:51 UTC
Permalink
... I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
...
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Here's how I layout my own systems (this example is on a single
spinning disk, but you'll be able to adjust the partitions for your own
needs):

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
|-sda1 8:1 0 1G 0 part /
|-sda2 8:2 0 4G 0 part [SWAP] <- volatile
|-sda3 8:3 0 8G 0 part /usr <- mounted read-only
|-sda4 8:4 0 1K 0 part
|-sda5 8:5 0 2G 0 part /var <- volatile
|-sda6 8:6 0 2G 0 part /tmp <- volatile
|-sda7 8:7 0 32G 0 part /local <- local software
|-sda8 8:8 0 32G 0 part /home
`-sda9 8:9 0 128G 0 part /local/opt

As noted, /usr is mounted read-only, so I don't see the frequent
recompilations of xml data (and nothing I ever use has shown any
failure because of that). Swap, /var, and /tmp are the obvious
candidates. /home too. On some systems, what shows here as /local/opt
might be a mail queue (volatile), or a chroot environment for a web
server (somewhat volatile). On this system it holds firmware and
software images for various appliances and hardware devices I work
with, so "somewhat volatile".

If I were putting a system on an SSD, the ssd would get (of the above)
"/" and "/usr" (mounted read-only).

I hope this helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
John Forkosh
2019-07-18 04:15:23 UTC
Permalink
Post by Sylvain Robitaille
... I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
...
So the overall question is -- what's a list of directories for
all the volatile stuff that would best be kept on the hdd?
Here's how I layout my own systems (this example is on a single
spinning disk, but you'll be able to adjust the partitions for your own
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
|-sda1 8:1 0 1G 0 part /
|-sda2 8:2 0 4G 0 part [SWAP] <- volatile
|-sda3 8:3 0 8G 0 part /usr <- mounted read-only
|-sda4 8:4 0 1K 0 part
|-sda5 8:5 0 2G 0 part /var <- volatile
|-sda6 8:6 0 2G 0 part /tmp <- volatile
|-sda7 8:7 0 32G 0 part /local <- local software
|-sda8 8:8 0 32G 0 part /home
`-sda9 8:9 0 128G 0 part /local/opt
As noted, /usr is mounted read-only, so I don't see the frequent
recompilations of xml data
I only noticed it because my rsync -av backups include most of
the / directories, and a whole bunch of that .xml stuff scrolls
by my konsole window every time (after time after...).
I think it's under /usr/lib64/... somewhere, but don't exactly
recall. Since I have a new slack install on the ssd, my backups
haven't cycled back to the first one yet, so I haven't had a chance
to take careful notice of exactly where those .xml's are.
Post by Sylvain Robitaille
(and nothing I ever use has shown any
failure because of that). Swap, /var, and /tmp are the obvious
candidates. /home too. On some systems, what shows here as /local/opt
might be a mail queue (volatile), or a chroot environment for a web
server (somewhat volatile). On this system it holds firmware and
software images for various appliances and hardware devices I work
with, so "somewhat volatile".
If I were putting a system on an SSD, the ssd would get (of the above)
"/" and "/usr" (mounted read-only).
I hope this helps ...
Yeah, I've moved (by way of symlinks) home/, tmp/ and var/ off the ssd
onto the hdd, and also symlink'ed root/ to home/root/ on the hdd
(it's a personal workstation so no security issues). I've left opt/ and
usr/local/ on the ssd, at least for the time being. Also on the ssd
are bin/, boot/, dev/, etc/, etc (and I'm still using a small separate
mounted partition on the hdd for swap, rather than a directory).
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Sylvain Robitaille
2019-07-18 15:49:10 UTC
Permalink
Post by John Forkosh
Yeah, I've moved (by way of symlinks) home/, tmp/ and var/ off the ssd
onto the hdd, and also symlink'ed root/ to home/root/ on the hdd
(it's a personal workstation so no security issues).
The issue I would have with this isn't so much about security
(filesystem permissions work the same way whether root's home directory
is under "/" or under "/home"), but rather the possibility of needing to
work on the system with only the root partition mounted (ie. no access
/home), for whatever reason. It's been a mightly long time since I've
needed to do that, but it can and does happen. I'd still prefer to have
root's startup files in place, for example.
Post by John Forkosh
... Also on the ssd are bin/, boot/, dev/, etc/, etc (and I'm still
using a small separate mounted partition on the hdd for swap, rather
than a directory).
Well, certainly in my example, swap is also a separate partition, not a
directory. I didn't mean to make it seem otherwise.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
John Forkosh
2019-07-20 03:30:02 UTC
Permalink
<<snip>>
Post by John Forkosh
... Also on the ssd are bin/, boot/, dev/, etc/, etc (and I'm still
using a small separate mounted partition on the hdd for swap, rather
than a directory).
Well, certainly in my example, swap is also a separate partition, not a
directory. I didn't mean to make it seem otherwise.
My bad. Yeah, in your example swap's obviously on a separate partition.
Don't know what I was (mistakenly) thinking.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2019-07-27 01:06:17 UTC
Permalink
Post by John Forkosh
Post by Sylvain Robitaille
... I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
...
As noted, /usr is mounted read-only, so I don't see the frequent
recompilations of xml data
I only noticed it because my rsync -av backups include most of
the / directories, and a whole bunch of that .xml stuff scrolls
by my konsole window every time (after time after...).
I think it's under /usr/lib64/... somewhere, but don't exactly
recall. Since I have a new slack install on the ssd, my backups
haven't cycled back to the first one yet, so I haven't had a chance
to take careful notice of exactly where those .xml's are.
Just fyi, it's most (but not quite all ) of the .xml files
under /usr/share/mime/ and in subdirectories under that,
like /usr/share/mime/images/, ...video/ and .../x-content etc.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2019-07-27 01:23:58 UTC
Permalink
Post by John Forkosh
Post by John Forkosh
Post by Sylvain Robitaille
... I've noticed during boots that there's a bunch of .xml stuff
in /usr that seems to get recompiled during every single boot.
...
As noted, /usr is mounted read-only, so I don't see the frequent
recompilations of xml data
I only noticed it because my rsync -av backups include most of
the / directories, and a whole bunch of that .xml stuff scrolls
by my konsole window every time (after time after...).
I think it's under /usr/lib64/... somewhere, but don't exactly
recall. Since I have a new slack install on the ssd, my backups
haven't cycled back to the first one yet, so I haven't had a chance
to take careful notice of exactly where those .xml's are.
Just fyi, it's most (but not quite all ) of the .xml files
under /usr/share/mime/ and in subdirectories under that,
like /usr/share/mime/images/, ...video/ and .../x-content etc.
Sorry for following myself up, but just checked that out,
and it's caused by /usr/bin/update-mime-database which is
executed by /etc/rc.d/rc.M during boot. That's guarded by
an if [ -x ...] so it can all be turned off by
chmod 644 /usr/bin/update-mime-database (which I just did
for myself).
So kind of a follow-up question: is there any other
not-really-necessary stuff like that which can be
similarly turned off if not wanted?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2019-07-27 10:11:25 UTC
Permalink
is there any other not-really-necessary stuff like that which can be
similarly turned off if not wanted?
Most scripts in /etc/rc.d are possible to turn off by doing
"chmod a-x /etc/rc.d/rc.somescript"

This is also done during installation with menu choices from the
installation script setup.services which you also after installation can
find in the directory /var/log/setup.

regards Henrik
John Forkosh
2019-07-27 13:43:35 UTC
Permalink
Post by Henrik Carlqvist
is there any other not-really-necessary stuff like that which can be
similarly turned off if not wanted?
Most scripts in /etc/rc.d are possible to turn off by doing
"chmod a-x /etc/rc.d/rc.somescript"
This is also done during installation with menu choices from the
installation script setup.services which you also after installation can
find in the directory /var/log/setup.
regards Henrik
Sure, thanks. I already realized that (indeed, during install,
the "what services do you want to run" menu just chmod's scripts
in /etc/rc.d based on what you tell it you want). But I wouldn't
want to "turn off" rc.M entirely, just its update-mime-database
section. And then there's the silly (my opinion) fortune stuff
in /etc/profile.d/ that I immediately "turn off" after every
install. And various other stuff that chmod's in /etc/rc.d/
don't handle.
But, for the purposes of this thread, I was specifically
asking about stuff that does unnecessary (or not entirely
necessary) disk writes during boot, which you might (and I do)
want to minimize for ssd's. (/var and /tmp aren't on the ssd,
so syslog writes and other such stuff don't count)
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Henrik Carlqvist
2019-07-28 10:06:57 UTC
Permalink
Sure, thanks. I already realized that (indeed, during install, the "what
services do you want to run" menu just chmod's scripts in /etc/rc.d
based on what you tell it you want). But I wouldn't want to "turn off"
rc.M entirely, just its update-mime-database section. And then there's
the silly (my opinion) fortune stuff in /etc/profile.d/ that I
immediately "turn off" after every install. And various other stuff that
chmod's in /etc/rc.d/ don't handle.
But, for the purposes of this thread, I was specifically
asking about stuff that does unnecessary (or not entirely necessary)
disk writes during boot, which you might (and I do) want to minimize for
ssd's. (/var and /tmp aren't on the ssd, so syslog writes and other such
stuff don't count)
Everything at boot is somehow started by a script in /etc/rc.d and those
scripts are started depending on runlevel as described in /etc/inittab.
The scripts called from inittab (including rc.M) should not get chmoded,
but ths scripts optionally called from rc.M and other scripts could get
chmoded to avoid being called.

The scripts in /etc/profile.d are not called at boot but at login.

regards Henrik

Loading...