Yah, and replaying the journal while there are other writers is dangerous: it can undo their changes. So you either make the device fully read-only and make yo

Yah, and replaying the journal while there are other writers is dangerous: it can undo their changes. So you either make the device fully read-only and make your filesystem cope with not being able to do the journal applies.. or you use something like lvm where you can just apply the journal to a snapshot / set of in-memory deltas. But it's worse than this and the above doesn't solve the problems. Say you've mounted already, the filesystem is changing under you, and assume no cache for simplicity (caching makes this even worse): For instance, say update A truncates a file and frees up some storage. update B allocates this free space to another file. Update C writes to it. A different system starts a read, and finds the metadata for the first file. Then it hesitates, and later reads the data from update C in the wrong file. Most filesystems are not written with this use case in mind-- mount readonly while someone else updates. It's something that I've tried doing with varying degrees of success in the past (sometimes perfect, sometimes with strangeness at the application level, sometimes with kernel panics).