Share an ext4 filesystem between two RHEL servers, but only one will mount at a time

Question

I have two RHEL 6 servers which share a physical connection to a SAN storage (i.e., so both servers can see this /dev/sdb when running fdisk -l).

My goal is not to have both servers access the ext4 at the same time. In fact, one of the servers will be mounting it for most of the time. Only when the first server fails, I will want the other server to mount this ext4 filesystem.

I already created logical volumes and have tested that both servers can mount this filesystem successfully. I am going to write scripts that are going to check and make sure the volume is not mounted on the other server before mounting.

My question is, when servers take turns to mount an ext4 filesystem like this, will there be underlying problems that I am missing? I fear that the OS might have some check or "notes" on the volumes...

Answer 1

There is no problem to use ext4 in this manner, and in fact this is done commonly with file servers (e.g. dual-homed NFS servers, or large cluster filesystems like Lustre) in a High Availability (HA) configuration. There is even an ext4 feature - Multi-Mount Protection (mmp) that is intended to be used in conjunction with HA software to reduce the risk of corrupting your filesystem from being mounted on two nodes at the same time.

That said, you definitely should use existing HA software like Corosync/Pacemaker (included by default with RHEL/CentOS) to manage the storage, instead of writing your own (which is a recipe for losing all of your data). Together with hardware power control (e.g. powerman) for STONITH and mmp (for backup in the rare case Corosync/Pacemaker fail) you can safely mount a single ext4 filesystem on two or more servers - on one server at-a-time.

It wasn't clear from your question, but note that sharing LVs/partitions on a single disk between the servers at the same time is NOT very safe. You should only access whole disks from any of the servers at one time.

Answer 2

Actually there is a common scenario which I did many times when you unmount file system and mount it from another OS installation. It is called "recovery".

Whenever you do recovery you boot for example from OS on your CD or other computer installation and make changes on file system. You unmount it and boot from original OS and everything works correctly.

This scenario is something like standard maintenance task I (and probably every experienced linux administrator) done dozens of time without issues.

Furthermore you can for example mount USB drive on one computer, unmount it and mount on another computer without issues as well.

---

Of course there are also some notes on file system. It is not dependent on specific installation but rather store important FS attributes like "mount options, file system state - clean, etc...".

You can read about these attributes when you call

man tune2fs

---

I would not be so much worried about situation when you correctly unmount file system and mount it on different OS as much as I would be worried about correct locking mechanism etc... Ext3/4 filesystem is not created for clustering usage and I do not understand why are you trying to do so.

There is alternative OCFS2 (Oracle Cluster File System 2) which is free, open source and in Linux kernel specifically created for this type of situations. I do not see reasons why not to use OCFS2 and rather do self-made (read "with unknown bugs") locking system when you can use tested and free solution.

Answer 3

So long as the filesystem is unmounted cleanly, there is no reason those two hosts cannot share that device the way you have just described, provided there is a common userId (UID.) If Alice is user id 1001 on host A, and Bob is user id 1001 on host B, then a directory on /dev/sdb mounted at /mnt/yourshareddevice/somedirectory owned by Alice on host A will be owned by Bob on host B.

Personally, I'd find it more convenient to share that device through a more traditional network file storage solution (NFS, SMB, Gluster, etc) but what you're describing is feasible and functional.