disk diagnostics

[Bill Hacker]

Simon 'corecode' Schubert wrote:

Bill Hacker wrote:

Warren Hull 25 minutes delay comes in, and I/O tuning doesn't cover 
that. Too big a number for where it is being reported as happening.

Either something else - probably something *basic* but simply 
overlooked - is placing demands on that storage system, or the 
'problem' has been misreported.


softupdates?  writing meta data with sync will be really slow.

cheers
 simon
No, not *that* slow, not even on K6-2-500 with 256 MB of SDRAM, where I have 
done it on a production FreeBSD 4.8 web & mx box for donkey's years (too small 
to hold a RAID). DFLY may not have focused on that area, but should not be 2 or 
3 orders of magnitude slower than 4.9/4.9 BSD.

Especially not that slow on a scripted dirtree rm -Rf

I'd want to see what is in the ~/messages and other logs, (rampant I/O errors?), 
what, if anything was mounted from the CD's, where mounted, and what the path 
was at the time - likewise RAMDISK and if df showed one or more mounts 
at/near/over 100%+ of capacity, memory and swap stats.... etc.  The 'usual 
suspects'.

The time involved hints at CD's being spun up, paths searched, found not to 
contain <whatever>, rewind.... or some partition being pushed over 100% 
temporarily. Folsks cramming multiple OS test installs onto media all too rarely 
pay attention to temporary needs. The 8+ GB needed for building OpenOffice from 
source caught even this old dog flatfooted, for example.

Otherwise, ATA I/O is too 'universal' in use to hide a DFLY bug of such 
magnitude for very long, so the paucity of related reports says it is a local 
'headspace' issue...

Bill