Re: disk diagnostics

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Pieter Dumon wrote:
> 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.

Ummmhhh.. you are doing a make buildworld, ..kernel,...install... cycle in 
multiuser mode via X+KDM?

> - 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

How much memory?  How many swap areas, and how large each?

> - 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.

I'll refrain from calling X+<any WM> 'stupid' for an OS make/install cycle, but 
only out of incredulity. There's one hog that should be shut down in favor of a 
simple (ssh-ed) CLI when doing resource-intensive make/build/install work.

*Especially so* if it has a filemanager view window open and is trying to keep 
it current and sorted.

> 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.

OK. Please copy us a 'df' or three as well, just to make sure.

Thanks,

Bill


> thanks already,
>
> Pieter
>
>
> On 7/26/06, Bill Hacker <wbh@xxxxxxxxxxxxx> 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