Install on SSD/HDD system - what approach

[Kerlaugar]

Hello all,

I'd like to install Debian Testing on a system with an (256GB) SSD and a (4TB) HDD. It'll be used by 1 or 2 users as a desktop system for typical desktop applications, but also some multimedia watching/listening. No other OS's will be installed.

I've found these earlier topics, but they are relatively old and don't answer all my questions:
viewtopic.php?t=104110
viewtopic.php?t=122099

Of course I'd like to get the benefits of the speed of the SSD and the large storage capacity of the HDD. Normally I install Debian using "Guided partitioning with encrypted LVM". I don't think I ever used separate partitions for /home or anything else. I only have experience with systems with only an HDD (and no SSD, so just 1 storage device).

For Guided partitioning, you have to choose which disk to install Debian on. You cannot choose both, I think.

1) What's the best approach to use both the SSD and the HDD?
2) Should I now choose manual partitioning? Or simply install everything on the SSD and later add the HDD somehow? I would prefer to only enter 1 passphrase to unlock the encryption for both disks.
3) Is it advisable to have /home, /swap, /var, /temp in a separate partition as suggested in the older topics?

I've been using Debian for about 10 years, but I'm more an end user than a developer, so suggestions/explanations are very welcome!

[CwF]

How far do you look ahead?

I would install to the ssd as if the HD doesn't exist. Then integrate in whatever way, knowing you can change, upgrade, add subtract, back up the OS to the HDD...I would not lock it into some integrated unit that does nothing more than increase the available failure modes! Do your pics movies and mp3's need to be encrypted? The minority of personal things that may benefit from encryption would exceed the 240GB?
KISS

#3 No, that old school.

[Kerlaugar]

Thanks for the very sensible advice. You're right, the data that I want to be encrypted is relatively minor volume wise. The videos and music that I want to store aren't private, perhaps there will be a few exceptions, but so few that I don't need the HD for those. I was overthinking it. I'll go ahead with my install and will add the HD as a non-encrypted device only after installing Debian on the SDD.

[p.H]

For Guided partitioning, you have to choose which disk to install Debian on. You cannot choose both, I think.

No, you can only choose one disk.

1) What's the best approach to use both the SSD and the HDD?

Put the whole system including /home and swap on the SSD.
Put data files which do not require fast access time, such as audio/video files, on the hard disk.

2) Should I now choose manual partitioning? Or simply install everything on the SSD and later add the HDD somehow?

If you know what you want, I advise to use manual partitioning anyway.
If the hard disk does not contain any system directory (including /home) you may either ignore it during installation and add it later, or add it during installation.

I would prefer to only enter 1 passphrase to unlock the encryption for both disks.

There are different means to type only one passphrase with multiple encrypted devices.

1) Create a single encrypted volume. This is possible even with two or more drives using RAID 0/linear or LVM. But I do not recommend agregating a hard disk and a SSD because it is harder or impossible to force the use of one or the other to store a given contents. Also failure of one drive ruins the whole volume.

2) Store the passphrase for the non-root device into the encrypted root device. But any process running with root privilege will be able to read it.

3) If both encrypted devices have the same passphrase and plymouth (boot splash screen) is installed, the passphrase is asked only once. Beware that plymouth significantly increases the initramfs size in /boot.

3) Is it advisable to have /home, /swap, /var, /temp in a separate partition as suggested in the older topics?

I guess you mean "swap", not "/swap". Swap is not a filesystem, you cannot mount it. Swap can use files, but the Debian installer supports only swap devices, not swap files. You can create and add a swap file after installation but I do not recommend it, as using a swap file is a dirty hack.
Separate /home, /var and /tmp are advisable if you fear that a user, stray process or log may fill the whole filesystem. LVM makes it easier by allowing to conveniently increase a logical volume size when needed as long as the volume group has enough free space.

[CwF]

I don't consider zram to be a dirty hack, I consider it the preferred modern solution. Along with the outdated concept of multiple partitions, the old advice addressed technical limitations that may not be present in a modern system. The momentum of the old techniques is still around, but we can plan around them.

Generally, the OP has started with what I consider the optimum minimum, That is an OS device, self contained, and bulk storage device (a personal assistant). The next spec to consider is RAM. This decides the swap features, not some generalized rule. If you take my 'optimum minimum' and dig deeper you may get to my next preferred spec recommending more ram, less OS disk. Makes life much easier. Beyond that we need to clarify this non-general advice diverges between big-box and portable device. If we are talking a desktop, maybe ask how many disk controller ports are there? Cool, use them!

Since I flipped my thinking a few years back, every iteration my OS device gets smaller and smaller. I don't bother using the entire 'chip' for the OS and leave a majority unpartitioned space on this 'OS device'. This 'partition' is 10-50% the volume of ram. Obviously I don't hibernate. This OS swimming in ram then has a 'support staff' scattered over those 'spare' ports. I reserve one of those ports for another easy $20 feature, a secondary parrallel/nested OS.

There are multiple 'slots' available to decrypt. A usb key could stay in the machine, or removed, or fail, and as I understand hardware detection can be used, if either fail you fall back to the prompt. I like backing up with images, and an encrypted volume locks the size from the benefits of compression. I've come to question the benefit of an encrypted OS once segmented like I describe. One of that support group of devices could be encrypted, better yet could be virtually/physically 'offline' when not needed.

You can install without swap. I'd like to see a zram default in that case at that point in the installer. It is a default already in other OS's. In the partition setup I'd like to see the ability for full disk encryption to leave open space. On the other hand I prefer 'golden images' and don't bother with installers anymore, somewhat chicken-egg maybe, but once you have a few viable eggs no more chickens are required! Overall, I have found no factor that cannot be altered post installation.

[p.H]

I don't consider zram to be a dirty hack

zram has nothing to do with swap files. It is a regular block device which does not violate the filesystem layer, so it fine.

I don't bother using the entire 'chip' for the OS and leave a majority unpartitioned space on this 'OS device'.

This sounds like a contradiction. The OS cannot use the entire device if some space is unpartitioned, it can only use the partitioned space.

This 'partition' is 10-50% the volume of ram

So if the OS uses, say, 10 GB disk space, then the machine must have at least 20 GB RAM ? I wish all my machines have so much RAM !

There are multiple 'slots' available to decrypt. A usb key could stay in the machine

And stolen with the machine.

In the partition setup I'd like to see the ability for full disk encryption to leave open space

This is possible with manual partitioning.

[CwF]

zram has nothing to do with swap files

It has everything to do with swap space. It is swap space. It is prioritized over disk swap and substitutes partial or fully any disk space. I recommend it in addition to, or in place of disk swap. I use both or only zram. Install zram-tools on a live system with a small amount of disk swap in use and watch as it migrates. Soon the disk swap will be empty, and possibly stay empty. Once you get to a machine proportioned like I like, and over the conceptual issue of why one would use ram as swap, and realize it's historical and things actually do run smoother and safer with swap, and the form of that swap in fungible, it makes lots of sense.

This sounds like a contradiction

It is strange, but I skipped the why. I mentioned images and encryption locking image size. So in a lowest common multiple kind of way I keep the OS image sized as needed and not sized to a particular device.. My systems will not live life on the same media as installed. I no longer pay attention to the slop. A small image images faster, restores faster, and if needed be tested or fixed virtualized entirely in memory, it happens. This system now is on its 5th disk on it's 4th motherboard, born May 7th, 2016. I wish medical science was this good! The upgrade to bullseye will celebrate on a new disk when ready, and already done as an image, waiting...

I wish all my machines have so much RAM !

Sure, but there is no must! Preference, world view changing preference! At 10GB OS size I'm closer to 10% than 50%. So keep going! I'm not sure where the mentioned bullseye will end up. The image is currently 2.5 GiB plus a gig of cruft within a virtual partition size of 17GiB. On my machine possible to test while in memory, and leaving 10GB free virtual disk space under operation. The 17GiB is the safety hatch for running in memory, not the runtime size on disk or use consideration. When live I will grow it to whatever. Next major upgrade I will clean it and truncate down to the current manageable size, I'd guess <32G, a size I can now manage in memory.
Enough memory changes the way thing are done. Swap in ram, firefox profiles in ram, top layer vm runtimes in ram (/pool/ram is 20GiB, need ~10) and large media editing is directed to /pool/vram (20 GiB, need more) anything else I can think of, in ram! The actual user stat is 20-40GiB, plus the unreported things mentioned. I would not trade this for 20GB of ram with all the disk space in the world!

Anyway, like I said, look ahead. There are many technologies looking to merge the OS storage and runtime into the same thing. The common element is 'external' mass storage. So when some new system operates from common pool of memory that also holds the OS itself in non-volatile hybrid ram, you won't want a 240GB OS image. Intel and Micron both have this type technology and currently 16-32 GB would be a reasonable size for a <10GB OS footprint. Really we see this use case in phones already. It adopts fine to a desktop scale, without the old school ways.

[p.H]

(about zram)

It has everything to do with swap space

No it doesn't.

It is swap space

No it isn't. zram is just a compressed RAM-based block device. It may be used like any other block device, including as - but not limited to - swap.
From the kernel documentation :

Code: Select all

The zram module creates RAM based block devices named /dev/zram<id>
(<id> = 0, 1, ...). Pages written to these disks are compressed and stored
in memory itself. These disks allow very fast I/O and compression provides
good amounts of memory savings. Some of the usecases include /tmp storage,
use as swap disks, various caches under /var and maybe many more :)


It is prioritized over disk swap

No it isn't. Only if you set it so.

zram-tools

This package is a misnomer. It does not contain any zram tool. It just contains a tool and associated systemd service which sets up zram devices as swap. It should be named "zramswap", like this tool. zram itself is managed through /sys and does not require any specific tool.

[CwF]

his package is a misnomer. It does not contain any zram tool. It just contains a tool and associated systemd service which sets up zram devices as swap. It should be named "zramswap", like this tool. zram itself is managed through /sys and does not require any specific tool.

Fair enough, my use of the term should then be "zramswap"
Then, what I said...!