Is it possible for the root and home partitions to have different filesystems and to be located on seprate physical devices?

10

1

Imagine I formatted the root with an ext3 filesystem on a separate partition that happens to exist on a SATA HDD and the home directory on a different btrfs partition that happens to exist on a Intel SSD.

I downloaded a file from the Internet and temporarily saved it to /tmp (in the root filesystem), then I decided to move it to my home directory (the second partition).

I can feel the painful process that happens in the background to make such a simple mv command work.

So, first, is it possible for the root and home to have different filesystems? Secondly, assuming the answer for the previous question was "yes", how does the OS manages all that transition from ext3 to btrfs and then using different device drivers for different disk types (HDD and SSD)?

Karim Manaouil

Posted 2017-06-03T03:31:37.273

Reputation: 231

3It's done with layers. The filesystem layer in built over the block device layer. You can use any suitable filesystem in the filesystem layer. You can use any suitable block device in that block device layer. Each mount point can have its own filesystem and device. – sawdust – 2017-06-03T04:02:52.170

@sawdust, that is a very interesting thing you pointed to, the filesystem layer and block device layer. How do they relate ? Any readings will be helpful. – Karim Manaouil – 2017-06-03T04:18:04.850

Don't know THAT much about file systems, but I assume the process would not be that different from copying files to an external FAT32 drive – Blaine – 2017-06-03T06:36:06.257

http://www.kevinboone.net/linux_kernel_file_0.html – sawdust – 2017-06-03T08:52:41.260

Why do you still use ext3 in 2017 when it's so simple to upgrade to ext4? – David Foerster – 2017-06-03T16:50:19.403

@DavidFoerster I'm no using ext3, it was just a random choice to illustrate the situation. – Karim Manaouil – 2017-06-04T00:10:34.783

Answers

25

The answer is yes, you can have any directory on any device, running any file system the OS can support.

So you can have / /var /home /opt and even /home/afr0ck on different devices, different partitions, different file systems.

Not only can you, but it is common. For example, it is always recommended to keep /var and /home on different partitions to / as these are most likely to inadvertently consume disk space - if they fill up, it doesn't impact the system too much. If they are on the same partition as root, it can cause the system to stop.

And you may want different directories to run on different devices for speed reasons. And use different filesystems for different purposes. For example, perhaps ext4 is what you want for the OS files, as they don't change much, but you might want btrfs for /home so you can keep snapshots for backups. These are all decisions that can be made by each person for their specific use case.

The user space part of the OS doesn't need to understand the different device and filesystem types. All it does it ask the kernel to move a file, and the kernel orchestrates everything from there. So the mv command (for example) is filesystem and device type agnostic. The kernel invokes whatever drivers are needed to read and write to the different partitions.

Paul

Posted 2017-06-03T03:31:37.273

Reputation: 52 173

7

Useful to point out that mv(1) first tries to rename(2) the file. Then it falls back to copy-and-delete. So trying to rename is how mv figures out whether it's possible in a FS-agnostic manner. (rename(2) always fails when moving between different devices, whether they use the same filesystem driver or not, @afr0k.)

– Peter Cordes – 2017-06-03T07:35:11.313

1@PeterCordes huh, I didn't know rename was a thing. I've always used mv to rename things. – None – 2017-06-03T11:48:29.350

5@stanri: mv doesn't fork/exec the rename(1) command, it just tries the rename(2) system call. There isn't a standard rename shell command. On some systems, it's the pattern-substitution multiple-file renaming command from util-linux. I wasn't talking about the shell command, just how mv works internally. – Peter Cordes – 2017-06-03T11:53:42.157

Even /usr could reside on a different partition, that is the reason why some truly essential stuff is in /bin /lib and /sbin - whether all installers will support it is another matter. – rackandboneman – 2017-06-04T00:09:59.687

7

Yes, separate filesystems (mount points) can be different filesystem types.  /proc is always a procfs filesystem, and /sys is always a sysfs.  Transient filesystems (sometimes including /tmp) are often tmpfs, and, in workgroup settings, it’s common for the user’s home directories (and their work product directories) to be nfs or other remote (network/shared) filesystem types.

There isn’t any special management for the OS to do.  Up to a point, at the user level, all filesystems look alike, in the sense that an ls listing will look pretty much the same in any directory.  Beyond that point, filesystems don’t interact.  Even between two filesystems (partitions) on the same physical disk, of the same filesystem type, there’s no linkage1.  For example, moving a file from one filesystem (mount point) to another always involves making a copy and deleting the original.  Doesn’t matter if they’re partitions on different disks.  Doesn’t matter if one of them is HDD and one is SSD.  Doesn’t matter if one is ext3 and one is btrfs.  Doesn’t matter if one is internal (inside the computer case) and one is external (a few inches outside, connected by a cable) — or remote (accessed over the network).

Speaking of the network, it’s a little analogous to ssh.  It reads from the keyboard and sends the characters you type to the network.  Simultaneously, it reads from the network and displays the results on the screen.

Or consider this: imagine you’re on the phone, and you’re mediating a conversation between the person on the other phone and another person in the room.  It’s no big deal.
________
1 except for symbolic links — but they can cross filesystem boundaries.

G-Man Says 'Reinstate Monica'

Posted 2017-06-03T03:31:37.273

Reputation: 6 509

1I largely agree with your answer, but its not really typical for /tmp to be a tmpfs (although maybe set like that on some distros) - its normally off the root partition and cleaned at boot. Ubuntu tand Redhat type distros use /dev/shm as tmpfs, – davidgo – 2017-06-03T04:18:57.483

I was confused.  I have updated my answer. – G-Man Says 'Reinstate Monica' – 2017-06-03T04:27:09.507

1@davidgo: What Linux distros don't default to /tmp on tmpfs? I also thought it was pretty much standard practice, since you can always put stuff in /var/tmp (although that isn't cleaned at boot). I'm not an expert on cross-distro defaults, just Debian/Ubuntu and Arch. With those plus RedHat, that covers a large fraction of the installed Linux systems out there (but not nearly as large a large fraction of the total distros). – Peter Cordes – 2017-06-03T07:32:03.710

(ignoring embedded systems) I only use Centos and Ubuntu regularly - both of which use disk for /tmp. - I'm pretty sure this means Debian, Redhat, and Mint will all follow the same convention. My Android device does not have /tmp – davidgo – 2017-06-03T09:32:13.473

2@PeterCordes The rise of tmpfs on Linux is only recent as of the last 5-7 years or so. e.g. Fedora was discussing the change on their wiki ~2012, and I believe it was introduced in Debian Wheezy. – Bob – 2017-06-03T11:08:02.707

OK, here are a couple more data points:  My Kali machine (based on a software download less than 2½ years ago) has tmpfs, but uses it only for /run, /run/lock and /run/shm, but not /tmp.  I don’t recall whether it offered me any options regarding this during installation.  P.S. It also has devtmpfs, which it uses for /dev. – G-Man Says 'Reinstate Monica' – 2017-06-03T19:08:13.803

@Bob "and I believe it was introduced in Debian Wheezy" - It was discussed for Wheezy, but rejected in the end. There is no Debian release that puts /tmp on tmpfs by default. (adding to the discussion, I'm not aware of any mainstream distribution that uses tmpfs for /tmp by default) – marcelm – 2017-06-03T21:35:46.787

@marcelm: Arch puts /tmp on tmpfs by default. I found a 2016 blog post that says Ubuntu still didn't after debating the proposal, but that Fedora does. (And Solaris has done it since 1994). And yes, even if /tmp isn't on tmpfs, /run and various other FSes like that always are. I must have manually configured /tmp on tmpfs on my Ubuntu system and forgot.

– Peter Cordes – 2017-06-04T07:24:02.110

/tmp on tmpfs is generally a good thing these days, with fewer downsides than in the past, because memory is more plentiful on typical systems (with exceptions including tiny cloud VMs). The advantages keep growing, since random access to magnetic hard drives is not getting any faster, while CPU/RAM speed keeps improving. And with modern journalled FSes, creating and then deleting a file right away still tends to produce some I/O. – Peter Cordes – 2017-06-04T07:28:27.167

It depends on the distro. Some do, some don't and some let you configure it however you want. – orange_juice6000 – 2019-04-27T12:29:32.317

Also /boot is usually vfat so efistub works and no boot loaders are necessary. – orange_juice6000 – 2019-04-27T14:38:42.520

@orange_juice6000: I’m not sure what you are saying.  *What* depends on the distro?  Whether /tmp is a tmpfs or not?  Do you believe that that hasn’t been adequately covered by the past two years’ worth of comments? And your statement about /boot doesn’t seem to be particularly relevant to the question, and it doesn’t appear to be at all relevant to my answer. – G-Man Says 'Reinstate Monica' – 2019-04-27T15:40:28.880