Doing a mke2fs is a very heavy asynchronous write activity. And, the writes
are scattered throughout the device which makes it even slower. Essentially
all (or a whole bunch) of system buffers are queued up to write the system
data. This can be many many megabytes, and each request will go through the
retry cycle. For each scsi retry, it will most likely go through a reset
cycle. All devices on the scsi bus wait for the two second reset wait period
before they have a chance to do anything again, but then the next request to
the bad device fails and another reset is issued. Not much will happen durring
while this is going on.
<>< Lance.
"Thomas A. Szybist" wrote:
> Hello,
>
> I've been following the discussions concerning scsi retries. I was
> hoping someone could shed some light on this issue. I'm using Red Hat
> 6.1 with adaptec 2940UW controllers.
>
> If I pull a cable during the middle of mke2fs for instance, It seemed like
> retries would go on and on. Looking closer, it seems that each buffer
> in the request is individually marked not uptodate, the command is then
> requeued minus that buffer. This happens until there are no more buffers.
> It also looks like I can have a lot of requests to do this for. So it
> seems to take a long time, on the order of hours.
>
> While this is going on, I can't seem to write to other disks.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
