lkml.org 
[lkml]   [2008]   [Mar]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 13 Mar 2008 12:35:53 +0000
From"Duane Griffin" <>
SubjectRe: [RFC, PATCH 0/6] ext3: do not modify data on-disk when mounting read-only filesystem
On 13/03/2008, Daniel Phillips <phillips@phunq.net> wrote:
> Hi Duane,
>
>  Thanks for doing this.  Some perhaps not so obvious fallout from the bad
>  old way of doing things is that ddnap (zumastor) hits an issue in
>  replication.  Since ddsnap allows journal replay on the downstream
>  server and also needs to have an unaltered snapshot to apply deltas
>  against, if we do not take special care, Ext3 will come along and
>  modify the downstream snapshot even when told not to.  Our solution:
>  take two snapshots per replication cycle (pretty cheap) so that one can
>  be clean and the other can be stepped on at will by the journal replay.
>  Ugh.

Ah, good to know, thanks. It looks like you folks are doing some
interesting things there.

>  With your hack, we can eventually drop the double snapshot, provided no
>  other filesystem is similarly badly behaved.

Excellent, I'm really pleased to hear that.

>  Re your page translation table: we already have a page translation
>  table, it is called the page cache.  If you could figure out which file
>  (or metadata) each journal block belongs to, you could just load the
>  page table pages back in and presto, done.  No need to replay the
>  journal at all, you are already back to journal+disk = consistent
>  state.

Hmm, interesting. I'll have to have a think about that, thanks.

>  mapping.  As it stands your solution seems well built, after a quick
>  readthrough.  Nice looking code.  I think you added about 250 lines
>  overall, so tight too.  Thanks again.

Thanks very much, I appreciate it!

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan


\
 
 \ /
  Last update: 2008-03-13 13:39    [from the cache]
©2003-2008