17

I know that mounting the same disk with an ext4 filesystem from two different servers (it's an iSCSI vloume) will likely corrupt data on the disk. My question is will it make any difference if one of the servers mounts the disk read-only while the other mounts it read-write?

I know OCFS2 or the likes could be used for this and that I could export the disk with NFS to be accesible to the other server, but I would like to know if the setup I propose will work.

Improve this question
3
  • 1
    It could work only if both mounted read-only (and by that I mean true read-only that does not write). As soon as one side mounts read-write, the other side (mounted read-only) does not expect changes by the other side (mounted read-write), and thus it reads corrupt data. What you need is a cluster-aware filesystem, or a single server that exposes a network filesystem to the other.
    – frostschutz
    Mar 22, 2013 at 14:02
  • 1
    @frostschutz Yes, both ro will work but not without tricks since ext4's ro-mount does write to the actual disk (needs an ro-loop and an overlayfs each).
    – Ned64
    Sep 18, 2019 at 17:35
  • I'll share a use case here: a physical server and a virtual server are sharing a physical disk with disk pass-through. The virtual server is mounting the disk as rw. I would like to copy a large amount of data from the disk but the network is too slow. It would be great if I could mount the physical disk as ro in the host OS and copy the data to an external USB drive. The host server has only one USB controller so PCI-passthrough is not an option.
    – Zhuoyun Wei
    Nov 25, 2019 at 13:20

2 Answers 2

Reset to default
27

No. It won't give consistent results on the read-only client, because of caching. It's definitely not designed for it. You could expect to see IO errors returned to applications. There's probably still some number of oversights in the code, that could cause a kernel crash or corrupt memory used by any process.

But most importantly, ext4 replays the journal even on readonly mounts. So a readonly mount will still write to the underlying block device. It would be unsafe even if both the mounts were readonly :).

Improve this answer
3
  • 6
    As you say, mounting readonly doesn't guarantee that the filesystem will be untouched. If you still want to try for "educational" purpose without taking risks, you should set your device readonly: blockdev --setro /dev/sda1.
    – Totor
    Mar 22, 2013 at 13:07
  • THat's interesting information about the ext4 mount. I suppose one could avoid this problem by forcing ext2 read-only mount?
    – Bananguin
    Mar 22, 2013 at 17:52
  • 1
    I found this snippet of code which let me mount a read-only block device in a VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/…
    – isaaclw
    Jan 30, 2014 at 23:02
0

This will avoid data corruption, but is probably not going to be what you want to do. I've never noticed any issues mounting the volume read-only on another node. Even if something doesn't match up on the ro node usually that just throws a "unexpected free inode, please run e2fsck" or the like into /var/log/messages. If something is dreadfully unexpected about a non-critical filesystem ("/opt/mySpecialmount") usually Linux will just mount the volume read-only (which hey, we're already there). If you're super worried about what effect caching has, you can try to get some sort of drop_caches/vfs_cache_pressure regime going.

To avoid replaying the journal add "noload" to the mount args, do that along with errors=remount-ro (just to err on the side of caution).

That said, chances are that if you're OK with mounting it read-only, it's probably just as a reference for the other node, in which case NFS or smbfs would solve the issue and is designed for a little more concurrency than ext3/4 would be. If you need performance then you could look into a clustered filesystem (little more administrative overhead, but it's there if performance really is something you need).

Improve this answer
6
  • 1
    "This will avoid data corruption": it may not, see sourcejedi's answer and my comment.
    – Totor
    Mar 22, 2013 at 13:14
  • 1
    "skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems" -- man mount. I can imagine there are applications that would detect and/or tolerate inconsistent data in their files, but you haven't mentioned any such caveat so far :).
    – sourcejedi
    Mar 22, 2013 at 13:17
  • @sourcejedi They say that because they're trying to tell people the risks of effectively sidelining the journal. This is alright, because the assumption is that the other node will be doing the journal work for the other node, we're just trying to avoid double work. We do this on one of our development servers (not my choice, I would've done NFS) and have had that thing mounted without even a drop_caches for close to a year without any issues at all. We've both mentioned that non-stale FS cache entries can render old data, but it's ultimately up to the admin to decide if this is workable.
    – Bratchley
    Mar 22, 2013 at 13:23
  • I'm not going to attempt to enumerate all the wrongness in the above comment. But as one data point, it's not just about stale file data in the VFS cache. ext4 will have caches of the filesystem internal data structures ("metadata") as well. You could end up reading data from a deleted file, which was subsequently overwritten by a new file. That's the sort of caveat you really want to know about in advance, even if it's only going to happen infrequently.
    – sourcejedi
    Mar 22, 2013 at 13:40
  • 1
    Looking back at your comment I think you may be trying to refer to block-level caching, which is caching of block device I/O in memory. In which case, it's not caching that occurs in the metadata itself, it's caching OF the metadata itself. It also exists outside of any filesystem drivers so ext4/btrfs/etc don't have any management of it.
    – Bratchley
    Mar 22, 2013 at 14:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .