Question: Moving /usr and /var to different partitions - tips ? advice ?

[jalsco]

Hi - is it ok to move /usr and /var to different partition ? ie not the boot partition.

If so - how best to do it on Dietpi ? There are many how-to pages for other linux distros.. something like this : (1) copy to temp folder name, (2) edit /etc/fstab - (3) reboot

I plan to move userdata and usr and var onto other partition (same SSD ) - if that's easy enough....

Ideally also to move /root but I think that might have some problems. Reason I like to move that one is that I usualy log in asroot and done alot of my dev work and SSG gen work in there.. So it is actually "user data" but is under the folder /root

Any problems with this approach ??

[Joulinar]

Theoretically you should be able to follow other Linux guides as well. There should be no problem on DietPi. But personally I don't see much of a benefit using different partitions. At the end it will be the very same SSD.

[jalsco]

ok - and what about /root - is it true it has special considerations and never should be moved ?

[Joulinar]

for some SBC we did something like this in past. At least we offered such an option. Maybe @MichaIng could comment on this.

[MichaIng]

Never for the /root (root user's home directory). And it doesn't make much sense, since not much data is stored/written inside, if you do not do that manually. Generally there is not much problem to move it to an external drive. If it is not available, and you login as root user, root user software configs, if present, and custom login scripts are not loaded. However, this does not break common system usage, i.e. you are still able to login and fix things.

Bu I also do not see much point in moving various system directories to external drives. If you want to reduce disk I/O because the SD card is slow or you fear it breaks fast (reasonably), then flash DietPi onto an SSD directly, or move the complete root partition onto the SSD, if USB boot isn't supported.

Which SBC is it, actually?

EDIT: Ah, having /usr on an external drive can actually break things. Since /bin and /lib are symlinks into /usr on modern Debian systems, and those are required for systemd to start and mount the external drive, you are stuck 😉. The usr-merge was actually done in most modern distros because no one sees any point anymore to have /usr on an external drive. It only exists from ancient time to allow exactly that, but that feature has been deprecated:

• https://wiki.debian.org/UsrMerge
• http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
• http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

[jalsco]

Thanks for the replies @MichaIng and @Joulinar 🙏🏻
After this new information - I certainly will NOT be moving /usr and /root.

What about /var ? - any specific issues ? It is getting quite big - like 15gb - and I expect soon will be double that and growing quickly.

I know dietpi_userdata will be ok - and it so easy to do by using dietpi-drive_manager. As that move (userdata to a different drive ) is seemingly encouraged - what is the rationale behind that ? My belief (not rooted in any hard facts) is that often userdata will have big datasets that may be volatile - esp with alot of MySql usage, or NextCloud , or lots videos etc (all of which store in userdata. And in that case - big and volatile - can be more prone to disk corruption. So is a good idea to keep it away from the boot partition. Also with size - more easily expanded and moved again later to somewhere even bigger - if setup on its own partition. And no risk of suddenly consuming all space on the /boot partition....

Thats why I thought userdata was "encouraged" to be moved.... But I learn so much whenever either of you reply - so please provide your thoughts... to correct/guide my thinking.

If there's no compelling reason to move userdata - I will probably just leave both /var and userdata on the boot partition and expand it to a huge number. I am thinking that may make a backup protocol a bit more difficult - or a bit different that my current plans.

p.s. one reason for me doing this - is so that I can always have on standby a (very recent) exact clone of /boot partition on an SD, as a backup. To do that I need to ensure that the size of the boot stays relatively constant and small enough to fit - not growing to 100+ 200+ all just on one single partition. From what you are saying - maybe my thinking is flawed and one single partition of 200+ in size is no real problem.... 🤷‍♂️

[MichaIng]

What about /var ?

It should work. But of course it is important to have it available as well, since system core files are stored inside. The safer alternative would be to identify the dir/software which creates such large data inside and link it to dietpi_userdata, e.g.:

mv /var/lib/foo /mnt/dietpi_userdata/foo
ln -s /mnt/dietpi_userdata/foo /var/lib/foo

This is what we do with many software installs where we know that this dir is heavily used or because we want to make it easier for users to find all relevant configs and data one userdata dir, for backups or when flashing a fresh DietPi image.

Your thoughts why dietpi_userdata can and is recommended to be moved to an external drive is correct, at least when the system drive is an SD card, or also for potential performance benefits when disk I/O is shared between two drives.
For /var, the same would apply, with the difference that /var is an FHS (default Linux) directory and hence more important to exist and for basic OS functionality than selected additional software data dirs.
E.g. dpkg uses it to store installed package states and maintainer scripts. If /var cannot be mounted and you need to reinstall a package (which provides a library of the mount command) to fix it, it won't work easily, since dpkg does not know anything about installed packages (/var/lib/dpkg missing) and because no /var/lib/dpkg/info/*.(pre|post)rm scripts are present, the already installed package cannot be correctly configured. And when /var is mounted again, all state changes which were done in between are lost. A pretty hypothetical case, though 😉.

[jalsco]

Thank you for your reply ! 🙏🏻🙏🏻👍