SUMMARY Device notifier removes the device entirely after "removing" the device by using the dedicated button. I have noticed this lately and I don't know the technical cause. In the past, it shown the device as not mounted. STEPS TO REPRODUCE 1. plug a portable disk or a thumb drive 2. mount it (use the plasmoid button or dolphin) 3. eject it, but not unplug it OBSERVED RESULT The device disappears entirely from the list. EXPECTED RESULT The device remains available to be mounted again. SOFTWARE/OS VERSIONS Windows: - MacOS: - Linux/KDE Plasma: Linux Sabayon 19 (available in About System) KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.53.0 Qt Version: 5.11.3 Kernel version: 4.18 ADDITIONAL INFORMATION I use two HDD enclosures, connected to a PC through USB. These enclosures contain 5 HDDs each, as standalone disks. As effect, the device notifier applet shows 5 disks available per enclosure. If I unmount the last one, without unplugging it, all disappear from the plasmoid, so I have to power down the HDD enclosure or unplug it and plug it again. It is highly inconvenient and ...harms... the hardware in time. It is similar to Windows behaviour, but not always commercial software is better.
> If I unmount the last one, without unplugging it, all disappear from the plasmoid This is intentional behavior. We recently changed it to safely power down disk drives after the last partition is unmounted, which was a feature that hundreds of people had loudly asked for over the last, like, 10 years. :) Your hard drives are actually far safer now than they were before! I understand that this is somewhat inconvenient for your particular use case, but there is a very simple workaround: instead of unmounting the last partition before mounting another one, just mount the other partition first and *then* unmount the first partition.
Sorry, I can't accept this as resolution. You have the right to mark it as "won't fix', but your kind of workaround is not a solution. I suggest to leave it for another developer, rather than closing it just to close one more request.
> Sorry, I can't accept this as resolution. Why not? It's a trivial change in your behavior in exchange for a critically important fix that improves your hardware's lifespan.
Because software must be my tool, serve my needs (when I say 'my' I refer to me as the user generally speaking, not to myself), not me serving the software. This is my philosophy as software developer and I still get many thanks from my clients (along with a living). If you ask me, being software developer, to change my methodology, let's say, from Paint Shop Pro to Photoshop, in order to achieve the same results, I understand the advantage of the new approach. Also from Word to QuarkXpress. And the examples could continue... Yet, I don't see such gain here. At least an option would have been nice. I sincerely don't know why would this be that complicated to make you refuse it so shortly.
@Nate " . For drives connected through USB, the effect is that the USB device will be deconfigured followed by disabling the upstream hub port it is connected to." Which won't park the head or anything it just kills the data stream. Instead what we actually want is to send an ATA command: http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Drive.Ata.html Setting PmStandby would solve this case here as we still have a data connection whilst probably doing a better job of handling the hard disk case. Is there a reason to power off?
Interestingly, the documentation continues with "Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives. Applications can examine the "SiblingId" property to determine such relationships. There are not a lot of guarantees associated with this method so it should only be called in response to an user action. Usually the effect is that the drive disappears as if it was unplugged." But might be more. Since I've noticed this behaviour, one more thing happens with other external disk (one drive). It refuses to eject, although I can't find any application using it. It started to behave so similar to Windows in this regard...
These are great questions for Stefan Brüns, who implemented the feature in question and is much more knowledgeable about the technical details of how Solid interacts with hard disks.
(In reply to David Edmundson from comment #5) > @Nate > > " > . For drives connected through USB, the effect is that the USB device will > be deconfigured followed by disabling the upstream hub port it is connected > to." > > Which won't park the head or anything it just kills the data stream. > > Instead what we actually want is to send an ATA command: > http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2. > Drive.Ata.html > > Setting PmStandby would solve this case here as we still have a data > connection whilst probably doing a better job of handling the hard disk case. > > Is there a reason to power off? Why are you omitting the part immediately leading your quote? --- Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that no process is using the drive, then requesting that in-flight buffers and caches are committed to stable storage. The exact steps for powering off the drive depends on the drive itself and the interconnect used. --- It is not the job of solid to reinvent proper device handling, but communicate with the operating system and its helpers. If the power down sequence is not implemented properly in UDisks2, it would be a bug in UDisks2, or possibly in the kernel.
Right, still, had no corruption before - was there an other method? Still, I need to mount/unmount separately than powering off. As any other disk or data storage. And I have one tat I can never eject without powering off the system. Why?
Also, "then requesting that in-flight buffers and caches are committed to stable storage" should be done on any unmount or whatever similar operation, not for powering down only. If the data stream is cut, should be cut in a safe way.
(In reply to Mihai Sorin Dobrescu from comment #9) > Right, still, had no corruption before - was there an other method? > Still, I need to mount/unmount separately than powering off. > As any other disk or data storage. > And I have one tat I can never eject without powering off the system. Why? The unmounting *always* flushes the buffers from the operating system. The drive will also eventually flush its internal buffers. A drive which supports eject should flush its internal buffers in the drive before actually ejecting the medium (safe any firmware bugs). If the driver does not support ejecting, it is explicitly told to flush the buffers and to stop *by UDisks*. This makes sure the heads are in the park position. Without power down, the disk is still spinning, and the heads may be flying above the platters. You can use the UDISKS_CAN_POWER_OFF udev property to disable power down.
Tell that to a simple user. Even though would go in that config, the content will scare him. Some option should be in the UI.
A new question, after thinking at the power down vs. keeping it online by simply unmounting. I see two cases: - power on the enclosure, the available disks are listed, not yet mounted - mount at least two by pressing the "arrow down" button - case I: press the "arrow up" button and ... what happens? The disk is unmounted for sure, not powered down, it is still listed and could be mounted again - if it is the case repeat the above action until there is only one drive mounted left - case II: press the "arrow up" button and, being the last mounted drive, the power down is triggered. What is the state of the before unmounted drives? Were they safely powered down too or not? I have several scenarios when I need to mount/unmount freely (like when I unmount them to scan them with a tool like gparted), but not want to power them down. At the end of operating with them, I clearly need to power them down all, safely. Most important, in the both cases, flushing their streams expressingly is mandatory. Definitely, both features are needed.
duplicate of bug 293906
Similar, but not actually the same issue. That one's about the display in the Devices Notifier Widget, but this bug is about what's going on on the backend.
Backend functionality is important for the reason of the current behaviour, but I think the mounting unavailability is the main issue for the user. Thinking of not IT related persons, they won't even care and understand the technical background. So it is pretty much the same bug from the user experience point of view. A reliable technical solution is a must. Discussing the configuration, as Sabayon user I am not comfortable with the workaround of editing configuration files because my distro updates them from time to time and becomes a pain to run a diff and conceal that.
I have a supplemental issue related to this. Some disks go to sleep after a while (WD Green type). At this point, I can't revive them unless a power down them occurs. At this point, the disks are mounted from the OS point of view. Trying to eject them or system shutdown/reboot will try to eject and power them down indefinitely, as they are already powered down or sleeping (?). This is a mess. Don't know if it is possible to raise some event when the hardware goes to sleep, though. Another problematic situation is when a disk goes to sleep and the system seems to "think" the disk is available. You have apparently a woken up disk, Dolphin can browse on it as long as it has a cache of the file system until you try to operate on it, like copying or moving files. Then KDE becomes pretty much stalled. No new mounts can be done, complaining to have not available D-Bus resources anymore for that. Dolphin starts having trouble. But not Gnome's file manager, not the GTK based apps (like EasyTag). VLC works too. But even the KDE/Plasma Desktop might become unresponsive. I don't know how much of thesee can be fixed, but it should improve KDE as much as possible.
One more question: Assuming I have a multiple disk enclosure, mounting two disks, ejecting disk A, then B, will flush and ensure the disk A (first ejected) is in the full written state too, along with the last ejected disk?
*** Bug 405617 has been marked as a duplicate of this bug. ***
*** Bug 404946 has been marked as a duplicate of this bug. ***
*** Bug 293906 has been marked as a duplicate of this bug. ***
*** Bug 405979 has been marked as a duplicate of this bug. ***
*** Bug 406362 has been marked as a duplicate of this bug. ***
There seems to be a lot of rambling on this bug report about loosely related topics. My issue is that a USB device should not have to be unplugged and re-inserted by design. That is a very poor working practice. You should be able to choose or default to Unmount rather than Eject (aka "Safely Remove") devices that do not require ejection. Is there no way for the programming of the Device Notifier to detect if a plugged in device is a spinning hard drive vs. a USB thumb drive? BTW, my WD USB spinning hard drive does not need to be "parked" to be removed. This effectively make Notifier mostly useless for USB thumb drives. If I have to go to the command line so I don't have to reach behind my monitor or PC case to unplug and reinsert my USB drive, then why have the GUI Notifier? At a minimum, "Unmount" should be in the options available and at best be the default choice when clicking the up arrow in Notifier. I'd bet that there are oodles more thumb drives being used than portable hard drives. Let the lesser sized user group have the extra "Fully Eject" option available in the action list but make Unmount the option. Seems way more logical to me.
For me there is one more thing important: to be able to eject "logically" with the insurance of data fully written on it. Then to be able to eject it for "physical" eject - unplug, with the insurance of data fully written on it (as it is now). Don't know if there are cases when somebody wouldn't want to commit the writes. Is there any?
Agreed, however in the case of USB thumb drive, unmounting forces commit or it won't unmount until cache is clear. It least that's my belief. IME I can't unmount any file system until it's not being used. Part of the issue might be the understanding of eject vs. unmount. A file system is unmounted, but not ever "ejected". A device may be ejected, but only cleanly if it has been unmounted prior. A device, like a USB thumb drive or USB hard drive is never really in need of "Eject" because once the file system(s) on it are unmounted you can just pull it out. This is where this whole mess started. Someone had multiple file systems on a USB device and failed to unmount one or more of them before pulling the plug. This could cause a file corruption if a write were not complete. This potential outweighed (at least in some persons minds) the inconvenience to the thousands of users just a thumb drive. In my mind, the best possible solution for USB r/w storage devices is an "unmount all" condition where all file systems on the device are unmounted. "Eject" does this conveniently enough but then you end up where we are - pulling a re-inserting the device. Seems like an expansion of the Notifier actions in this regard is in order.
Thinking it over, what I would like to see is; If the USB storage device is a CD/DVD/BR, "Eject" is the default action. If the device is a USB attached file system but not a CD/DVD/BR, then set "Unmount all file systems on this device" as default action, and offer "Unmount only this file system" as an action in the list for the device. Then if you want to unmount and grab your thumb drive or USB hard drive, the default is perfect. If you are continuing to work with a multi-file system USB device, then you can select and specify which file system to unmount (or mount). In both cases, the device remains accessible because it has not been powered off by Eject.
People have long requested to power-down-on-remove, see bug 270808. The problem is the way the power-down is done. May be an udisk2 bug. When I use the 'hdparm -y /dev/sdX' command, the disk is powered down, but it is still visible in /dev, so that it can be remounted later without an unplug/replug cycle.
That doesn't seem to work here, at least not with a USB stick: sudo hdparm -y /dev/sdi [sudo] password for stuart: /dev/sdi: issuing standby command SG_IO: bad/missing sense data, sb[]: f0 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The drive is still mounted after this and unmounting first has the same results.
hdparm is for spinning disks. It doesn't unmount, but sends a direct IDE/SATA command to the disk. Different needs for different device types...
(In reply to Stuart K. Smith from comment #26) Right, sorry I was careless about terminology, this discussion began after all from the wonderful Linux flexibility of mounting and unmounting disks so blamed by the initial DE users, but you know what I've meant. I have never had multiple partitions for the disks I need to handle like this, but indeed, having this feature for them at partition level is very important also. (In reply to Christoph Feck from comment #30) I need primarily this for hard disks, but what about sticks? Sometimes unmounting only is needed, especially for backing them up before making some bootable stick with some tool that requires unmounting it? Is this possible? Assuring the safe unmount is very important, generally speaking. Remember Windows initial stick eject that corrupted the filesystem. How safely can these be unmounted?
Mihai Sorin Dobrescu: I totally got what you meant and my comment wasn't pointed at you. Rather, I was try to illustrate a broader point that different devices needs different actions and the terms are important because of that. Using "Safely Eject" obfuscates the actual needed action and is part of the problem in my view. Christoph Feck: Precisely and exactly to the issue. There are many uses for the Notifier when controlling USB storage devices and there is no "one size fits all" solution. Fully ejecting a non-spinning device in unwarranted and in many cases very inconvenient.
FWIW, I withdraw my original comment in #5 From the kernel ioctl udisks calls https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=253e05724f9230910344357b1142ad8642ff9f5a it very much affects usb devices. I'm happy to admit that kernel and udisks people know way more than me when it comes to this sort of thing.
*** Bug 414906 has been marked as a duplicate of this bug. ***
Still not resolved.
Well, the most annoying is, I realize now, when I need to scan a disk - so it goes away at unmount.
*** Bug 334429 has been marked as a duplicate of this bug. ***
An idea: what if the devices under same controller are grouped under a tree node and a device can be mounted/unmounted by clicking on it's button and the controller itself by clicking on it's own button? What if that controller would eject all its children, if possible (if they are in use, is expected not to, for example)?
Could you add an umount option next to safely remove so people could choose which function to use? I'm mainly looking for this function so that I could umount usb sticks and not have to re-plug them in if I wanted to manage the stick's partition table.
So to do this, we need changes in a few places: - The Device Notifier and Solid framework, to fix Bug 293906. - KIO framework, to fix Bug 405979. I've done some re-arranging so that the bugzilla tickets reflect this. *** This bug has been marked as a duplicate of bug 293906 ***