Re: Desynchronizing dm-raid1

>>>>> "Malahal" == malahal 
<malahalus.ibm.com> writes:

[I sent this last week but it never made it to the list]

Malahal> Very few drivers require it, so how about an
interface to
Malahal> lock the pages of an I/O available to drivers.
Only needed
Malahal> RAID drivers would lock the I/O while it is in
progress and
Malahal> they only pay the performance penalty.  mmap
pages are a bit
Malahal> tricky. They need to go into read-only mode when
an I/O is in
Malahal> progress. I know this would likely be rejected
too!!!

I have exactly the same problem with the data integrity
stuff I'm
working on.

Essentially a checksum gets generated when a bio is
submitted, and
both the I/O controller and the disk drive verify the
checksum.

With ext2 in particular I often experience that the page
(usually
containing directory metadata) has been modified before the
controller
does the DMA.  And the I/O will then be rejected by the
controller or
drive because the checksum doesn't match the data.

So this problem is not specific to DM/MD...

-- 
Martin K. Petersen	Oracle Linux Engineering

--
dm-devel mailing list
dm-develredhat.com
http
s://www.redhat.com/mailman/listinfo/dm-devel

Martin K. Petersen [mkpmkp.net] wrote:
> >>>>> "Malahal" == malahal 
<malahalus.ibm.com> writes:
> 
> [I sent this last week but it never made it to the
list]
> 
> Malahal> Very few drivers require it, so how about
an interface to
> Malahal> lock the pages of an I/O available to
drivers. Only needed
> Malahal> RAID drivers would lock the I/O while it is
in progress and
> Malahal> they only pay the performance penalty. 
mmap pages are a bit
> Malahal> tricky. They need to go into read-only mode
when an I/O is in
> Malahal> progress. I know this would likely be
rejected too!!!
> 
> I have exactly the same problem with the data integrity
stuff I'm
> working on.
> 
> Essentially a checksum gets generated when a bio is
submitted, and
> both the I/O controller and the disk drive verify the
checksum.
> 
> With ext2 in particular I often experience that the
page (usually
> containing directory metadata) has been modified before
the controller
> does the DMA.  And the I/O will then be rejected by the
controller or
> drive because the checksum doesn't match the data.

Your problem is very similar to an iSCSI problem sumitted
here:
http://now.netapp.com/NOW/cgi-bin/bol?Type=D
etail&Display=137902

Fortunately, you can detect the problem and the I/O can be
retried if
possible. In the RAID case, it goes undetected until you hit
the
eventual corruption!

--
dm-devel mailing list
dm-develredhat.com
http
s://www.redhat.com/mailman/listinfo/dm-devel

On Mon, 7 Apr 2008, Martin K. Petersen wrote:

>>>>>> "Malahal" == malahal 
<malahalus.ibm.com> writes:
>
> [I sent this last week but it never made it to the
list]
>
> Malahal> Very few drivers require it, so how about
an interface to
> Malahal> lock the pages of an I/O available to
drivers. Only needed
> Malahal> RAID drivers would lock the I/O while it is
in progress and
> Malahal> they only pay the performance penalty. 
mmap pages are a bit
> Malahal> tricky. They need to go into read-only mode
when an I/O is in
> Malahal> progress. I know this would likely be
rejected too!!!
>
> I have exactly the same problem with the data integrity
stuff I'm
> working on.
>
> Essentially a checksum gets generated when a bio is
submitted, and
> both the I/O controller and the disk drive verify the
checksum.
>
> With ext2 in particular I often experience that the
page (usually
> containing directory metadata) has been modified before
the controller
> does the DMA.  And the I/O will then be rejected by the
controller or
> drive because the checksum doesn't match the data.
>
> So this problem is not specific to DM/MD...
>
> -- 
> Martin K. Petersen	Oracle Linux Engineering

BTW: is it guaranteed for crypto functions that they read
the source data 
only once?

I.e. if you encrypt a block while another CPU modifies it,
and then 
decrypt it, is it guaranteed that each byte of the result
will be either 
old byte or new byte of the original data?

If not, we have a subtle case of disk corruption here too.
(imagine that 
you update for example atime field in inode while the block
is being 
written and the crypto interface will trash the inode
block).

Mikulas

--
dm-devel mailing list
dm-develredhat.com
http
s://www.redhat.com/mailman/listinfo/dm-devel