Using openSUSE 12.2 with gnome (3.4), I encountered weird behaviour of unmounting external drives, especially flash drives.
The thing is:
When I copy large file(s) to the flash drive, the copy dialog finishes much sooner than the files are actually written, due to heavy cache usage.
If I try to unmount it while the copy dialog is open, it shouts that a program is still using the drive, as it should. HOWEVER, if it is already closed (but files are still being writen - the LED indicator flashes), unmounting the drive is succesfull, but the cache contents are still being written to the drive!
When the drive is very slow, it can take more than few minutes for the write to finish. I see no way to tell if I can already remove the drive (other than the LED). Even iftop doesn’t list it as a disk operation. I can see some correlation between the end of the writing and release of some cache assigned RAM space, but this is not really good method (especially when deleting files useless).
It is painful because I’m going to buy flash drive without the LED indicator.
I understand that the copy dialog is finished before it is physically there (small files & media with limited write cycles). But I’m convinced, that enabling unmount before the cache contents are written, and thus providing no way to tell if it’s safe to remove the drive, is just wrong.
Basically, I have two questions:
Is there any way to know, if all I/O operations are finished (other than the LED indicator)?
Should this be filed as a bug somewhere?
To be more specific (and sorry for not finding the edit post button:shame:),
by unmount, I mean here unmounting via nautilus or the bottom left corner tray (it seems they do completely the same), not a CLI umount.
> If I try to unmount it while the copy dialog is open, it shouts that a
> program is still using the drive, as it should. HOWEVER, if it is
> already closed (but files are still being writen - the LED indicator
> flashes), unmounting the drive is succesfull, but the cache contents are
> still being written to the drive!
It smells to me of a nasty bug. Please report in Bugzilla.
in KDE you get somewhat the same behaviour - as in the progress indicator has completed but files are still being written.
The difference in KDE though is that if you try to unmount / remove the device while writing is still occurring you do not get the “the device can be safely removed” message. I think the message you get is something like - “preparing for removal”
So the lack of any kind of indication would seem to be a gnome / nautilus bug.
You click there on the “remove savely” or something like that, but does it tell you that that action is finished? I mean normaly there is some graphical confirmation (IIRC a V check) that the unmount (and thus the cache emptying) is done.
And btw, when it takes some minutes before the flashing stops, you have another means to check what the system thinks:
shows all that is mounted, see if it is still in the list.
On 12.1, I just tested: the behavior is not show anything if it is succesfull, and show prompt “Writing data…” with explanation if the cache is not written yet.
But now on 12.2, I get nothing in either case. The icon disappeares, it is not listed in devices in the Nautilus left bar anymore, and it is not listed in the “mount” output as well.
Now I get prompt just if trying unmount while the copy dialog is in progress, or any other program has an open handle on some file there.
On 2012-11-19 13:36, hcvv wrote:
> Hm, when it not mounted anymore, there should be no read/write activety
> (as long as no direct access to the device using the device files is
> done, but I think we can rule out that).
It can be umounted lazy.
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))
On 11/19/2012 08:34 AM, Carlos E. R. pecked at the keyboard and wrote:
> On 2012-11-19 13:36, hcvv wrote:
>> Hm, when it not mounted anymore, there should be no read/write activety
>> (as long as no direct access to the device using the device files is
>> done, but I think we can rule out that).
> It can be umounted lazy.
If you are not sure you can always use
on a command line and wait the your prompt to return meaning all write
requests are finished.
Tested liveCD against liveCD, so it is not affected by any local settings:
still observing undesired behavior on 12.2 only
comparing mount and /proc/mounts in 12.1 and 12.2, there were differencies:
both mount and /proc/mounts: in 12.1 there was one more option - “flush” (also uid=<number> differs, but that’s not related).
mount only: “uhelper=udisks” in 12.1 vs “uhelper=udisks2” in 12.2
It seems to me that, based on the flush option, in 12.1 the copy dialog waits for the cache to be (almost completely) written. However it is still possible to get the “Writing data” window (on image above) for like a second.
Anyway, manually adding the flush option wouldn’t fix the core of the problem, just partially work-around it. The core of the problem here is missing notification (one like above) of pending cache writing.
**If there are other people observing the same problem, please tell us here - just to be sure that I’m not doing something in a really wrong way. **
Ohhh, I’ve exactly the same problem like this. I’m using 12.2, KDE. This bug damaged my phone SD card and I had to re-format it.
Is there anyway to put some true progress bar like a popup notification, or a progress bar in Dolphin?
This bug is really bad and disappoint me.
It is possible to add the flush option manually with the “Disks” utility (in Gnome), or by manually editing /etc/fstab (equivalent, Disks edits it too). But it is done for specific devices separately (they are identified by id, label or somehow else). Any new device will still be connected with the default settings, without flush.
Does anyone know how to change this default behavior (not using flush) for any flash drive(s)? I wasn’t able to find solution after long googling…
Attempting to add flush is just to achieve better state than currently, I am still willing to report the cache emptying as a bug. But first, I want to collect as much related information as possible about the topic.
I found nothing about changing settings for the udisks2. Even after intensive search through the filesystem, I didn’t find anything like udisks2 config file :
I can’t see other quick temporary solution for the problem, than manually making sure with sync command before unplugging.
You could try udiskctl directly, it allows passing mount options:http://people.freedesktop.org/~david/udisks2-20110628/udisksctl.1.html
But I suspect that it is not controlled by udisk2 at all, and is completely client (i.e. in this case GNOME) issue. We already went through it when centralized configuration of mount options was removed from HAL in favor of client side explicit options …
> I am still willing to report the cache emptying as a bug. But first, I
> want to collect as much related information as possible about the topic.
I would suggest opening the bug report now with what you do know, and
then adding any further information you discover later. That way, the
devs may start to examine the problem and may even fix it. Increase the
number of eyes looking at the problem.
I’ve just found a temporary solution for this. In system tray, right click on Notifications icon, go to settings and uncheck the option “File Transfer and other jobs”. After logout and login, when you copy files, there’ll be a dialog show you the copying progress.
I hope Dolphin in KDE will add this progress bar feature soon.
As mentioned earlier - this bug is not present in KDE
Although the taskbar progress dialogue can be somewhat inaccurate - the same as in gnome - if you click the taskbar icon to remove the usb drive while writing is still occurring you will get a message that simply states “removing”
You should not remove until you get the “it’s now safe to remove” message.
The inaccurate transfer reporting is discussed a little in this bug