Re: Poor performance from file system

From: Mike Mol (mikemol_at_gmail.com)
Date: 12/20/04

  • Next message: Dr Balwinder Singh Dheeman: "Re: The guts of /dev/* ?" 
    Date: 20 Dec 2004 05:26:35 -0800

    Jean-David Beyer wrote:
    > I already do that. Everyday, logwatch tells me stuff like:
    >
    > /dev/hda :
    > 1 Time(s): SMART Prefailure Attribute: 8 Seek_Time_Performance
    changed
    > from 246 to 248
    > 1 Time(s): SMART Prefailure Attribute: 8 Seek_Time_Performance
    changed
    > from 246 to 250
    > 1 Time(s): SMART Prefailure Attribute: 8 Seek_Time_Performance
    changed
    > from 247 to 246
    >
    > [snip]
    >
    > What do I care if seek time changes. What is the number anyway?

    "Seek time" is the measurement of how long it takes the hard drive to
    find a specific address on the disk. The arm holding the read/write
    head of the disk has to get into position to read the data, then the
    platter has to rotate until the address desired is directly underneath
    the head. This takes time.

    (I believe most hard drives now have multiple platters and multiple
    heads, but the principle is still the same.)

    If the number shows a trend towards failure, it's a good idea to back
    up your data, as a variety of components could be contributing to the
    decrease in performance, and the failure of any one of them could mean
    significant loss of data.

    However, a small jitter in this number doesn't necessarily indicate a
    problem, since seek times can be affected by the kinds of data access
    your computer performs, which in turn is affected by the kinds of
    applications you run. Jobs that require little movement of the
    read/write head tend to result in short seek times, while jobs that
    frequently require large movements tend to result in larger seek times.

    For example, if you use dd to create a large, contiguous file, your
    seek times will seem to improve. In contrast, if you run an
    application that scatters its read/write requests, such as defrag, your
    seek times will likely seem to deteriorate.

    If you don't want notification of changes in pre-failure attributes for
    that device, remove "-p" from the line beginning with "/dev/hda"

    >
    > 1 Time(s): SMART Usage Attribute: 201 Unknown_Attribute changed
    from
    > 239 to 248
    > 1 Time(s): SMART Usage Attribute: 201 Unknown_Attribute changed
    from
    > 240 to 239
    > 1 Time(s): SMART Usage Attribute: 201 Unknown_Attribute changed
    from
    > 241 to 240
    >
    > [snip]
    >
    > Knowing thatan unknown attribute changed is worse than useless.

    Upgrading your installation of the smartmontools package *might*
    resolve this. However, a little sleuthing might get the answers you
    need.

    What's the brand name and model number of the disk? Do a search for
    "(model number) SMART attributes" If that turns out not to help, email
    the manufacturer of the disk.

    >
    > /dev/sda :
    > 1 Time(s): Temperature changed -1 degrees to 36 degrees since
    last reading
    > 1 Time(s): Temperature changed -2 degrees to 37 degrees since
    last reading
    > 1 Time(s): Temperature changed 1 degrees to 36 degrees since last
    reading
    > 2 Time(s): Temperature changed 1 degrees to 37 degrees since last
    reading
    > 1 Time(s): Temperature changed 1 degrees to 38 degrees since last
    reading
    > 1 Time(s): Temperature changed 1 degrees to 39 degrees since last
    reading
    >
    > By and large, I do not care that the SCSI temperatures change,
    though, of
    > course if they got too hot, I would like to know that.

    True. From the smartd.conf manpage:

    **
    -I ID
    Ignore device Attribute ID when tracking changes in the Attribute
    values. ID must be a decimal integer in the range from 1 to 255. This
    Directive modifies the behavior of the '-p', '-u', and '-t' tracking
    Directives and has no effect without one of them.

    This is useful, for example, if one of the device Attributes is the
    disk temperature (usually Attribute 194 or 231). It's annoying to get
    reports each time the temperature changes. This Directive may appear
    multiple times for a single device, if you want to ignore multiple
    Attributes.
    **

    So, in smartd.conf, add -I (ID) to the line for any device you want to
    ignore changes in temperature of. However, I'm not sure that it will
    also watch for device failure with respect to temperature if you add
    that line.

  • Next message: Dr Balwinder Singh Dheeman: "Re: The guts of /dev/* ?"

    Relevant Pages

    • Re: What tool to use for processing large documents
      ... cannot parse faster than the disk can read the XML data. ... Reading 10 GB off a disk will take around 3 to 5 minutes ... I forgot to mention that my logs are in zipped xml. ... Get the set of nodes matching an XPath expression. ...
      (comp.text.xml)
    • Re: *Fast* way to process large files line by line
      ... line and parse it. ... reading file loop> marshalling> parsing. ... the disk I am using is an LVM mapped ext3 local disk. ... Btw will using something like an mmap extension for ruby speed things ...
      (comp.lang.ruby)
    • Re: Best Way to build a calibrated S meter
      ... If you derive the S-meter reading from the a.g.c. ... gain of simple IF-strips vary with temperature (and thus need a ... power level and temperature calibration points ... One vector for a specific band might contain the front end ...
      (rec.radio.amateur.homebrew)
    • Re: Scanf and number formats
      ... > before the decimal-point character (which is nonzero if the ... > largely dominated by the disk I/O rate... ... > reading the data from memory, as if it were using getcto fetch ...
      (comp.lang.c)
    • Re: Router bit temperature
      ... The little HF pocket model goes on sale for $9.95 now and then. ... I took the reading with the nose about 3" from the router bit, so might have gotten a more or less decent reading of the average bit temperature. ...
      (rec.woodworking)