I'm planning on doing a migration of my Debian installation from one disk to another in the near future. As a part of that, I'm thinking about setting the file systems up differently, for future-proofing as well as for simplifying the setup.

My current setup is a one-device RAID1 LVM (I originally intended to set up mirroring of the system disk, but never got around to actually doing that) on a partition on a SSD. That RAID1 in turn holds the ext4 root file system, with /opt plus parts of /usr and /var separated onto ZFS storage. Particularly, /boot is part of the root file system, and I'm booting using old-style MBR using GRUB 2.

The idea is to have a large root file system with a *nix-esque file system (probably ext4 to begin with), and to separate out the parts that have special needs.

I'd like to leave open the possibility of migrating to UEFI boot later, possibly including a migration to GPT, without needing to move things around. (Backup/repartition/restore is another matter, and will likely be needed for migrating from MBR to GPT, but I'll probably be getting a new disk again before that becomes an issue.)

I'd also like to have the option to migrate the root file system to ZFS later, or at least to set up dm-verity for data integrity verification. (Yes, it'll be a bit of a headache to get everything about that right, especially semi-in-place. That'll be a matter for a later day; their only consideration for this question is in terms of later options.)

This all seems to make an obvious case for separating /, /boot and the FAT32 /boot/efi (the last of which may initially be empty), in addition to those that I have already separated from the root file system. But are there others?

  • Which system file systems, backed by persistent storage, should be separated from the root file system and why on a modern-day Linux installation?
  • Do any of these file systems need to go onto specific partition locations when using MBR, or are their locations arbitrary? For example, would /boot/efi need to go onto the first primary partition or something like that?
  • 1
    To whoever voted to close: How is this primarily opinion-based? I specifically ask for the reasoning, not just a laundry list of file systems, and I restricted it to system file systems backed by persistent storage, and I specify a set of objectives I'm looking to have met by suggestions in answers. Yes, one could argue that there is some opinion involved, but those opinions should be amply supportable by fact and references. Compare Good Subjective, Bad Subjective. – a CVn Jun 17 '18 at 6:23
  • Recent kernel versions/GRUB? are more than happy on not having a /boot partition anymore. I prefer to not have it than having to plan growing it when the kernel grows or having problems when more than x versions keep behind. This way I just worry on / having free space. I would go to GPT before using ZFS if I were you. – Rui F Ribeiro Jun 17 '18 at 7:25

At a minimum, separate package-managed directories from non-managed directories.

In my experience the non-managed directories are typically (but not necessarily exclusively) /opt, /usr/local, and of course /home.

(I also mark files within the package managed-directories that I have edited manually, so it's easy for me to identify them at an arbitrary point in the future.)

| improve this answer | |
  • 1
    I'd be careful with /opt. Third-party packages that install into /opt tend to use /etc/opt/... and /var/opt/.... See pathname.com/fhs/pub/… – Andrew Henle Jun 17 '18 at 11:46
  • @AndrewHenle thank you for that. I've only really come across /opt/{application}/bin, /opt/{application}/etc , /opt/{application}/lib style installations. – roaima Jun 17 '18 at 13:22

First off, this is largely opinion based. If you ask a dozen different people, you're likely to get at least 3-4 different answers.

That said, here's my opinion on this:

  • Keep /home separate from /. The primary reasoning here is largely along the same lines as it always has been. It makes it harder for your users to accidentally use up all of the space on /, and it makes it significantly easier to keep user data if you need to re-install. Additionally, it isolates one of the largest parts of most systems from the rest of the system, which can be particularly useful for managing backups.
  • Keep /tmp and /var/tmp separate from /. Both of these areas are used for temporary storage, and the amount of churn this can induce on the root filesystem can have a significant long term impact on it's performance. Additionally though, the data is guaranteed to be transient with a relatively short lifetime. This means you shouldn't be backing them up (it's just a waste of space), and probably won't be copying them when you move to a new disk. That said, /tmp should generally be a tmpfs instance these days, and /var/tmp generally should be too if you can fit everything likely to be there in RAM.
  • A bit controversial and a lot more invasive, but isolate your global cache directories from the filesystems they would normally be on. The canonical example is /var/cache, but there may be others depending on your particular system (I think /var/cache covers it completely on Debian though). This has a lot of the same advantages that isolating /tmp, /var/tmp, and /home does, but it also gives you a clear cut area that you don't need to back up (it's a cache, if an application breaks because it can't find data there, it's a poorly written application), and thus also don't need to copy when you move to a new disk.
  • Keep your data sets separate from /. This is intentionally abstract, but includes such things as the pages and data for any websites the system is hosting, the backend-storage for any database or directory services the system provides, and other such things. Isolating this data provides two big benefits. First, it provides the same general benefits that keeping /home separate from / does. Second, it at least partially decouples the performance of the root filesystem from the performance of your data volumes. This also allows you to transition these data sets to different storage configurations without directly impacting the rest of the system, which can mean the difference between an online maintenance period (where service is just degraded, but not completely shut off) and an off-line one.
  • Keep 'throwaway' data that can be trivially regenerated or reacquired separated from other data. Examples include publicly accessible data from the internet (git repositories, package repository indexes, ISO images, etc), and things that are just so trivial that you wouldn't be backing them up. This is mostly to simplify planning of backups, but it can also help when switching to a new disk (namely, you don't have to copy most or even all of this data, because you can just reacquire/regenerate it as needed).
  • Keep directory structures not managed by your package manager separate from those that are. This isn't mandatory, but can greatly simplify both upgrades and reinstallation. This technically includes the stuff I mentioned above, but in this case I'm more specifically referring to /opt and /usr/local. Note that /opt may contain data managed by your package manager (for example Dropbox and Google Chrome both install there).
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.