Wow, not too fast. I don't have access to my machine right now (I'm at work), so I will post detailed stats later (timed rm, top output, ...)
- no servers (web,mail,smb,....) are running - no other users present - no cron jobs or other daemons or other processes apart from the standard system processes and X+KDM running. - disk room enough for what I'm trying to do, only HDD access to that HDD needed. - it's an AMD Sempron 3100+, with Dragonfly on the old disk - the 25 minutes was a subjective quantification. But it's O(10min). - DFly-preview 1.5.4, but got the same problem with older versions - I did not want to say it is a bug in DFly, no far from that, it just should be some hardware problem or a configuration issue or something stupid. If I remember well, the rm process is spending a lot of time in the IOWAIT status, but I'm not sure anymore. So, wait for more info to come later. thanks already, Pieter On 7/26/06, Bill Hacker <[EMAIL PROTECTED]> wrote:
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
