Re: Incredibly slow to boot - any ideas?
On Friday 31 March 2006 10:59, N.Pauli wrote:
> On Fri, 31 Mar, Brian Schrock wrote:
> > > debianoak:/home/nbp# hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1192 MB in 2.00 seconds = 595.20 MB/sec
> > > Timing buffered disk reads: 6 MB in 3.24 seconds = 1.85 MB/sec
> > > **
> > >
> > > That looks reasonable to me - very fast from the cache and a lot slower
> > > when it has to be buffered (on the hard drive, presumably). But, what
> > > do I know!?
> >
> > That is not even close to reasonable. I have never seen buffered reads
> > THAT bad.
> >
> > Timing cached reads: 1316 MB in 2.09 seconds = 629.02 MB/sec
> > Timing buffered disk reads: 158 MB in 3.02 seconds = 52.25 MB/sec
> >
> > That is what I get when I run it on an HP d325.
> >
> > Do this too if you want some more information on your drives.
> >
> > hdparm -I /dev/hda
>
> Thanks, Brian for the reality check! I did what you suggested and the info
> below returned instantly. *******
> debianoak:/home/nbp# hdparm -I /dev/hda
>
> /dev/hda:
>
> ATA device, with non-removable media
> Model Number: Maxtor 2F040L0
> Serial Number: F1AS6MYE
> Firmware Revision: VAM51JJ0
> Standards:
> Supported: 7 6 5 4
> Likely used: 7
> Configuration:
> Logical max current
> cylinders 16383 16383
> heads 16 16
> sectors/track 63 63
> --
> CHS current addressable sectors: 16514064
> LBA user addressable sectors: 80293248
> device size with M = 1024*1024: 39205 MBytes
> device size with M = 1000*1000: 41110 MBytes (41 GB)
> Capabilities:
> LBA, IORDY(can be disabled)
> Queue depth: 1
> Standby timer values: spec'd by Standard, no device specific
> minimum R/W multiple sector transfer: Max = 16 Current = 0
> Advanced power management level: unknown setting (0x0000)
> Recommended acoustic management value: 192, current value: 0
> DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
> Cycle time: min=120ns recommended=120ns
> PIO: pio0 pio1 pio2 pio3 pio4
> Cycle time: no flow control=120ns IORDY flow control=120ns
> Commands/features:
> Enabled Supported:
> * NOP cmd
> * READ BUFFER cmd
> * WRITE BUFFER cmd
> * Host Protected Area feature set
> * Look-ahead
> * Write cache
> * Power Management feature set
> Security Mode feature set
> * SMART feature set
> * FLUSH CACHE EXT command
> * Mandatory FLUSH CACHE command
> * Device Configuration Overlay feature set
> Automatic Acoustic Management feature set
> SET MAX security extension
> Advanced Power Management feature set
> * DOWNLOAD MICROCODE cmd
> * SMART self-test
> * SMART error logging
> Security:
> Master password revision code = 65534
> supported
> not enabled
> not locked
> not frozen
> not expired: security count
> not supported: enhanced erase
> HW reset results:
> CBLID- above Vih
> Device num = 0 determined by the jumper
> Checksum: correct
> *******
>
> I repeated
> # hdparm -tT /dev/hda
> and the info came back (substantially as before) with 2 to 3 second delays
> after the command, after the name of the drive was returned and after the
> result for each timing. I think that very low value for timing buffered
> disk reads is a symptom of my problem with gconf.
>
> I'm having to knock off now for a few hours, but
> http://www.gnome.org/projects/gconf has given me some useful
> troubleshooting tips.
>
> Having said that, is there anything in what 'hdparm -I /dev/hda/' has
> returned that should cause concern?
>
> Yours,
> Nigel
> --
> Nigel Pauli
> Network Manager
> St. John's School, Northwood
Nothing in your output looks bizarre to me, but I am not a hard core HDD geek
either, I would acquire that information or talk to someone who knows more.
Also, If I were you I would install the S.M.A.R.T. monitoring tools, and run
a few tests, and also look at the logs on the HDD.
apt-get install smartmontools
And then read this to get going quickly...
http://www.linuxjournal.com/article/6983
You may also want to get some HDD testing software from the manufacturer, and
then again the problem may not be the drive and I am completely wasting your
time. Hope I have at least helped a little.
--
Brian J. Schrock
Reply to: