You've got me thinking again now. I know I went into it in quite great detail
sometime ago, but my memory is falible.
There is a good article in InfoExplorer that describes exactly what is
happening, but as I do not have an RS/6000 at home, I cannot look at it!
I'll check next time am at work, and post a reply.
Peter Gathercole.
Paul Hilchey wrote:
> You are quite right that the JFS journal does nothing to guarantee
> the integrity of the data, but neither does mirror write consistency.
> That is, a partial write is always a possibility. MWC just makes sure
> both sides of the mirror have the same data, not complete and valid
> data. Each application has to implement its own procedures to ensure
> the integrity of its data structures.
>
> Consider ADSM writing a backup file into a disk storage pool volume. If
> there is a power failure in the middle of the operation, some blocks of
> the file will have been written, and others not. When ADSM restarts, it
> will have to know that the backup file it was writing is unusable. It
> could know this because its database would not indicate the file as
> being successfully stored. MWC would only make a difference if ADSM
> does make some use of the data it was writing at the time of the power
> failure. I can't determine that since the ADSM documentation does
> not describe the internal structure of disk storage pool volumes.
>
> I'm curious to know if you have any basis for your assertion that a
> parallel mirror write is regarded as complete when only one of the
> physical writes is completed. That does not agree with my understanding
> of how either AIX LVM mirroring or ADSM database mirroring work.
>
> I should clarify the configuration I have:
> - ADSM disk storage pool volumes are files in a JFS filesystem, which
> is on a logical volume mirrored by the AIX logical volume manager
> - ADSM database volumes are raw logical volumes mirrored by ADSM
> That is, the two questions I'm asking are quite distinct.
>
> --
> Paul Hilchey
> University Computing Services
> The University of British Columbia
>
> On Aug 20, 10:15pm, Peter Gathercole wrote:
> >
> > The Journelled filesystem (JFS) does not journal ALL changes to a
> > filesystem, only those that affect the structure of the filesystem. This
> > means that not all writes have journal entries written. The ones that do
> > are those that are to Inodes or directory files, or to the free use
> > bitmap(s). What journelling provides you with is the reduced necessity
> > of running FSCK against a filesystem that was not unmounted cleanly. It
> > does not guarantee the integrity of the data!
> >
> > The advantage that sequential writes gives you is that the write will
> > not return until both copies are written. The converse is parallel
> > writes, where the write will return after the first copy has been
> > written. This could cause databases which do their own journaling
> > problems, as the DB thinks that the data has been written, but if the
> > system crashes before the second copy is complete, there could be
> > inconsistancies. This is where Mirror Write Consistancy comes in, as LVM
> > will be able to determine which copy has the valid data. Turning this
> > off is bad news with parallel writes, as nothing will know if there is
> > inconsistant data between the copies.
> >
> > Peter Gathercole
> > Open System Consultant
> >
> > Paul Hilchey wrote:
> >
> > > There has been some discussion recently about the reasons for doing
> > > sequential writes to mirrored log volumes, from which I've concluded
> > > it is a good idea and reconfigured my system.
> > >
> > > But what about writes to mirrored database volumes? The default is
> > > sequential, though I don't see any good reason for that. As I
> > > understand it, the log replay should correct any problems in the
> > > database resulting from partial writes.
> > >
> > > On a related note, I have my disk storage pool volumes in a JFS
> > > filesystem, which is on a logical volume mirrored by AIX. Can I
> > > turn Mirror Write Consistency off for that logical volume?
|
