GNOME Bugzilla – Bug 535609
Stop external hard drive after unmounting it
Last modified: 2018-09-21 16:22:05 UTC
When I unmount an external disk from nautilus, the disk is generally not stopped (and often, the action of unmounting the disk will cause it to start spinning while before, it was sleeping). When I disconnect my drive, I would like it to be stopped (that is not spinning). If it is, I fear that it may damage the drive. (I suspect that one of my drives got corrupted because I didn't stopped it correctly). Perhaps, it could be possible to put the hard drive to sleep after umounting its last partition (it seems either hdparm -y or sdparm -C stop is the way to go) Perhaps add another entry to the contextual menu when all partitions have been unmounted that would stop completely the drive (including for example the USB power, that is available for all drives while hdparm/sdparm might not work everywhere)
I agree with you that this is a cool thing to have, but I don't know if this is really a Nautilus duty, I'd see HAL/DeviceKit as a better place for this feature. CC-ing David to hear his thoughts about this.
*** Bug 553112 has been marked as a duplicate of this bug. ***
Reassigning to GVFS / volume monitor.
How do you actually "stop" it in software? There's no proper command to stop it. Does using "eject" (the command-line tool) on the device work? If so, you can fix your problem by submitting a "requires eject" fdi change for your hard-drive to hal-info
I'm not sure using eject is what we want; that will make all the partitions disappear and the user will have to replug the device to get them back. The requires-eject, for non-optical drives, is only useful to make the "not safe to disconnect" message go away. I'm not sure what the right solution to this problem is; for real ATA/SCSI devices, probably messing with sdparm/hdparm. But I don't think that's a good solution either; I'm fairly convinced the kernel needs to do power management under the hood and put the drive to sleep (sending same commands as sdparm/hdparm) when there's no activity for a while. And put it very quickly to sleep if there are no open files (e.g. will kick in just after unmounting). Also, sane defaults and some knobs in sysfs for the people who like to tweak stuff. Would be good to figure out what end user UI story / experience we want, that might influence what knobs we want in sysfs. Also not sure how that will work for dumb USB/Firewire bridges. As a data point, from what I can tell this works pretty nice on OS X even with USB/Firewire bridges. Adding mjg59 to the Cc. Matthew, your thoughts?
(also, gvfs is probably not the right component but let's keep it here for a while after we've examined what options we have)
Pasting from IRC <mjg59> davidz: there's no realistic way the kernel is going to start sending spindown commands on idle <mjg59> There was a therad recently on allowing spindown through firewire bridges, though On lkml <davidz> mjg59: well... do you think it's better that user space does it? or.. shouldn't we spin down drives at all? <mjg59> In this kind of situation, you want an explicit spindown Which is a userspace decision <davidz> and what about laptop_mode? I mean... it's very very hard for user space to figure out when to spin drives down - there's just not enough information <mjg59> And static spindown times are the wrong answer in so many ways it's not funny <davidz> right <mjg59> But in any case, this bug's not about that <davidz> probably not <mjg59> In MacOS, does unmounting a USB drive cause it to spin down? <davidz> I guess it depends most of my USB enclosures does it by themselves some don't... on Linux... but reporters says they do on OS X <mjg59> Then we probably need to send a spindown command <davidz> that's pretty hard to do over USB storage.... <mjg59> Works fine on the USB storage I have <davidz> but sure... HAL or whatever could do that... on the last unmount but it seems, long term, like a better solution to fix the general problem <mjg59> sdparm -C stop /dev/sdc works fine here <davidz> e.g. we also want drives to spin down when not used <mjg59> Unmounting a drive is always going to spin it up <davidz> maybe not for rootfs though I know update the superblock etc. <mjg59> And really, for laptops you /don't/ want to spin the drive down most of the time <-- nim-nim has quit (Read error: 131 (Connection reset by peer)) <davidz> but the general use case is this: uses just attach a 500GB external disk... they use it once a week.... <mjg59> Power draw for a spinning (but idle) disk is on the order of 200mW <davidz> s/uses/user/ <mjg59> And yes, I'm working on that <davidz> ok <mjg59> But we're not doing a static timeout. Ever. <davidz> I actually didn't ask for that ;-) <mjg59> Heh <davidz> well... partly... "when there's no activity for a while" <mjg59> It's trivial to do from userspace. You don't actually need that much information, and it's already exported --> nim-nim (~nim@81-64-155-27.rev.numericable.fr) has joined #fedora-desktop <davidz> I'd like as much of power management to be in the kernel driver as possible... way to fragile getting user space involved I think <mjg59> Disk spin behaviour is very policy dependent Much more so than most other pm choices, because there's such huge amounts of latency involved <davidz> right and noise ;-) <mjg59> We're talking on the order of seconds, not ms <davidz> I mean, disk enclosures... they're big.. they're noisy... also, there's the thing that it causes a lot of wear on the disk if you Do It Wrong(tm) <mjg59> So I'd rather leave this up to userspace, because otherwise you're going to end up with a huge number of kernel policy knobs <davidz> ok so as any kind of conclusion your advice is that we should just call hdparm/sdparm on the last unmount? I mean... *after* the last unmount <mjg59> I think we should limit this to enclosures So it's actually just open the sg device and do an ioctl on it Possibly after some checking to see whether it reports implementing it There's a recent lkml thread on firewire enclosures and spindown, though <davidz> makes sense I guess <mjg59> I think there's a couple of possible commands <-- walters has quit (Read error: 145 (Connection timed out)) <davidz> I'll copy paste this IRC conversation into the bug
Changing component to udisks2 volume monitor, because hal volume monitor is obsolete currently and this issue seems to be valid also for udisks2 volume monitor... gnome-shell is responsible for automounting, maybe it should also unmount/stop them... see similar bug 562581 about unmounting.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/49.