Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD
On 08/12/2021 19:35, Jorge P. de Morais Neto wrote:
Hi. Thank you for your response.
Em [2021-12-08 qua 14:49:50+0000], piorunz escreveu:
I understand you have one SATA 2.5" slot in your laptop and one NVMe
slot, and you want to utilize them both.
That is correct.
On the SSD I intend to leave 35 GB unpartitioned for extra over
provisioning. It would have just one 215 GB partition.
Leave more overprovisioning if you can. Use Btrfs with zstd compression
for your / and /home, you will gain many gigabytes.
How much overprovisioning would you recommend? I can probably afford
more indeed (because of the 1 TB HDD), but excessive overprovisioning
could increase the risk of the system failing due to lack of disk space
during some important task. Also, I heard that Linux filesystems like
having some reasonable (some say 10%) internal (within the filesystem)
free space.
As much as you can spare. Of course give any filesystem on NVMe a space
to breathe. It's up to you.
This doesn't make any sense. Don't run RAID1 SSD+HDD. You will kill
all gains SSD NVMe provides.
I lack RAID experience, but I assumed the kernel would easily be smart
enough to read from the fastest RAID member (SSD), so read performance
would be great. And I hoped the kernel would also be smart enough to,
on writes, write to the SSD first and later (asynchronously) replicate
to the HDD. But now a quick web search indeed suggests that those
optimizations are not default or common, so we can drop the RAID idea.
This is due to mdadm, not Linux kernel. You were going to use mdadm,
correct?
async writes may be possible in a way you described, but don't bet it
will be working like that out of the box. Out of the box, with mdadm,
you will have performance of HDD, no gains whatsoever.
- noatime: I didn't know about this issue, I thought relatime was
efficient enough. Thank you for the tip!
You are welcome!
- nodiratime: According to the mount manpage, noatime implies
nodiratime.
It' been long time since I review this. I will check again and fix my
own mount options if this is not necessary :) Thanks.
- ssd: Does btrfs not autodetect SSD? Why provide ssd option?
I am not sure if Btrfs autodetects SSD. SSD mode is enabling some
optimizations. If you decide to read on it, please share if you find
anything.
- Why `compress-force' instead of simply `compress'?
I've read very extensive discussion about that and came to conclusion
that compress-force is better. It's checking every chunk of file for
compressibility. "compress", on the other hand, checks only first
sectors, then drops compression if no compressible data is detected.
Imagine your qcow file, first 1 GB is not compressible, so "compress"
option will drop compression of that file right away. But remaining 20GB
are zeros because you haven't filled that yet. With compress-force, you
compress these zeros to nothing. File takes 1GB of space. You don't have
that on ext4, or btrfs "compress" only option.
For more context, my DE is Gnome and some of my most often used
applications are:
- GNU Emacs
- notmuch and offlineimap (I am considering switching to mbsync)
- GNU IceCat and Mozilla Firefox
- Gajim and GNU Jami
- Nextcloud (it is always running but rarely syncing changes)
- Gnome Boxes or Virtual Machine Manager running a VM with 2 GiB RAM and
one .qcow2 disk image currently weighting 24 GB.
Kind regards!
In your use case, I would use partitioning suggested earlier. Place
Virtual Machine Manager images folder on HDD. Your / and /home will be
very small and totally manageable, while select folders like VMM images,
will live on HDD. Then all backups are up to you, but you not losing any
speed of your brand new NVMe.
--
With kindest regards, Piotr.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀
Reply to: