Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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 '13 at 14:02
add comment

2 Answers 2

up vote 19 down vote accepted

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 :).

share|improve this answer
3  
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 '13 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 '13 at 17:52
    
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 at 23:02
add comment

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).

share|improve this answer
1  
"This will avoid data corruption": it may not, see sourcejedi's answer and my comment. –  Totor Mar 22 '13 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 '13 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. –  Joel Davis Mar 22 '13 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 '13 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. –  Joel Davis Mar 22 '13 at 14:01
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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