Even though it was more than 10 years ago, I was playing with Ubuntu 18.04 LTS installed because I didn't want to save money and throw away what I bought, but now I guess it's a level spec, but I can use the Web and email. Somehow it can be used for some reason, so at this time I decided to move to SSD and try as soon as possible.
--Target PC) Fujitsu FMV-BIBLO MG70W (released in 2007, Ubuntu 18.04 LTS installed) --SSD) GREEN HOUSE 120GB SSD (GH-SSDR2SA120: 2,750 yen including tax) --Soft) EaseUS Todo Backup Home (12.8 at the time of work) --Working PC (Windows 10) --2.5inch HDD case that can be connected via USB --1 DVD-R
When I made a Linux clone using Todo Backup, I saw a few articles that it would not work unless I specified sector by sector, so I did that, but when I tried to clone it, an error dialog appeared and proceeded. Absent.
I should have read the message properly at this time, but by the way, I did nothing with the SSD, so I removed it from the PC and formatted it, but after all the same dialog appeared, so I read the message again I read it (English)
** (Free translation) There is not enough disk space at the migration destination **
As a result of investigation, in the case of sector-by-sector specification, it is said that it will not work unless ** "The migration destination (SSD) has a disk size equal to or larger than the migration source (HDD)" ** (it is natural to say that it is natural). This time, the HDD of the migration source is 160GB, the SSD of the migration destination is 120GB ... That's why it is said "not enough" orz
Then you should reduce the size of the HDD partition, right? However, I didn't want to type the dd command, fdisk, or any other command here, so I managed to find a way to go with just the GUI as much as possible, and changed to the following procedure.
This time HDD <SSD, so no error occurred and the clone started to work (^^) Cloning is completed in 1 hour and 24 minutes.
Replace it with the SSD that has been cloned and start it ... Uh, it worked! Thanks to that, it started up very quickly!
So it took less than half a day to move to SSD (^^)
It started working safely, so when I suddenly saw the resource monitor while I was trying it out
** Gya, I'm using swap! (＞ ＿ ＜) **
Even though it's old, it has 4GB of memory, and if I was arguing that it wasn't a big deal, I could easily create a swap area. No, I think it's not the time to feel at ease with 4GB.
Speaking of swap, it was an image that it was set in / etc / fstab, but with ubuntu 18.04, it seems that it is also necessary to execute it with a command. However, you also need to edit / etc / fstab, so open the fstab file and comment out the line where type is "swap".
$ sudo nano /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=fe275a41-3782-4249-9109-3eb171e4eb2e / ext4 errors=remount-ro 0 1
# /swapfile none swap sw 0 0 ← This line
Then disable swap with the command. Specify the swap file name in the parameter.
$ sudo swapoff /swapfile
Finally, a huge file of 200MB or 2GB was created, so I deleted it.
$ sudo rm -r /swapfile
GNOME's system monitor shows "Swap: Not available", and swapon -s didn't show anything, so I decided that swap could be disabled.
It seems that there were settings that should be done not only for swap but also for SSD in the first place.
Of course, SSDs have a different mechanism for writing and erasing data than HDDs, so it seems that the "TRIM" function is important for SSD performance and longevity (I'm not sure).
The PC is old, but the OS and SSD are new, so I think it's supported ... but first check.
$ sudo hdparm -I /dev/sda1 | grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)
Since it is "Supported", it turned out that it is an SSD that supports the TRIM function.
There seems to be a command called "fstrim" to execute TRIM, but instead of hitting it by hand, let the OS execute it regularly.
First, check the status.
$ sudo systemctl status fstrim
● fstrim.service - Discard unused blocks
Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor preset: en
Active: inactive (dead)
Well, I'm not sure, but the fact that fstrim is displayed means that something is set. So enable the timer that runs fstrim on a regular basis.
$ sudo systemctl enable fstrim.timer
Check if the timer is registered properly.
$ sudo systemctl list-timers --all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2020-11-04 10:04:42 JST 47min left Wed 2020-11-04 09:03:19 JST 14min ago anacron.timer anacron.service
Wed 2020-11-04 15:02:57 JST 5h 45min left Wed 2020-11-04 08:54:50 JST 22min ago motd-news.timer motd-news.service
Thu 2020-11-05 03:41:03 JST 18h left Wed 2020-11-04 08:53:14 JST 24min ago apt-daily.timer apt-daily.service
Thu 2020-11-05 06:26:46 JST 21h left Wed 2020-11-04 08:53:14 JST 24min ago apt-daily-upgrade.timer apt-daily-upgrade.s
Thu 2020-11-05 09:08:14 JST 23h left Wed 2020-11-04 09:08:14 JST 9min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-cl
Mon 2020-11-09 00:00:00 JST 4 days left Mon 2020-11-02 14:03:51 JST 1 day 19h ago fstrim.timer fstrim.service
n/a n/a n/a n/a snapd.snap-repair.timer snapd.snap-repair.s
n/a n/a Wed 2020-11-04 08:54:10 JST 23min ago ureadahead-stop.timer ureadahead-stop.ser
The fact that LAST is 11/2 means that it has worked, and since fstrim.timer has appeared, it will surely work.
There seems to be a setting for continuous TRIM when mounting. If you set this, it seems that the performance will drop at the cost of doing a lot of TRIM, so I confirmed it (like discard)
$ sudo findmnt -O discard
$
Since the mount point was not displayed even though it was executed, it was judged that discard was not set. You can also run fstrim manually, but I stopped here.
Also, on the Web, I saw a story about "specifying noatime when mounting", but I stopped it because it sometimes stopped working. In addition, when I looked at the mount status, it was ↓, so it was judged that relax time was specified & discard was not specified.
$ cat /proc/mounts
:
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
:
It seems that mlocate writes a large file, but I was reluctant to disable it, so I moved mlocate from /etc/cron.daily to /etc/weekly.
It seems that you can check the execution log of cron with "sudo journalctl -f -u cron", so I looked at it, but I thought it was good because there seems to be no evidence that mrocate worked.
There may be some omissions because I'm writing while thinking back after finishing all the steps, but I added it because it is better to do it after migrating to SSD.
EaseUS Todo Backup Free https://jp.easeus.com/backup-software/free.html
Recommended Posts