Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-general] Welland Greenstar HDD spindown problem

Expand Messages
  • Carl Lowenstein
    ... I find state 2 really hard to believe. Disk drives aren t built that way. The heads fly dynamically on a thin layer of air, and the drive platters must
    Message 1 of 8 , Jul 17, 2008
    • 0 Attachment
      On Sun, Jul 13, 2008 at 2:01 PM, tjrundy <tjrundy@...> wrote:
      > Hello,
      >
      > Apologies for a 2nd email, but I thought that by splitting out topics
      > into threads, it might be easier for people to refer to these in the
      > future.
      >
      > I'm running Unslung 6.10 beta. I have two hard drives, one natively
      > formatted on port 2, and a 1TB FAT 32 formatted drive on port 1
      > (Samsung HD103UJ). The Enclosure for port 1 is a Welland Greenstar:
      > http://www.welland.com.tw/html/green/740pss.html.
      >
      > I got it since it was recommended on the wiki:
      > http://www.nslu2-linux.org/wiki/FAQ/SpinDownUSBHarddisks#method2
      >
      > The Enclosure has 4 power states:
      >
      > 1. On - Read / Write normal RPM
      > 2. Idle - reduced RPM
      > 3. Spindown
      > 4. 'Power Off'

      I find state 2 really hard to believe. Disk drives aren't built that
      way. The heads fly dynamically on a thin layer of air, and the drive
      platters must be running at full speed for this to happen. Otherwise
      you get a head crash, which is not good for the head, the platter, or
      the data.

      carl
      --
      carl lowenstein
      marine physical lab, u.c. san diego
      clowenstein@...
    • Rod Whitby
      ... See the conclusion paragraph at http://www.tomshardware.com/reviews/wd-caviar-gp,1703-8.html The main feature in WD s GreenPower portfolio is the dynamic
      Message 2 of 8 , Jul 18, 2008
      • 0 Attachment
        Carl Lowenstein wrote:
        > On Sun, Jul 13, 2008 at 2:01 PM, tjrundy <tjrundy@...> wrote:
        >> The Enclosure has 4 power states:
        >>
        >> 1. On - Read / Write normal RPM
        >> 2. Idle - reduced RPM
        >> 3. Spindown
        >> 4. 'Power Off'
        >
        > I find state 2 really hard to believe. Disk drives aren't built that
        > way. The heads fly dynamically on a thin layer of air, and the drive
        > platters must be running at full speed for this to happen. Otherwise
        > you get a head crash, which is not good for the head, the platter, or
        > the data.

        See the conclusion paragraph at
        http://www.tomshardware.com/reviews/wd-caviar-gp,1703-8.html

        "The main feature in WD's GreenPower portfolio is the dynamic adjustment
        of the drive's spindle speed. It can run at speeds between 5,400 RPM and
        7,200 RPM to save energy whenever high performance isn't needed."

        Dunno about what the enclosure in question can do, but the latest
        GreenPower WD drives apparently can reduce the RPM of the spindles to
        save power.

        -- Rod
      • tjrundy
        ... adjustment ... and ... to ... Right, so on the face of it, it seems a pretty nifty piece of kit. Now I m back from my summer hols, I m back on the case of
        Message 3 of 8 , Oct 1, 2008
        • 0 Attachment
          > See the conclusion paragraph at
          > http://www.tomshardware.com/reviews/wd-caviar-gp,1703-8.html
          >
          > "The main feature in WD's GreenPower portfolio is the dynamic
          adjustment
          > of the drive's spindle speed. It can run at speeds between 5,400 RPM
          and
          > 7,200 RPM to save energy whenever high performance isn't needed."
          >
          > Dunno about what the enclosure in question can do, but the latest
          > GreenPower WD drives apparently can reduce the RPM of the spindles
          to
          > save power.
          >
          > -- Rod

          Right,

          so on the face of it, it seems a pretty nifty piece of kit. Now I'm
          back from my summer hols, I'm back on the case of trying to get this
          HDD working with Openslug.

          Remember my original problem was:

          When connected to the NSLU2, at boot it mounts it as /dev/sdb and
          HDD_1_1_1. When the drive is subsequently accessed and it's in this
          'Power Off' state, it then mounts it as /dev/sdc and HDD_1_2_1. If the
          drive powers off again, next time it will appear as /dev/sdd and
          HDD_1_3_1, and so on.

          Unfortunately there's no way to set the enclosure to spindown but
          never 'power-off'.

          Please does anyone know how I can force subsequent mounts to use the
          same device and HDD_1_1_1?

          Does anyone have any idea about this? Please, Pretty please? ;)
        • Mike (mwester)
          tjrundy wrote: ... OpenSlug (aka SlugOS) or Unslung? Your comments below seem to imply Unslung. ... If this is, in fact, Unslung, it s pretty unlikely that
          Message 4 of 8 , Oct 1, 2008
          • 0 Attachment
            tjrundy wrote:
            ...
            > so on the face of it, it seems a pretty nifty piece of kit. Now I'm
            > back from my summer hols, I'm back on the case of trying to get this
            > HDD working with Openslug.

            OpenSlug (aka SlugOS) or Unslung? Your comments below seem to imply
            Unslung.

            > Remember my original problem was:
            >
            > When connected to the NSLU2, at boot it mounts it as /dev/sdb and
            > HDD_1_1_1. When the drive is subsequently accessed and it's in this
            > 'Power Off' state, it then mounts it as /dev/sdc and HDD_1_2_1. If the
            > drive powers off again, next time it will appear as /dev/sdd and
            > HDD_1_3_1, and so on.
            >
            > Unfortunately there's no way to set the enclosure to spindown but
            > never 'power-off'.
            >
            > Please does anyone know how I can force subsequent mounts to use the
            > same device and HDD_1_1_1?
            >
            > Does anyone have any idea about this? Please, Pretty please? ;)

            If this is, in fact, Unslung, it's pretty unlikely that you'll get this
            to work the way you want it. The fundamental problem is that the
            mechanism that handles this is proprietary Linksys code.

            For SlugOS (and other distros like Debian) it should just work -- udev
            should take care of the situation, and if you are mounting by UUID or
            label, it doesn't matter if it gets a new /dev node.

            Mike (mwester)
          • tjrundy
            ... this ... udev ... or ... Thanks for your help mike. I re-checked my notes, I changed to SlugOS 4.8 beta after I posted that message, but the problem
            Message 5 of 8 , Oct 1, 2008
            • 0 Attachment
              > If this is, in fact, Unslung, it's pretty unlikely that you'll get
              this
              > to work the way you want it. The fundamental problem is that the
              > mechanism that handles this is proprietary Linksys code.
              >
              > For SlugOS (and other distros like Debian) it should just work --
              udev
              > should take care of the situation, and if you are mounting by UUID
              or
              > label, it doesn't matter if it gets a new /dev node.
              >
              > Mike (mwester)
              >

              Thanks for your help mike. I re-checked my notes, I changed to SlugOS
              4.8 beta after I posted that message, but the problem persists. Just
              to incite a little more help, here's a copy of the log files when I
              plug in the device:

              Oct 1 21:40:13 (none) syslog.info -- MARK --
              Oct 1 21:45:01 (none) user.info kernel: usb 1-2: new high speed USB
              device usin g ehci_hcd and
              address 3
              Oct 1 21:45:01 (none) user.err kernel: usb 1-2: device descriptor
              read/64, erro r -71
              Oct 1 21:45:01 (none) user.info kernel: usb 1-2: configuration #1
              chosen from 1 choice
              Oct 1 21:45:01 (none) user.info kernel: scsi1 : SCSI emulation for
              USB Mass Sto rage devices
              Oct 1 21:45:01 (none) user.debug kernel: usb-storage: device found at
              3
              Oct 1 21:45:01 (none) user.debug kernel: usb-storage: waiting for
              device to set tle before
              scanning
              Oct 1 21:45:06 (none) user.notice kernel: scsi 1:0:0:0: Direct-Access
              SAMSU NG HD103UJ
              PQ: 0 ANSI: 2 CCS
              Oct 1 21:45:06 (none) user.notice kernel: SCSI device sdb: 1953525168
              512-byte hdwr sectors
              (1000205 MB)
              Oct 1 21:45:06 (none) user.notice kernel: sdb: Write Protect is off
              Oct 1 21:45:06 (none) user.debug kernel: sdb: Mode Sense: 00 38 00 00
              Oct 1 21:45:06 (none) user.err kernel: sdb: assuming drive cache:
              write through
              Oct 1 21:45:06 (none) user.notice kernel: SCSI device sdb: 1953525168
              512-byte hdwr sectors
              (1000205 MB)
              Oct 1 21:45:06 (none) user.notice kernel: sdb: Write Protect is off
              Oct 1 21:45:06 (none) user.debug kernel: sdb: Mode Sense: 00 38 00 00
              Oct 1 21:45:06 (none) user.err kernel: sdb: assuming drive cache:
              write through
              Oct 1 21:45:08 (none) user.info kernel: usb 1-2: USB disconnect,
              address 3
              Oct 1 21:45:08 (none) user.info kernel: sd 1:0:0:0: SCSI error:
              return code = 0 x00010000
              Oct 1 21:45:08 (none) user.warn kernel: end_request: I/O error, dev
              sdb, sector 0
              Oct 1 21:45:08 (none) user.err kernel: Buffer I/O error on device
              sdb, logical block 0
              Oct 1 21:45:08 (none) user.info kernel: sd 1:0:0:0: SCSI error:
              return code = 0 x00010000
              Oct 1 21:45:08 (none) user.warn kernel: end_request: I/O error, dev
              sdb, sector 0
              Oct 1 21:45:08 (none) user.err kernel: Buffer I/O error on device
              sdb, logical block 0
              Oct 1 21:45:08 (none) user.warn kernel: unable to read partition
              table
              Oct 1 21:45:08 (none) user.notice kernel: sd 1:0:0:0: Attached scsi
              disk sdb
              Oct 1 21:45:08 (none) user.debug kernel: usb-storage: device scan
              complete
              Oct 1 21:45:08 (none) user.notice root: udev/mount.sh [/dev/sdb] is
              blacklisted , ignoring
              Oct 1 21:45:09 (none) user.notice root: udev/mount.sh [/dev/sdb] is
              blacklisted , ignoring
              Oct 1 21:45:18 (none) user.info kernel: usb 1-2: new high speed USB
              device usin g ehci_hcd and
              address 4
              Oct 1 21:45:19 (none) user.err kernel: usb 1-2: device descriptor
              read/64, erro r -71
              Oct 1 21:45:19 (none) user.info kernel: usb 1-2: configuration #1
              chosen from 1 choice
              Oct 1 21:45:19 (none) user.info kernel: scsi2 : SCSI emulation for
              USB Mass Sto rage devices
              Oct 1 21:45:19 (none) user.debug kernel: usb-storage: device found at
              4
              Oct 1 21:45:19 (none) user.debug kernel: usb-storage: waiting for
              device to set tle before
              scanning
              Oct 1 21:45:24 (none) user.notice kernel: scsi 2:0:0:0: Direct-Access
              SAMSUNG HD103UJ PQ: 0 ANSI: 2 CCS
              Oct 1 21:45:24 (none) user.notice kernel: SCSI device sdb: 1953525168
              512-byte hdwr sectors (1000205 MB)
              Oct 1 21:45:24 (none) user.notice kernel: sdb: Write Protect is off
              Oct 1 21:45:24 (none) user.debug kernel: sdb: Mode Sense: 00 38 00 00
              Oct 1 21:45:24 (none) user.err kernel: sdb: assuming drive cache:
              write through
              Oct 1 21:45:24 (none) user.notice kernel: SCSI device sdb: 1953525168
              512-byte hdwr sectors (1000205 MB)
              Oct 1 21:45:24 (none) user.notice kernel: sdb: Write Protect is off
              Oct 1 21:45:24 (none) user.debug kernel: sdb: Mode Sense: 00 38 00 00
              Oct 1 21:45:24 (none) user.err kernel: sdb: assuming drive cache:
              write through
              Oct 1 21:45:25 (none) user.info kernel: sdb1
              Oct 1 21:45:25 (none) user.notice kernel: sd 2:0:0:0: Attached scsi
              disk sdb
              Oct 1 21:45:25 (none) user.debug kernel: usb-storage: device scan
              complete
              Oct 1 21:45:25 (none) user.notice root: udev/mount.sh [/dev/sdb] is
              blacklisted, ignoring
              Oct 1 21:45:25 (none) user.err kernel: FAT: utf8 is not a recommended
              IO charset for FAT filesystems, filesystem will be case sensitive!
              Oct 1 21:45:26 (none) user.notice root: mount.sh/automount Auto-mount
              of [/media/sdb1] successful

              if I run fdisk:

              root@storage:~$ fdisk -l

              Disk /dev/sda: 80.0 GB, 80026361856 bytes
              255 heads, 63 sectors/track, 9729 cylinders
              Units = cylinders of 16065 * 512 = 8225280 bytes

              Device Boot Start End Blocks Id System
              /dev/sda1 1 366 2939863+ 83 Linux
              /dev/sda2 367 9670 74734380 83 Linux
              /dev/sda3 9671 9729 473917+ 83 Linux

              Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
              255 heads, 63 sectors/track, 121601 cylinders
              Units = cylinders of 16065 * 512 = 8225280 bytes

              Device Boot Start End Blocks Id System
              /dev/sdb1 1 121601 976760001 c Win95 FAT32
              (LBA)

              Now I wait for 10 minutes for the disk drive to go into its low power
              state...

              now I try and access it:

              root@storage:/etc$ mount
              rootfs on / type rootfs (rw)
              /dev/root on /initrd type jffs2 (ro)
              /dev/sda1 on / type ext3 (rw,data=ordered)
              proc on /proc type proc (rw)
              sysfs on /sys type sysfs (rw)
              /dev/sda1 on /dev/.static/dev type ext3 (rw,data=ordered)
              tmpfs on /dev type tmpfs (rw)
              /dev/sda2 on /home type ext3 (rw,data=ordered)
              tmpfs on /var/volatile type tmpfs (rw)
              tmpfs on /dev/shm type tmpfs (rw)
              usbfs on /proc/bus/usb type usbfs (rw)
              devpts on /dev/pts type devpts (rw)
              /dev/sdb1 on /media/sdb1 type vfat
              (rw,sync,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8)
              root@storage:/etc$ cd /media
              root@storage:/media$ ls
              card hdd net realroot sda2 sdc1 union
              cf mmc1 ram sda1 sdb1 sdd1
              root@storage:/media$ cd sdb1
              root@storage:/media/sdb1$ ls
              ls: ./Music: Input/output error
              ls: ./Software: Input/output error
              ls: ./Films: Input/output error
              System Volume Information
              root@storage:/media/sdb1$

              and the messages log contains lots of rejection I/O to dead device:

              Oct 1 22:18:49 (none) user.err kernel: scsi 3:0:0:0: rejecting I/O to
              dead device
              Oct 1 22:18:49 (none) user.err kernel: FAT: Directory bread(block
              477041) failed
              Oct 1 22:18:50 (none) user.err kernel: scsi 3:0:0:0: rejecting I/O to
              dead device
              Oct 1 22:18:50 (none) user.err kernel: FAT: FAT read failed (blocknr
              4906)
              Oct 1 22:18:50 (none) user.err kernel: scsi 3:0:0:0: rejecting I/O to
              dead device
              Oct 1 22:18:50 (none) user.err kernel: FAT: FAT read failed (blocknr
              4906)
              Oct 1 22:18:50 (none) user.err kernel: scsi 3:0:0:0: rejecting I/O to
              dead device
              Oct 1 22:18:50 (none) user.err kernel: FAT: FAT read failed (blocknr
              4906)
              Oct 1 22:18:50 (none) user.notice root: mount.sh/automount Not
              removing non-empty directory [/media/sdb1]
              Oct 1 22:18:50 (none) user.notice root: udev/mount.sh [/dev/sdb] is
              blacklisted, ignoring
              Oct 1 22:18:57 (none) user.info kernel: usb 1-2: new high speed USB
              device using ehci_hcd and address 6
              Oct 1 22:18:57 (none) user.info kernel: usb 1-2: configuration #1
              chosen from 1 choice
              Oct 1 22:18:57 (none) user.info kernel: scsi4 : SCSI emulation for
              USB Mass Storage devices
              Oct 1 22:18:57 (none) user.debug kernel: usb-storage: device found at
              6
              Oct 1 22:18:57 (none) user.debug kernel: usb-storage: waiting for
              device to settle before scanning
              Oct 1 22:19:02 (none) user.notice kernel: scsi 4:0:0:0: Direct-Access
              SAMSUNG HD103UJ PQ: 0 ANSI: 2 CCS
              Oct 1 22:19:02 (none) user.notice kernel: SCSI device sdc: 1953525168
              512-byte hdwr sectors (1000205 MB)
              Oct 1 22:19:02 (none) user.notice kernel: sdc: Write Protect is off
              Oct 1 22:19:02 (none) user.debug kernel: sdc: Mode Sense: 00 38 00 00
              Oct 1 22:19:02 (none) user.err kernel: sdc: assuming drive cache:
              write through
              Oct 1 22:19:02 (none) user.notice kernel: SCSI device sdc: 1953525168
              512-byte hdwr sectors (1000205 MB)
              Oct 1 22:19:02 (none) user.notice kernel: sdc: Write Protect is off
              Oct 1 22:19:02 (none) user.debug kernel: sdc: Mode Sense: 00 38 00 00
              Oct 1 22:19:02 (none) user.err kernel: sdc: assuming drive cache:
              write through
              Oct 1 22:19:03 (none) user.info kernel: sdc1
              Oct 1 22:19:03 (none) user.notice kernel: sd 4:0:0:0: Attached scsi
              disk sdc
              Oct 1 22:19:03 (none) user.debug kernel: usb-storage: device scan
              complete
              Oct 1 22:19:03 (none) user.notice root: udev/mount.sh [/dev/sdc] is
              blacklisted, ignoring
              Oct 1 22:19:04 (none) user.err kernel: FAT: utf8 is not a recommended
              IO charset for FAT filesystems, filesystem will be case sensitive!
              Oct 1 22:19:04 (none) user.notice root: mount.sh/automount Auto-mount
              of [/media/sdc1] successful

              and re-mounts it on sdc1!

              So it must take about 15 seconds to spin up out of its low power
              state. So this causes havoc with Samba, naturally because the shares
              don't reference the right device now!

              Sorry to be a continued pain, but anyone have any thoughts on how to
              fix this?

              Cheers,

              Tom.

              ps. the Mrs isn't too keen on having hdd's spinning all the time, esp
              when I'm away!
            • tjrundy
              ... Further to Mike s suggestion, I spent a couple of hours last night trying to get the UUID of the disk (which was only 8 chars long as it s VFAT formatted),
              Message 6 of 8 , Oct 2, 2008
              • 0 Attachment
                --- In nslu2-general@yahoogroups.com, "tjrundy" <tjrundy@...> wrote:
                >
                >
                > > If this is, in fact, Unslung, it's pretty unlikely that you'll get
                > this
                > > to work the way you want it. The fundamental problem is that the
                > > mechanism that handles this is proprietary Linksys code.
                > >
                > > For SlugOS (and other distros like Debian) it should just work --
                > udev
                > > should take care of the situation, and if you are mounting by UUID
                > or
                > > label, it doesn't matter if it gets a new /dev node.
                > >
                > > Mike (mwester)
                > >

                Further to Mike's suggestion, I spent a couple of hours last night
                trying to get the UUID of the disk (which was only 8 chars long as
                it's VFAT formatted), and then trying to mount it by the UUID, or the
                label. Neither worked, and I noticed that much of the web-material
                about this was referenced to the Debian dist...

                I'm thinking that perhaps Debian might be a better bet?

                However before I start all over again, can anyone confirm whether UUID
                support only works for ext2/3 and if it's supported under VFAT how I
                would get a 'proper' UUID string?

                Thanks again guys,

                Tom.
              • Mike (mwester)
                tjrundy wrote: ... Check out blkid -- it puts the current list of UUIDs in /etc/blkid.tab (or similar) Mike (mwester)
                Message 7 of 8 , Oct 6, 2008
                • 0 Attachment
                  tjrundy wrote:
                  ...
                  > However before I start all over again, can anyone confirm whether UUID
                  > support only works for ext2/3 and if it's supported under VFAT how I
                  > would get a 'proper' UUID string?

                  Check out "blkid" -- it puts the current list of UUIDs in /etc/blkid.tab
                  (or similar)

                  Mike (mwester)
                Your message has been successfully submitted and would be delivered to recipients shortly.