Olivier Kaloudoff
2003-Sep-19 13:20 UTC
ext3 hack: using the journal to replicate a filesystem
Hi, I'm looking for a way to use ext3 in the following setup for experimentations purposes: I have a machine A, a machine B, one of which is read-write, and machine B is read-only. I would want the machine B to be the exact copy of machine A, automagically, like it would happen in an SQL replication scheme. Is it possible to do with ext3, using the hidden .journal file as a source for the machine B filesystem ? any feedback would be greatly appreciated. Olivier Kaloudoff
Stephen C. Tweedie
2003-Oct-03 10:14 UTC
Re: ext3 hack: using the journal to replicate a filesystem
Hi, On Fri, 2003-09-19 at 14:20, Olivier Kaloudoff wrote:> I'm looking for a way to use ext3 in the following > setup for experimentations purposes: > > I have a machine A, a machine B, one of which is > read-write, and machine B is read-only. > > I would want the machine B to be the exact copy > of machine A, automagically, like it would happen in an > SQL replication scheme. > > Is it possible to do with ext3, using the hidden > .journal file as a source for the machine B filesystem ?Fundamentally, you need a clustered cache-coherency mechanism to achieve this. Otherwise, when machine A modifies data, there's no way for machine B to know what has changed. In other words, you don't just need to know _what_ has changed, you also need to know _when_. In theory, though, that could be piggy-backed on top of the ext3 replication mechanism. A bigger problem would be that the Linux filesystem layer isn't used to dealing with the fs changing beneath its feet dynamically. Even a readonly copy would be hard to keep totally consistent, as there are all sorts of logical caching effects going on. Linux doesn't cache data based on physical disk blocks, it caches it based on file and offset; and simply replaying a few on-disk disk blocks won't invalidate the file contents in cache. So for live filesystems, you need way more cache coherency than you can achieve just with the journal. Cheers, Stephen
Maybe Matching Threads
- rsync behind a NAT
- Ext3 filesystem aborting journal at random times (Maxtor 300GB disk)
- gluster 10.3: task glfs_fusenoti blocked for more than 120 seconds
- [Gluster-devel] gluster 10.3: task glfs_fusenoti blocked for more than 120 seconds
- short read while checking ext3 journal