On Mon, 7 Apr 2008, Martin K. Petersen wrote:
"Malahal" == malahal <[EMAIL PROTECTED]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
