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
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?
|
