| Summary: | libatasmart should not wake up disks that are sleeping | ||
|---|---|---|---|
| Product: | libatasmart | Reporter: | Snorre Jensen <snorre> |
| Component: | library | Assignee: | Lennart Poettering <lennart> |
| Status: | RESOLVED FIXED | QA Contact: | Lennart Poettering <lennart> |
| Severity: | normal | ||
| Priority: | medium | CC: | jim, marti, mmoneta, rrauenza, zeuthen |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
devkit-disks-helper-ata-smart-collect output with patched libatasmart
skdump output with patched libatasmart |
||
|
Description
Snorre Jensen
2009-10-16 14:51:29 UTC
We don't. We specifically use libatasmart API to check if the disk is asleep before attempting retrieving SMART data from it. This works fine for most disks but some disks are broken insofar that checking if they are asleep wakes up the disk. Yes, priceless isn't it? So this is either a hardware bug (most likely) or a libatatasmart bug (less likely). I'm saying the more is more likely because of the 8 external disks that I own, only one exhibits the behavior your bug is about. Anyway, not a DeviceKit-disks bug. Actually this seems to be a libatasmart bug, see these downstream bug reports https://bugzilla.redhat.com/show_bug.cgi?id=491552 https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/435190 Unfortunately there's no bug tracker for libatasmart yet but I think Lenny wanted one on fd.o. I'll try to get that going, then I'll reassign this bug. Thanks. Reassigning to libatasmart. I understand that some drives are behaving differently, but I run hddtemp every 2 hours and have smartd polling every 2 hours, and neither utility wakes up my drives. They both know when they are asleep and they skip their check and log a message saying as much. Hi Lenny, I have one of these disks, too ;-) Not sure who this "Lenny" guy is, I only know a distribution by that name... But anyway, some guy called Lennart now prepped this patch: http://git.0pointer.de/?p=libatasmart.git;a=commit;h=a223a4f6277a9f006b722b13671d5292dc6339bb And I could use someone to test this before I roll a new release tarball for this. Anyone up for this? I can test it --- what's the easiest way for me to get a build? Or build my own? Fedora 11, 32bit Rich (In reply to comment #7) > I can test it --- what's the easiest way for me to get a build? Or build my > own? If building your own would be OK're prefer that. It should be enough to build libatasmart from the git tree and run the dkdisks daemon with LD_LIBRARY_PATH=foobar/libatasmart/.libs/ > Fedora 11, 32bit Uh, this should be tested with F12. We broke ABI and API of libatasmart between F11 and F12. Hmph -- then that takes me out of the test pool! Rich Good work Lennart! now its working :) /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 1 Disk /dev/sda is asleep and nowakeup option was passed /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda 1 Disk /dev/hda is asleep and nowakeup option was passed /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb 1 Disk /dev/hdb is asleep and nowakeup option was passed (In reply to comment #10) > Good work Lennart! now its working :) > > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda > 1 > Disk /dev/sda is asleep and nowakeup option was passed > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda > 1 > Disk /dev/hda is asleep and nowakeup option was passed > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb > 1 > Disk /dev/hdb is asleep and nowakeup option was passed > Now we know that the wakeup situatin got fixed. But does reading the SMART data work as well, i.e. are there any regressions? Could you verify that please? I run: # /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 0 then the disk spins up and I get this error: Failed to read smart data for /dev/sda: No such file or directory On Fri, 23 Oct 2009 15:47:34 -0700 (PDT) bugzilla-daemon@freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=24579 > > > > > > --- Comment #11 from Lennart Poettering <lennart@poettering.net> > 2009-10-23 15:47:33 PST --- (In reply to comment #10) > > Good work Lennart! now its working :) > > > > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda > > 1 > > Disk /dev/sda is asleep and nowakeup option was passed > > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda > > 1 > > Disk /dev/hda is asleep and nowakeup option was passed > > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb > > 1 > > Disk /dev/hdb is asleep and nowakeup option was passed > > > > Now we know that the wakeup situatin got fixed. But does reading the > SMART data work as well, i.e. are there any regressions? Could you > verify that please? > > I run: # /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 0 then the disk spins up and I get this error: Failed to read smart data for /dev/sda: No such file or directory Created attachment 30689 [details] devkit-disks-helper-ata-smart-collect output with patched libatasmart Lennart, The patch fixed the spin-up problem on my Ubuntu 9.10 Alpha 6 box. Here's the output from devkit-disks-helper-ata-smart-collect when the drive is spun down, first with nowakeup=1, then nowakeup=0. I installed the patched libatasmart from Martin Pitt's Ubuntu PPA: https://launchpad.net/~ubuntu-desktop/+archive/ppa Created attachment 30690 [details]
skdump output with patched libatasmart
Here's skdump output for my disk with the patched libatasmart. I haven't compared it to the output before installing the patch, but all values seem valid.
Everything looks good then. I'll consider this bug fixed. There was another positive testing response on the downstream lp bug. Thanks for fixing! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.