evil breezy unmounting action due to async filesystem

[Allison Karlitskaya]

When I plug in my vorbis player:

/dev/sdb1 on /media/IAUDIO type vfat
(rw,noexec,nosuid,nodev,quiet,shortname=winnt,uid=1000,gid=1000,umask=077,iocharset=utf8)

I seem to remember that hoary used to mount vfat volumes sync. jdub told me
that there's no such thing as 'sync' for vfat filesystems, so I'm not sure if
that's the problem.

Either way, behaviour on unmount is much worse on breezy than it was on hoary.
With hoary the data would be written to the volume fairly quickly within
requesting an unmount and with breezy it takes an awful long time (sometimes
minutes).

This is bad since I have no way of knowing when it's safe to unplug the device
without looking at /proc/mounts or typing 'sync' into a terminal and waiting.
This will be a nightmare for people in my family, at least, since they are all
heavy users of their mp3 players. I'm not looking forward to having to explain
this to them.

Request: either make it so that reads/writes to removeable devices are done
synchronously or give some sort of user feedback on unmount about when it's safe
to unplug a device.

Cheers.

http://bugzilla.gnome.org/show_bug.cgi?id=313639: http://bugzilla.gnome.org/show_bug.cgi?id=313639

[Sebastien Bacher (seb128)]

The change is probably this one:

pmount (0.8-2) unstable; urgency=high

  * Urgency high since this fixes an RC bug, the fix should reach Sarge.
  * Added debian/patches/02-async_by_default.patch:
    - Mount devices 'async' by default instead of 'sync'. This will avoid
      physical damage of flash chips due to exaggerated updating of inode/FAT
      structures and greatly speed up the write throughput. On the bad side
      this makes it much less safe to remove devices without proper umounting.
    - Replace option "--async" with option "--sync".
    - Document change in the manpages.
    - Closes: #309591
  * debian/control: Correct package priority to optional, to match the katie
    overrides.

 -- Martin Pitt <email address hidden> Wed, 18 May 2005 15:41:13 +0200

Martin, any opinion on this?

[Allison Karlitskaya (desrt)]

OK. In light of the comments in this changelog, I strongly believe that we
should keep it async.

I'm working on a solution for this.

[Allison Karlitskaya (desrt)]

Created an attachment (id=3173)
gumount.c

A first crack at what I think the solution should look like.

To try it, pop in your USB key, make sure it's mounted async and then copy a
couple of hundred megs onto it then run gumount /dev/sdb1 from gnome-terminal.

Random note: for the progress bar it uses the number of dirty pages on the
entire system from /proc/meminfo. As this number decreases to 0, the progress
bar increases to 100%. This isn't entirely accurate as there may well be dirty
pages assocated with other filesystems. I don't know of any way to get a list
of dirty pages for a partially-unmounted filesystem. This will only ever
result in the dialog disappearing sooner than the user expects, though.

[Allison Karlitskaya (desrt)]

Created an attachment (id=3174)
patch to gnome-vfs

This is a patch to gnomevfs to try to call gumount before pumount.

Since gumount needs to know DISPLAY, XAUTHORITY and possibly others I removed
the environment-zapping code in gnome-vfs. I will replace it with environment
zapping code in the next version of gumount that I upload.

[Martin Pitt (pitti)]

Thanks for your programs! However, unfortunately it is too late to include them
into Breezy since we are already in feature freeze. Up to then users have to get
along with looking at the device's LED/display/whatever. Breezy ejects devices,
so the light on USB sticks will completely go off, the iPod will tell you that
it is save to disconnect, etc.

[Martin Pitt (pitti)]

This is not a pmount issue, pumount and umount block until the write cache is
cleared. It is a Gnome UI issue.

I reported this upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=313639

Ryan, maybe you can coordinate directly with the upstream developers?

[Martin Pitt (pitti)]

*** Bug 21745 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

*** Bug 22827 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

*** Bug 24189 has been marked as a duplicate of this bug. ***

[Martin Pitt (pitti)]

*** Bug 24802 has been marked as a duplicate of this bug. ***

[Maximilian Federle (max-federle)]

I have created a howto to get the gumount functionality in Breezy. (in German)
A install script for Ubuntu Breezy in English is also available: http://home.arcor.de/guenter.federle/ubuntu/install .
I have added a callback to gumount.c so that it can't be killed by accident with a "X" click.

Gruß/Have a nice day Max

[Phillip Susi (psusi)]

I believe this is caused by the kernel removing the mount entry from
/proc/mounts immediately, even though umount is blocked while the dirty buffers
are flushed. Once the entry goes away from /proc/mounts, gnome-vfs removes the
icon. I am not sure if the behavior of removing the entry from /proc/mounts
before the flushing is done can be considered a bug or not.

A simple work around may be to first remount the filesystem read only, which
will block flushing the dirty buffers, but not cause the icon to go away.

I have not tried gumount yet, but if I am correct, then the icon should still
vanish immediately even though gumount pops up and tracks the flush progress.

Another thing I think would be nice to do is initially mount the filesystem as
read only, and provide a right-click option to switch between r/o and r/w.

[Sebastien Bacher (seb128)]

I should probably be hacked from nautilus, that's what upstream suggests and the
bug got reassigned

[Martin Pitt (pitti)]

*** Bug 27685 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

*** Bug 28315 has been marked as a duplicate of this bug. ***

[Martin Pitt (pitti)]

This has recently been fixed, see bug 32643.