Bug 561876 - sdparm --command=stop is ineffective
Summary: sdparm --command=stop is ineffective
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sdparm
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Terje Røsten
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-04 15:44 UTC by Pádraig Brady
Modified: 2010-04-16 19:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-16 19:50:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
open the device read only (508 bytes, patch)
2010-02-04 15:44 UTC, Pádraig Brady
no flags Details | Diff

Description Pádraig Brady 2010-02-04 15:44:17 UTC
Created attachment 388817 [details]
open the device read only

In fedora 8 the above command would spin down my usb disk immediately.
In F11 with sdparm-1.04-1.fc11.i586 I can here the disk respond with to the command but it seems to spin up again immediately.

I think this is probably the same issue as:
https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/388506

The workaround described there wrt changing the udev rule works for me.
Also sdparm does open the device RDWR as verified by:

# strace -e open sdparm --verbose --command=stop /dev/sdc
open("/dev/sdc", O_RDWR|O_NONBLOCK)     = 3

Also sdparm with the attached patch spins down the drive.

Comment 1 Dan Horák 2010-02-04 16:11:47 UTC
The patch makes sense to me, but I talk to the author of sdparm before applying.

Comment 2 Terje Røsten 2010-02-14 20:19:23 UTC
Any news from upstream?

Comment 3 Dan Horák 2010-02-15 09:42:29 UTC
yes, we discussed it and it's not so simple due some difference between SCSI and ATA. As a result new command-line switch for opening the device RO is introduced and I have a release candidates of the sdparm/sg3_utils upcoming versions.

Comment 4 Pádraig Brady 2010-02-15 09:59:34 UTC
Could you expand on that a bit. I really hate unnecessary options, but if it needs to be an option fair enough. Could we try RO then fall back to RW for example?
Also hdparm sets RO by default, so why exactly is sdparm different.

cheers.

Comment 5 Dan Horák 2010-02-15 10:17:26 UTC
The long answer from Doug:

T10 and T13 have been trying to converge the semantics
of START/STOP for some time. Folks from Seagate are
driving the effort at T10. My guess is that this
problem in some form has bitten them.

The executive summary is that START_STOP_UNIT in SCSI
is state changing in the sense that after a stop both
READ and WRITE will fail (until a start command is
sent). However in the ATA world what SAT maps
START_STOP_INIT(stop) to will not break subsequent
READs and WRITEs, it will just slow the first one
down (while it spins up the media).

A related problem came up in smartmontools recently along
these lines: if a ATA disk (via a SCSI device) is
opened RW to collect some metadata then on close
it will do a SYNCHRONIZE CACHE which will spin up an
ATA disk that had earlier been spun down. Same solution:
open the device RO.

Since sdparm and sg_start were designed for SCSI
devices my preference would be to add a '-r'
(and '--readonly') option to open the given device
RO.

Comment 6 Pádraig Brady 2010-02-15 10:35:06 UTC
I see the issue. So with the above proposed --readonly option:

--command=stop still does nothing on ATA unless it's called. That would need to be documented at least in the stop command section of the man page.

What does --command=stop do in the presence of udev and SCSI. Will that also be ineffective?

Would it be possible to detect if an ATA device is connected and open RO in that case, thus not requiring the -r option and associated documentation.

Comment 7 Dan Horák 2010-02-15 10:52:12 UTC
I think you should discuss it with Doug directly (see http://sg.danny.cz/sg/ for contact info) and as always - patches are welcome.

Comment 8 Terje Røsten 2010-04-15 18:12:11 UTC
A new upstream release is available, seems like Doug has implemented the solution in comment #5. Could you please test the updated package:

 http://koji.fedoraproject.org/koji/buildinfo?buildID=167119

and see if that helps?

Comment 9 Pádraig Brady 2010-04-16 10:26:07 UTC
works. thanks.

Comment 10 Terje Røsten 2010-04-16 19:50:31 UTC
Thanks for the feedback, I have pushed the update to F11, F12 and F13.


Note You need to log in before you can comment on or make changes to this bug.