You are not logged in.
I have moved my system disk to a Samsung 840EVO 1TB. I followed a wiki for Arch and have implemented the changes posted below.
I am older (56), and am requesting the community review what I have done, and then tell me if I have missed anything that should be done when using Arch on an SSD.
/dev/sda (my system disk) was cloned to the new /dev/sda using Clonezilla, and it appears to have done it's job flawlessly.
Basically, I am asking for validation that I haven't missed anything.
Here is what I have done:
Old HDD Config:
/dev/sda Hitachi 1TB spinning HDD (Linux dual-boot with win 7 for games)
/dev/sdb Hitachi 2TB spinning HDD
/dev/sdc Hitachi 2TB spinning HDD
/dev/sdd Western Digital Greeen 450Gb spinning HDD. (this is an old drive beginning to throw SMART errors)
New HDD Config:
/dev/sda Samsung 850EVO 1TB SSD
/dev/sdb Hitachi 2TB spinning HDD
/dev/sdc Hitachi 2Tb spinning HDD
/dev/sdd Hitachi 1TB spinning SSD. (original /dev/sda moved into /dev/sdd's slot)
Basically I left /dev/sdb, sdc in place, retired /dev/sdd, and moved my old /dev/sda into /dev/sdd's position. The EVO is now /dev/sda.
a) Per the Arch wiki, added "discard" to the fstab for the fs's that reside on the ssd so that "trim" was enabled. (fstab provided below)
b) Partitioned /dev/sdd into /dev/sdd1, sdd2, and sdd3. /dev/sdd1 is the lions' share of the HDD. /dev/sdd2 is a 50GB partition dedicated to the /var tree. /dev/sdd3 is a 16GB swap partition. A bit of a large swap file considering my new DRAM I just installed is 32GB.
c) Followed a posted procedure in the Arch forums to move the entire /var tree to another partition, in this case from my SSD to /dev/sdd2. fstab was updated.
d) I already had vm.swappiness=0 in my old sysctl.conf file which I ensured was migrated to the systemd equivalent per the Arch wiki when sysctl.conf was depreciated.
e) Modified the fstab to use /dev/sd3 as the swap space instead of the old partition(/dev/sda6), which was deleted, and the existing partitions on /dev/sda adjusted accordingly so that no space is wasted on the SSD. I had to modify the fstab of course because once I deleted /dev/sda6, /dev/sda7 (root) then became /dev/sda6.
f) Modified the syslinux.cfg file to point to the new real root partition.
g) Followed another wiki to ensure that tmpfs existed only in RAM, and was being used for all c++ compilation passes, and consisted of about 50% of my systems memory. Come to find out, that this is an Arch Linux default characteristic. But at least I looked at it and verified it.
The system is running perfectly at this point.....
//-----------------
Is there something I am missing beyond what I have done?
//-----------------
Sincerley and respectfully, and of course THANK YOU!
Dave
//----------------Begin fstab
#
# /etc/fstab: static file system information
#
#
#
#
# <file system> <dir> <type> <options> <dump><pass>
# tmpfs is a filesystem that exists only in ram. This is where compilation
# stuff goes. It's defaults to 1/2 of the systems ram.
tmpfs /tmp tmpfs nodev,nosuid 0 0
# /dev/sda2, Windows
/dev/sda2 /media/Windows ntfs-3g defaults,noauto,users 0 0
# /dev/sda5, boot
/dev/sda5 /boot ext4 rw,noatime,exec,discard 0 2
# /dev/sda6, root
/dev/sda6 / ext4 rw,noatime,exec,discard 0 1
# /dev/sdb1, Backup-1
/dev/sdb1 /media/Backup-1 ext4 noauto,users,noatime,exec 0 2
# /dev/sdc1, Backup-2
/dev/sdc1 /media/Backup-2 ext4 noauto,users,noatime,exec 0 2
# /dev/sdd1, VMs-Misc
/dev/sdd1 /media/VMs-Misc ext4 users,noatime,exec 0 2
# /dev/sdd2, the new /var mountpoint on spinning media to protect the SSD
# from excessive writes
/dev/sdd2 /var ext4 defaults 0 2
# /dev/sdd3, the new swap on spinning media.
/dev/sdd3 none swap defaults 0 0
# /dev/sr0, the dvd burner
/dev/sr0 /media/DVD auto defaults,noauto,users 0 0
# /dev/sr1, the BluRay reader
/dev/sr1 /media/BluRay auto defaults,noauto,users 0 0
Last edited by dcbdbis (2013-12-10 23:01:09)
Offline
There's nothing wrong with what you have done, though I question your 1TB assertion of an SSD???? (late edit - unless they are hybrid drives?)
Nevertheless, OS on SSD, Data on spinners, and a backup of data as a fallback, and you can't go far wrong (/me reminds myself to backup data)
Last edited by Roken (2013-12-10 21:42:00)
Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus B550-F Gaming MB, 128Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (2 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703
/ is the root of all problems.
Offline
Hello,
The 1TB ssd is already over 1/2 full of OS related data. It is a pure SSD. The Samsung 840EVO. All I can say is I have a boatload of include files and libraries I've amassed over the years.
I have procured a multi-year software contract where I need to dramatically speed up my compile times. It's a huge project. The /tmp tree is where the compilation happens, then the final product is written out to the SSD. So RAM was increased to 32GB to accomodate the larger compilations that will be happening in about 2-3 months. Since I upgraded my RAM, my current /tmp tree has 16GB of memory assigned to it (default to 1/2 of the installed memory in Arch). That addresses temp files and various stages of intermediate op code during the compilation process. The SSD still houses all the include libraries so that the compiler can read those *.h and external libraries very fast so as not to slow down the compilation process itself when reading these external files.
Basically I modified my system to have blazing fast read performance, and blazing fast compile times. I remember my last big contract, and what a P.I.A. it was waiting for compilation passes....I don't want to start a compile, go to the gym, only to come back to a still-not-complete compile.
I am using the make -j8 options in my arch system, as well as in my compiler project settings. I am using a AMD-8350 CPU. So I have all eight cores available, and my IDE uses them.
I use the iterative programming method IE: Code a little, test a lot, code a little, test a lot, etc.....I have had good success using this slower, but more reliable coding methodology. I just don't want to burn a lot of time waiting during compiles.
Anyway, there is my SSD reasoning....
I wanted the community to review my settings as this is obviously new tech that needs to be deployed **delicately** to achive longevity. Arch is a far cry from AT&T SystemV Rev III. I wanted to make sure I was current with the proper way to deploy an SSD under Arch Linux.
And THANK YOU for the reply..... I'll mark the thread as solved.....
Sincerely,
Dave
Offline
There's nothing wrong with what you have done, though I question your 1TB assertion of an SSD???? (late edit - unless they are hybrid drives?)
Nevertheless, OS on SSD, Data on spinners, and a backup of data as a fallback, and you can't go far wrong (/me reminds myself to backup data)
OT: I just got the same model in the 250GB size; apparently, it's the first consumer SSD to come in a 1TB size.
Offline
Perhaps what I did to reconfigure Arch will be of some assistance to you and your new drive?
Regards,
Dave.
Offline
I think it is the first SATA3 1TB SSD, but not the first in general. There is that store that sells aftermarket parts that are marketed as Mac components. I believe they are Other World Computing (OWC), and they make their own SSDs. They had a SATA2 1TB SSD out maybe a year and a half or two years ago. It was really just two 500GB SSDs sandwiched together in a 9mm case though.
@Dave, you probably don't really need the discard flag, and in fact it would probably be better not to have it. The trim command is something that was more heavily relied upon in the days of crappier garbage collection and wear levelling. It helped maintain the life and performance of those older drives, but the trim command is blocking, meaning that all I/O has to wait for it to finish. This means that removing files will result in degraded performance. Since you use ext4, a better alternative (if you still feel as though you need to trim your device) would probably be to run fstrim on the various mount points from time to time. I have this set up as a weekly anacron job.
The only time I think that the discard flag is justified is if you are using a filesystem that doesn't support fstrim. As far as I've been able to determine, the only one that supports the discard flag but does not support using fstrim is vfat. So I have my EFI System Partition mounted with discard, but nothing else.
Offline
WonderWoofy, have you got a source on that info? Not that I don't trust you, but I'm looking at two SSDs in LVM now, so I'm a little wary of getting everything right myself.
Offline
Is this with GPT? I thought I remembered that GPT was important with an SSD for some reason but now I can't remember why I think that.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Well, you don't want the OWC SSD anyway since it is twice as expensive as the 840 Evo and not nearly as fast. I am of the opinion that the Samsung SSDs are the best choice right now. They have high quality flash, and they have fast triple core controllers that don't rely on compression for their speed.
The only downside to those Evos are that they are triple cell flash. But tests have indicated that their endurance is enough to last for quite some time. I have an 840 (non-evo) 250GB and it is fantastic. I also have the older 830 128GB, and that too is pretty fantastic, though the 840 is slightly faster. The 840 Evos have only a slightly higher read speed, but the sequential (claimed) write speed of the Evo is over twice that of my plain 'ol 840.
Offline
Dear "cfr",
My installation isn't new so I stuck with the old MSDOS partition table scheme......I just let Clonezilla do it's thing at the device level, not the partition level. It caried all my partitions over. I cloned from my original /dev/sda (now /dev/sdd), to the EVO. The old HDD (now /dev/sdd) had already had the partitions manipulated appropriately so as to not step on the reserved sectors of the target SSD during the cloning process.
Once the cloning was complete, then I used gparted offline of course, to manipulate the partitions to fill the SSD, and delete the swap partition that was part of the cloning process. Then I used the terminal of Clonezilla to mount/unmount/massage the fstab, syslinux.cfg, move the /var tree, etc.
I would encourage any SSD adopters before they clone....do your homework first to ensure that the cloning process won't step on any reserved sectors that your chosen SSD may use.... Be safe, not sorry. I did my homework over a period of ~30 days before I made the purchase decision. I also took this time to make sure my system was ready for the port in case the clone process failed. Including using gparted to move my /dev/sda1 partition around. I wanted confidence that the clone wouldn't do anything unorthodox to the new and expensive SSD.
It's an expensive investment, so I made as sure as I could be, before I made the decision to go forward, that I wasn't doing anything obviously stupid.
I also had a full system backup (x2 actually) in case something threw up. This way a fresh reload of my OS's on /dev/sda would not threaten any of my data and libs...
And for those doing a fresh install to an SSD.....before you use any fdisk/cfdisk/gdisk variant......Make sure you know where the SSD expects things to be placed, so you don't step on the sectors that the drive wants to keep for it's own purposes.
For me, the port was painless........
Regards,
Dave
Last edited by dcbdbis (2013-12-11 02:09:11)
Offline
Were you also careful to ensure the partitions were aligned? I guess there's disagreement on whether this is important judging by the links at the end of the wiki page, even though the page itself assumes it is.
Anyway, I can't remember why I think gpt is better for ssds. (Something to do with trim?) Also, stuff may have changed - it is a while since I set an ssd up.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Knowing I was going to clone.....I chose my cloning software carefully. In reading the Clonezilla wikis' and FAQ....It became aware that Clonezilla does this for you. It is an option that shows up when you do a drive to drive clone. And I selected it. Just like there is another option that pops up in a disk to disk clone that asks the user if they want to clone the boot sectors.
Then after the cloning was successful and verifies, ...Clonezilla then spent some time at the CLI. aligning the partitions after asking me if it was OK.
I'm good to go.....
Regards,
Dave
PS: Back to the original purpose of the post: Do others agree that I have deployed the SSD in a manner to maximize it's usable life?
Offline