Unrelated, but: I notice that on my 2.0.* machines, "rm" of directory
trees of a GB or so ties up the whole machine for 30s to 1M if the disk
is IDE. On machines (roughly P200's) with SCSI disks, the rm is much
much faster. Say 3s at most.
I suppose metadata is sync (I haven't checked, but given that
_something_ is async by default, it must be data that is async and
metadata that is sync). SCSI seems to handle syncronous data changes
asynchronously :-). I suppose that's due to tagged predictive
anti-caching reordering in the controller ;-)
> only is disk bandwidth stolen almost completely for that operation, but
> the cpu also seems to be at a loss. The systems I'm using all have 512Mb
> of RAM, they're dual cpu, some are ppro 200s, some are p-ii 266s, some are
> p-ii 400s. They all have buslogic scsi, with ultrawide disks.
Interesting. Clearly you need to look up a lot of (double) indirections
on the disk for release of the blocks if the files are oversize. But
doing anything big with metadata should cost equally if it's synchronous
and the controller isn't doing black magic (like mine ;-). So it must
be that you haven't pushed the black-magic switch on the controller. I
believe it's called "tagged queueing" in real life, not that I know
what "tagged" adds to the description here. Just being able to queue
reschedulable requests would be enough, provided that you can maintain a
defined partial order between them. Perhaps what the "tag" means ..
Peter ptb@it.uc3m.es
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu