I have my openSUSE Tumbleweed installation on a 10-year old 256 GB Samsung EVO 850 SSD that’s kind of a leftover part from my previous PC. Now I’ve ordered a 2 TB Samsung EVO 870 drive to replace it.
My current partitions on the old SSD are just an EFI partition, 2 gigabytes of swap and a big Btrfs partition.
How should I approach partitioning a bigger drive? I was thinking of something like
512 MB for EFI
8 GB for a swap partition. I guess it’s enough with 32 GB of RAM?
256 or 512 GB Btrfs for OS + home
This leaves me with about 1,4-1,7 TB of space.
What would be an ideal filesystem for the remaining space if I want to use it for things like Steam library, media storage/serving (possibly Jellyfin in my home network), etc. ?
Lastly, is there a step-by-step guide available on how to migrate the OS onto the new drive? No other components in the PC will be replaced at this time.
You want the efi partition to be 4GB as Tumbleweed will move to systemd-boot at some point, or install that now, I have a test system using it fine, likewise my Aeon install uses it without problems.
On my test system with 16GB of RAM, I have no swap and use zram instead, it suspends fine sofar. If you want swap, then a general rule of thumb is 1.5 times, installed RAM, in your case 48GB (I would also put at end of device).
Anything outside of / for data, I would use xfs partitions.
Oh, damn. I was entirely unaware of this and my mainboard has an AMD chipset (B550). Thanks for the link.
I did a quick search and found various discussions saying that this issue would have been fixed in later manufacturing batches, however I am unable to confirm it.
What would be the practical consequences of this issue if it is still present in newer drives?
I can still easily cancel the order. But I’ve only ever used Samsung SSDs. What other reputable vendors are there? I can only think of Western Digital and Crucial but WD’s quality seems to be hit or miss. I know Crucial makes good RAM but nothing about their SSDs.
Yes, hardware and trim, because I don’t know what exactly am I dealing with here. I’m very much a UI / end-user person and have little to no knowledge about how computer technology actually works. In this regard, using Linux has been very educating and not always easy.
I might still keep the order though. That way I could cycle my 512 GB music-making drive to be the Linux drive (plenty of space for OS+files) and format the new drive to NTFS for music-making in Windows.
And the old 256 can be the OS drive in a later homelab project or I could donate it to the local hacklab.
That largely depends on whether it is a laptop and you want to suspend-to-disk (AKA hibernate).
The suspend image nowadays is compressed, so it is always less than the active RAM space and swap is unlikely to be heavily used otherwise with today’s large RAM banks in most cases.
That is unless the system is used in unusual ways, of course, like suspend-to-disk just in the middle of a massive compile/build process or database heavy lifting and such.
Anyway the system quickly becomes unresponsive beyond 1-2 GB of swap use during normal operation, even with SSDs; swap is not a substitute for enough RAM.
I have been happy for years with half RAM space, say 8 GB swap for 16 GB RAM. 8 GB swap for 32 GB RAM might hit the ceiling in corner cases IMHO.
Setting the swap at the end of the disk is a good idea anyway; reserving, say, 32 GB at the end for swap+some blank space allows some flexibility:
it is easier to grow or reduce a swap space than moving or reducing a data partition, so start with 8 GB swap and grow if needed;
the remaining blank space allows the SSD firmware some flexibility in block allocation and recovery, generally speeding up operations;
if you need a (temporary?) extra partition to test a new install, an experimental sandbox or the like you can easily (temporarily?) reduce or even eliminate the swap space and use the blank space at will.
The information on this issue is very conflicting. Some say it’s mainly a firmware issue. I use Windows and have Samsung Magician installed so I can easily upgrade Samsung firmware.
But then some say it’s definitely a chipset issue in which case I’m out of luck since I’m not looking be replace my mainboard anytime soon.
@Svyatko Both of my M.2 slots are already in use so I’ll be using a 2,5" SATA drive.
@OrsoBruno Thank you for the write-up and especially mentioning the option to leave blank space at the end after swap. I had no idea it could be useful.
Regarding the AMD compatibility, since the news you are quoting is based on the fact that their SATA controllers exhibit issues with various Samsung SSD, these controllers are the AMD/ATI SB7x0/SB8x0/SB9x0 (and do not appear on recent AMD SATA adapters)
FWIW, the aforementioned affected southbridges are quite old. Therefore, there should not be that much drama around this, especially since many won’t be impacted (basically, motherboards fitted with an AM4 socket are unaffected).
And then:
To check if you are “at risk” of being affected, you could check if the southbridge of a machine (MB for AMD CPUs) is to blame with the following command: dmesg | grep -i SB7x0/SB8x0/SB9x0
Since I have an AM4 board and didn’t get any results from dmesg, everything points to the conclusion that the drive I ordered should not be affected by the mentioned TRIM issue.
But still thanks for pointing it out. I learned something new.
Now, I’ll return to my original question: is there a step-by-step guide on how to migrate a Tumbleweed installation onto a new drive? If not, where should I start researching?
Direct cloning of the old drive may not be the best approach, since the partitioning scheme on the new drive should be different.
Stick to KISS. With respect to partitioning of the SSD this boils down to:
erlangen:~ # fdl /dev/nvme1n1
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 990 EVO 2TB
Disklabel type: gpt
Disk identifier: 9CC8F3A2-0DC2-4237-8673-D76DCF8AF37F
Device Size Type
/dev/nvme1n1p1 100M Microsoft basic data
/dev/nvme1n1p2 1.8T Linux filesystem
erlangen:~ #
Current UEFI didn’t complain. However moving the drive to another system could cause trouble:
erlangen:~ # fdl /dev/nvme1n1
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 990 EVO 2TB
Disklabel type: gpt
Disk identifier: 9CC8F3A2-0DC2-4237-8673-D76DCF8AF37F
Device Size Type
/dev/nvme1n1p1 100M EFI System
/dev/nvme1n1p2 1.8T Linux filesystem
erlangen:~ #
Boot loader is small:
erlangen:~ # find /boot/efi/ -type f
/boot/efi/EFI/tumbleweed/grubx64.efi
/boot/efi/EFI/BOOT/BOOTX64.EFI
erlangen:~ #
erlangen:~ # df -h /boot/efi/
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1p1 100M 662K 100M 1% /boot/efi
erlangen:~ #
@karlmistelberger Thanks for the tips. Your workflow in the other thread might be doable, although I don’t understand everything about it. I’ll see what I can dig up on the commands and making my own ISO image.
So, I watched some videos about CloneZilla and then discovered the GParted live image. As a test, I used it to resize my EFI partition and increase my swap to 16 GB. This involved moving the Btrfs partition back and forth.
I figured performing this as a test on the old drive doesn’t carry much of a risk, since I don’t have anything critical stored on it.
But this way I also got some of the recommended adjustments done in advance.
My best course of action could be to first use CloneZilla to make an ISO of the entire drive and store it on an external disk.
Then swap the 850 EVO to the 870 EVO.
Then boot to CloneZilla and write the ISO to the new drive. This would recreate the old partitions.
And finally use GParted again to increase the Btrfs partition size and create any new ones if I want to.
On paper at least this feels like a suitably noob-friendly method.
which looks like that is still the case…