The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

[SOLVED] Moving installation to SSD drive

Hello:

I recently came across a very good offer for a brand new/sealed Kingston SV300S37A/120G SSD on the local flebay and decided it would be a good candidate for my main drive.
At US$16.50 I could not pass it up.

I was about to use dd but I found this ...

https://www.pcsuggest.com/hdd-to-ssd-cloning-linux/

... and following the instructions I used the previously unknown to me pv utility to clone the drive:

# pv </deb/sdb> /dev/sda

In ~09:00 my 68Gb SAS drive was cloned to the new 120Gb SDD and with a progress bar.  =-)

I then booted to an alternate instalation, pulled up gparted and resized the extended and /home partitions to take up the unallocated space.

A shutdown, removal of the 68Gb SAS drive and reboot after a BIOS boot drive order change found everything in it's proper place and working properly.

Up to here everything was OK.

So I shutdown again, replaced the 68Gb SAS drive in it's bay and rebooted but when I brought up gparted again to do some checking/cleaning up and I saw that the old /home and /swap partitions were locked.

Retracing my steps and knowing that BackInTime and Timeshift had me covered, I replaced the old drive and after booting into the alternate install, reformatted it to a 68Gb ext4 partition.

A reboot and inspection with gparted confirmed that everything was back to normal.

But this left me with a couple of questions:

1. how should I have checked that pv did everything properly?
2. what should I have changed/modified so that any partitions left in the old drive were ignored? Give the SAS drive a new UUID?

Also, my rig has 8.0Gb RAM and I can safely say that the swap partition is never (?) used.
I have kept it because I have the idea that there may be some applications that require the presence of a swap partition but I really cannot say.

Are there any system tweaks needed to keep the SSD in proper shape?

---

Edit:
I noted that the swap file was not activated so I activated it using gparted.
But the setting does not survive a reboot.

Besides setting swapon in gparted, is there anything else?
What am I missing?

---

Thanks in advance,

A.

Last edited by Altoid (2020-03-14 13:30:49)

Dutch_Master

Member

Registered: 2018-05-31

Posts: 285  

Re: [SOLVED] Moving installation to SSD drive

Partition/disk management in Linux takes place in the /etc/fstab file. So, in order for the old partitions to be ignored, you'd have to comment them out (put a # in front of the line) Swap is also managed in that file, following the same syntax as a normal partition:

UUID=7af41fff-29cd-4f83-a099-aec1cb6eda8a none            swap    sw              0       0

This is swap activated in my system, your UUID will differ but feel free to copy the (rest of the) line as is.

Tip: to obtain UUID's for your partitions, use the blkid command on the cli, as described in this wiki page. (which I wrote, btw )

Do note that every edit to the /etc/fstab file needs to be done as root!

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

Thanks for the prompt reply. =-)

Partition/disk management in Linux takes place ...

Yes ...
I also found out that UUIDs get changed if you make changes in partitions.
In may case, I deleted and made a new larger swap file.

I still have to clean/tidy up my fstab file as it is a mix of UUID= and LABEL= lines.

... following the same syntax as a normal partition:

UUID=7af41fff-29cd-4f83-a099-aec1cb6eda8a none            swap    sw              0       0

Yes, the one I just set up is a bit different but it seems to work:

groucho@devuan:~$ cat /etc/fstab
--- snip ---
# swap partition in ssd
UUID=0797ed56-60ad-4f53-a9ab-39b6fb3aaccd  none  swap  defaults  0    0
--- snip ---

Does a swap file in a SSD need any special settings?

Thanks for your input.

A.

Last edited by Altoid (2020-03-14 14:09:32)

Dutch_Master

Member

Registered: 2018-05-31

Posts: 285  

Re: [SOLVED] Moving installation to SSD drive

No, not really. Unless your system is seriously memory-starved and swap comes into play often, in which case it's advisable to move it to a spinning disk instead as Flash drives do not cope too well with high read/write load cycles: it shortens their lifespan considerably. But as you stated swap is rarely used, don't bother now. My system also has an SSD for the system, including swap, but like yours it's seldom used so I don't bother about it. One of my SSD's (1st gen. consumer grade stuff, from Crucial, 60GB) lasted well over 60,000hrs before replacing it not so long ago.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

No ...
Unless your system is seriously memory-starved and swap comes into play often ...

I don't think it is the case here.

Flash drives do not cope too well with high read/write load cycles ...

Yes, I had read something about that.

I'll see if I can find if there is a utility that can log swap activity (I think I saw one once ...) over a set amount of time, say 30/60/120 days and evaluate the results.
I have enough relatively fast SAS 3.0Gb/sec rust so I could eventually set up an 8.0Gb swap partition on one of them.

Thanks for your input.

Cheers,

A.

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: [SOLVED] Moving installation to SSD drive

Are there any system tweaks needed to keep the SSD in proper shape?

Use a weekly cron job to run fstrim on the drive to maintain performance, MX Linux has one you can "steal":

# /etc/cron.weekly/fstrim
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

But don't bother following any obsolete advice to minimise writes, I actually have one of those Kingston drives and the longevity is great. See also https://techreport.com/review/27909/the … -all-dead/

---

Brianna Ghey — Rest In Power

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

... a weekly cron job to run fstrim ...
... MX Linux has one you can "steal" ...

It seems that it is part of a 'goodies' package (how I abhor this goodies crap)

http://mxrepo.com/MX19packages.html

mx-goodies - 20.03.01
Version: 20.03.01
Section: system
Architecture: 32bit and 64bit
Description:
Includes:
* burniso (write an ISO image from cli)
* fancy-prompts (nine different colorful and interesting prompts)
* ps_initrd.sh (initrd packing/unpacking tool)
* zram (script to set up zram)
* ps_mem.py (RAM usage script)
* fstrim-mx (auto set up fstrim of SSE drives as a weekly cron job)
Homepage: http://antix.mepis.org
Maintainer: anticapitalista

Can't get just the fstrim-mx by itself?

# /etc/cron.weekly/fstrim
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

OK.

Q: how come it is not in (any realease, actually) the devuan repository?

... don't bother following any obsolete advice ...
... have one of those Kingston drives and the longevity is great.

Good to know.

Cheers,

A.

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: [SOLVED] Moving installation to SSD drive

Can't get just the fstrim-mx by itself?

Well you could download the .deb package then unpack it and copy the script to /etc/cron.weekly but it's more or less the same as the one I've posted (it uses bash instead of /bin/sh for some reason though, which is slower, potentially more buggy and slightly more memory-intensive).

Don't add the # /etc/cron.weekly/fstrim line if you copy my script though, that's just my lazy way of indicating the filename & location.

Last edited by Head_on_a_Stick (2020-03-14 21:03:02)

---

Brianna Ghey — Rest In Power

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

... download the .deb package then unpack it and copy the script ...

I posted and went to make myself an espresso which made my head work a bit better.

So:

groucho@devuan:~$ locate trim
/home/groucho/trimmed_log.txt
/sbin/fstrim
/usr/share/bash-completion/completions/fstrim
/usr/share/man/man3/malloc_trim.3.gz
/usr/share/man/man8/fstrim.8.gz
/usr/share/tools/trim26lst
groucho@devuan:~$ 

Seems that the fstrim util is in/part of the Devuan ascii distribution.
And from the locate printout, it also seems that it has been run before.

groucho@devuan:~$ cat /home/groucho/trimmed_log.txt
[30/Nov/2018:10:44:10-0300] 1
[08/Dec/2018:19:12:32-0300] 1
--- snip ---
[17/Feb/2020:13:44:14-0300] 1
groucho@devuan:~$ 

The trimmed_log.txt (which for some strange reason is not in /var/log) only gives date, time and what would be the trim (?).

But ...

I only installed the SSD yesterday, no SSDs before that, so fstrim was working on some other drive.
I speculate that it was on the SAS drive replaced with the Kingston SSD ie: boot drive. (?)

Q:
1. How is fstrim set up and started? 
2. Will it keep working now albeit on the SSD?

Some dates in /home/groucho/trimmed_log.txt are far apart and there are up to 30 entries with the same date (with trims as high as 24 so it does not seem to be a cron job.

So if it is not a cron job, what triggers it to run and how can it be modified?

Thanks in advance,

A.

Dutch_Master

Member

Registered: 2018-05-31

Posts: 285  

Re: [SOLVED] Moving installation to SSD drive

Bookmark this page: https://ss64.com/bash/

Tools to investigate (use the link, for instance) are (in no particular order):
which, strace, ps, whereis, grep/egrep/pgrep, lsof, locate/slocate and htop

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

Bookmark this page ...

Thanks ...
Already had it.

Tools to investigate ...

Indeed ...

I use locate and grep every day.
I have used which, whereis, ps and htop at some time or another as part of a script I copied from the web.

The rest I have not come across, at least that I remember.
Thanks for the pointer.

But I am still far from finding out where (in my Devuan ascii) fstrim is started and under what circumstances.

One thing I found and think it is important:

https://unix.stackexchange.com/question … -do-fstrim

TRIM does at least three things:

1. minimize write amplification
2. prevent long-term performance degradation
3. irrecoverably delete your data

--- snip ---

If you decide on fstrim you should know where the cron job is located so you can disable it when you have an accident, that way you get a compromise between 2) and 3).

I would have expected to find the cron job for fstrim in /etc/cron.daily, /etc/cron.weekly or /etc/cron.monthly but it is not there. 

I would like to edit the configuration file so that it logs in /var/log/fstrim.log with the verbose option so I know what it is doing or even disable it.
Instead just basic data in trimmed_log.txt in my /home directory.

Any idea as to where it is in Devuan ascii?

Thanks for your input.

Cheers,

A.

Last edited by Altoid (2020-03-15 02:25:31)

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: [SOLVED] Moving installation to SSD drive

But I am still far from finding out where (in my Devuan ascii) fstrim is started and under what circumstances.

I don't think it's started automatically at all. The Debian util-linux package supplies systemd timer & service unit files to allow it to be configured to run automatically every week but the Devuan package doesn't include those files or any cron jobs to replace them.

That trimmed_log.txt file in your home directory must be for something else.

To get fstrim running every week create a cron job for it, as I have shown.

---

Brianna Ghey — Rest In Power

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

I don't think it's started automatically ...

Right. (A bit late in life but I have vowed to try to stop using OK)

... Debian util-linux package supplies systemd timer & service unit files ...
... but the Devuan package doesn't include those files or any cron jobs ...

I see.

... trimmed_log.txt file in your home directory must be for something else.

Hmm ...
I'll start looking again to see if I can find out just where it comes from.

... create a cron job for it, as I have shown.

I was just about to do that when I found trimmed_log.txt.

--- solved ---

From its content and name, it seemed (to me) that it could have been produced by fstrim.
But it turns out that it is not.   =-)

A search on the web brought up just three hits, one of them from a thread I (!) started here at Dev1.
So it turned out that it was right in front of me/us.

See here:
https://dev1galaxy.org/viewtopic.php?pid=20206#p20206

The simplest way to trim information from the log is awk

I suppose in the "Samsung_M2020_Series groucho 109 [27/Dec/2018:08:37:02 -0300] 1 1 - localhost H:\Desktop\flower_sm.jpg A4 -" entry the 6th word (in this case it's "1") is the number of printed pages. Therefore the following command will give a text table with date/time and amount of printed pages found by the word "A4":

cat /var/log/cups/page_log | grep A4 | awk '{print $4$5 " " $6}' > trimmed_log.txt  <-------------- !!!

And here:
https://dev1galaxy.org/viewtopic.php?pid=20211#p20211

Try these instead:

awk '/A4/{print $4$5 " " $6}' /var/log/cups/page_log > trimmed_log.txt  <-------------- !!!
awk '/A4/{pages += $6} END {print pages}' /var/log/cups/page_log

It was generated when I was trying to figure out how many pages my M2020W cartdrige had actually printed before running out.
Which I still have to figure out how to awk properly.

Thanks a lot for your input.

Cheers,

A.

Last edited by Altoid (2020-03-15 13:25:00)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

Use a weekly cron job ...

Done.
Works a treat.  =-)

#!/bin/sh
# trim all mounted file systems which support it
# added 20200315
#
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim --all --verbose >> $LOG

groucho@devuan:~$ cat /var/log/trim.log
*** Sun, 15 Mar 2020 17:51:27 -0300 ***
/var/log: 0 B (0 bytes) trimmed
/home: 112 MiB (117415936 bytes) trimmed
/: 483.9 MiB (507346944 bytes) trimmed
groucho@devuan:~$ 

Just changed the name of the cron job so that it would not be the same as the executable.
Thanks for your input.

Cheers,

A.

ToxicExMachina

Member

Registered: 2019-03-11

Posts: 210  

Re: [SOLVED] Moving installation to SSD drive

You don't need to run TRIM command at all if you mount filesystem with 'discard' option.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: [SOLVED] Moving installation to SSD drive

Hello:

... don't need to run TRIM command at all if you mount filesystem with 'discard'...

Yes, but thenI'd be running trim every time I booted the rig, which could be up to three or four times a day.

I'm looking to analyse the /var/log/trim files in a month or so to see what went on and then decide on weekly, monthly or something else.

There's a chap that wrote a daemon for running trim here:

https://github.com/dobek/fstrimDaemon

He argues that it would seem to be "more reliable to execute fstrim based on up time then cron table.".

Thanks for your input.

Cheers,

A.

Last edited by Altoid (2020-03-19 18:32:46)

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: [SOLVED] Moving installation to SSD drive

You don't need to run TRIM command at all if you mount filesystem with 'discard' option.

The discard option slows down the drive because TRIM is applied for all I/O operations.

Last edited by Head_on_a_Stick (2020-03-19 18:30:28)

---

Brianna Ghey — Rest In Power

ToxicExMachina

Member

Registered: 2019-03-11

Posts: 210  

Re: [SOLVED] Moving installation to SSD drive

You don't need to run TRIM command at all if you mount filesystem with 'discard' option.

The discard option slows down the drive because TRIM is applied for all I/O operations.

Any write operation is slowing down an SSD due to physical limitations. In practice the 'discard' option is just convenient thing with insignificant overhead.