4

My objective is to have the physical storage for the Linux FHS read/write directories (/home, /srv, /tmp, /var) on a separate (logical or physical) disk from the potentially read-only rest of the root file system.

I know I can create four partitions on my second disk and use each partition for one of the beforementioned directories using mount. But I don't feel like determining the required storage space for the four directories upfront, even if I may be able to correct the sizes of the (logical or physical) partitions later.

Can this be achieved and how?

Run CMD
  • 590

2 Answers2

3

Similar questions have been asked before. The closest appears to be How to mount multiple directories on the same partition? where this currently accepted answer suggests that it can be in two ways:

  • Using four _symbolic links: in the root filesystem, pointing to four individual subtrees on the second disk, which itself is mounted once to a mount point independent of the four directories.

  • Using bind mounts (available since Linux 2.4) to mount four individual subtrees on the second disk to the four directories, after the second disk is first mounted to a mount point independent of the four directories.

The same answer has an interesting comment which points to this Q&A discussing pros and cons of symbolic links vs bind mounts. From this, one would conclude that symbolic links should be preferred, because they're easier to see and maintain and will cause no trouble with any existing software.

However, systemd has an explicit dependency configuration feature called RequiresMountsFor. E.g. the standard Debian 8 (Jessie) uses it to make some services wait for potential mounts of /var, which needs to be available for the services in question.

systemd's RequiresMountsFor will only work with bind mounts; not with symbolic links.

At least the Debian 8 systemd service configuration files in question are located in /lib/systemd so they are not meant to be modified. This suggests that bind mounts should be preferred if you use a Linux distribution which introduces such systemd dependencies. Modifying the systemd configuration of the Linux distribution may turn system maintenance into a nightmare.

The presence of systemd itself, on the other hand, does not constitute a pro or con point for the choice between symbolic links and bind mounts.

Community
  • 1
Run CMD
  • 590
  • Assume symbolic links are instantaneous. In that case, simply require mount of the single mountpoint of the 2nd disk. In other words - systemd shouldn't affect your choice of bind mount vs. symbolic links. – Dani_l Nov 09 '15 at 12:53
  • @Dani_l I see your point but I'm in a pragmatic mood today. Debian's choice of making services wait for /var to be available is made in systemd config files located in /lib/systemd, not in /etc/systemd. I guess changing these Debian distro files will turn system updates into a nightmare. So although I had a slight preference in favour of symbolic links, this changed since I don't want to be at the maintainer's mercy. – Run CMD Nov 09 '15 at 13:02
  • Fine, in that case modify your answer to reflect that /var mount requirement is pushed by distro, so it's easier to maintain or something to that effect. – Dani_l Nov 09 '15 at 13:08
  • @Dani_l Good point. I've tried to make that more clear now. Thank you for your valuable feedback. – Run CMD Nov 09 '15 at 13:31
  • symlinks are messy. /etc/fstab is nice. another way to do it without specifying explicit size is with btrfs subvolumes. – mikeserv Nov 09 '15 at 13:40
  • also the linked discussion on --bind mounts is incorrect. mount --bind dir1 dir2 is only one way to mount --bind. a linux kernel maintains an entire mount propagation tree, and mounts can be specified per process, per path, per user, or many combinations thereof. its why systemd wants --bind mounts in the first place (besides the mount being more secure, that is). – mikeserv Nov 09 '15 at 13:50
  • I feel like having opened a box full of surprises. @mikeserv Are you suggesting that the presence of systemd is, in itself, a point on favour of bind mounts? – Run CMD Nov 09 '15 at 13:55
  • no. systemd is a soul-devouring octopus. but bind mounts are secure and handled in kernel, and so systemd chooses correctly in this case. – mikeserv Nov 09 '15 at 14:05
2

One option is to use a distro with a merged /usr; then you can mount /usr RO and the rest RW, and have most of the relevant stuff RO. This doesn't catch /etc, though, which you might want. Not quite a solution, more a workaround.

Another is to make a single BTRFS volume with subvolumes for all the mounts you want, then mount with -osubvol=<whatever>. These mounts can have individual mount options, but in the default configuration (without any quota setup) they'll all count against the entire BTRFS volume space-wise, such that you'll be able to put new data anywhere you like as long as the whole FS has space left.

Tom Hunt
  • 10,056