> That might work if the FS ran on a separate thread.
> But under Linux, the "fs thread" *is* the application process.
mmh..
> The reason other tasks may also be held up during the spin-up
> is that the disk-queue is blocked on the r/w request that
> caused the spin-up, and other requests for the same MAJOR
> (IDE interface) cannot proceed until it is serviced.
So even the other one (master/slave) is blocked? Sorry, but
this is really *bad*. One of my disks (a ~730MB Quantum)
needs almost 8 seconds to spin up. It is configured as slave,
and if the master (a faster Seagate) would have to wait this
time, it would be a serious drawback,
> Other IDE interfaces are free to continue working in parallel.
4 HDs on 2 controllers -- so one is always innocently blocked.
Please don't say I should switch to SCSI. I would, but 1st I
already have these IDE controllers and want them to work.
2nd SCSI costs $$.
My fault, I really thought the fs I/O thru the cache was asynchronous.
ciao,
johnny
-- Trust no-one.- 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/