Opened 4 years ago

Last modified 2 years ago

#1440 new defect

'smartctl -n standby' wakes up Adaptec HBA adapter drives

Reported by: Andrey P. Owned by:
Priority: major Milestone: undecided
Component: all Version: 7.2
Keywords: aacraid linux Cc:

Description (last modified by Christian Franke)

After update from smartctl 6.2 2017-02-27 r4394 Linux 3.10.0-693 to smartctl 6.6 2017-11-05 r4594 Linux 3.10.0-957 we've got logs full of the following messages:

Apr 11 15:13:18 us6-acs1-stor08 smartd[2742]: Device: /dev/sdbb [SAT], CHECK POWER STATUS spins up disk (0x81 -> 0xff)

Hardware: Adaptec HBA adapter.

The issue affects recent smartctl 7.2 as well. It appears in code block trunk/smartmontools/os_linux.cpp@5208#L3437 when executing linux_smart_device(O_RDWR|O_NONBLOCK) on line trunk/smartmontools/os_linux.cpp@5208#L979 in c-tor of class linux_aacraid_device.

The issue is similar to ticket #37.

Change History (3)

comment:1 by Christian Franke, 4 years ago

Description: modified (diff)

comment:2 by Christian Franke, 4 years ago

Keywords: linux added; hba adaptec power removed
Milestone: Release 7.3undecided

After update from smartctl 6.2 2017-02-27 r4394 Linux 3.10.0-693 ...

The official release was 6.2 2013-07-26 r3841, not r4394.

If possible, please check which smartmontools release introduced the problem.

Apr 11 15:13:18 us6-acs1-stor08 smartd[2742]: Device: /dev/sdbb [SAT], ...

You referred to smartctl, but provided a sample output from smartd. Does this mean that the problem could be reproduced with both?

It appears in code block ... in c-tor of class linux_aacraid_device.

Does the spin up actually appear in or after c-tor execution but before device open()? The c-tors only initialize members and do not access the device.

Please check which command spins up the device:

  smartctl -d aacraid,... -i /dev/sdbb
  smartctl -d sat+aacraid,... -i /dev/sdbb
  smartctl -d scsi+aacraid,... -i /dev/sdbb

The issue is similar to ticket #37.

This was somewhat different. Experiments showed that the spin up was triggered late by close(). Possibly because the kernel then sends some flush command when a raw device was open for writing. It affected default Linux SCSI/SAT/SATA layer, not any RAID controller.

But it is possibly worth the effort to check whether the fix for #37 would also help here. Please try this patch:

  • os_linux.cpp

     
    976976linux_aacraid_device::linux_aacraid_device(smart_interface *intf,
    977977  const char *dev_name, unsigned int host, unsigned int channel, unsigned int device)
    978978   : smart_device(intf,dev_name,"aacraid","aacraid"),
    979      linux_smart_device(O_RDWR|O_NONBLOCK),
     979     linux_smart_device(O_RDONLY|O_NONBLOCK),
    980980     aHost(host), aLun(channel), aId(device)
    981981{
    982982  set_info().info_name = strprintf("%s [aacraid_disk_%02d_%02d_%d]",dev_name,aHost,aLun,aId);

PS: Please do not set the Milestone in future submissions.

comment:3 by (none), 2 years ago

Last edited 2 years ago by Christian Franke (previous) (diff)
Note: See TracTickets for help on using tickets.