This explains it.
>
> That would be 344EC4 so its plausible. Could you have issued requests before
> changing the block size ? It sounds form your comemnt that after that error
> everything continued fine ? If so you only issued one stray request somehow -
> as it would have logged each I/O that went off the end in its view.
You might be correct here. When we do re-mirroring, we do it
BACKWARDS. That is to say, we start at the end of the partition and
swipe upward in 64K chunks. We do it this way to avoid blowing the
elevator in the LRU. Novell discoverd long ago that re-mirroring could
severely starve normal I/O if you used a single list elevator queue
(they quickly went to an A an B queue to correct this) because
re-mirroring would continously re-order the elevator list and push older
requests with larger LBA values the bottom (yipes!!!). We are seeing
this because we are starting at the end of the disk. It's benign,
except we are trying to hotfix the missing sectors (and since they
aren't really there, we end up deactivating the disk since we think its
undergoing a soft as opposed to hard failure). I checked and we are
setting the blocksize to 512 before attempting IO, but for some reason,
where we are doing it is not working with the driver. I will
investigate further and get back to you.
Jeff
>
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/