Ubuntu

nautilus hangs on accessing vfat drives - statfs() blocks for a long time

Reported by Rocko on 2007-08-20
70
Affects Status Importance Assigned to Milestone
gnome-mount (Ubuntu)
High
Martin Pitt
Nominated for Gutsy by Wousser
hal (Ubuntu)
High
Martin Pitt
Nominated for Gutsy by Wousser
nautilus (Ubuntu)
Medium
Martin Pitt
Nominated for Gutsy by Wousser

Bug Description

Binary package hint: nautilus

In Nautilus 1:2.19.90-0ubuntu1 (gutsy tribe 4), when I first try to access a newly mounted vfat USB drive, there is a long delay (I've timed it up to 65 seconds). Nautilus appears to hang because no other Nautilus windows respond (and they go grey).

There's no delay in accessing the drive through the command line immediately after mounting. There's no delay the second or subsequent times that I try to access the drive's folder through Nautilus.

There isn't a delay when first accessing external ext3 or ntfs drives.

Sebastien Bacher (seb128) wrote :

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem. Does it happen when using a fileselector? How do you mount the drive?

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Rocko (rockorequin) wrote :

I've attached a backtrace of the command 'nautilus' run on the offending directory, but it doesn't look very useful. Nautilus doesn't crash, it just hangs for a long time (in the log, the delay starts after the lines 'Initializing gnome-mount extension; /bin/sh: /usr/bin/esd: not found' appear) . After that, it's fine. On subsequent accesses, it runs at normal speed.

In this instance, I'm mounting with the command:

sudo mount -t vfat /dev/sdf1 ATHENA

The mount command runs quickly. If I do

ls ATHENA

the listing comes up quickly.

But when I run "nautilus ATHENA" (whether I have run the 'ls ATHENA' command or not), the nautilus window appears, but there's a long delay before it is filled with the directory listing. During this delay, already open Nautilus windows don't respond, either, nothing launches from the Places menu, and nautilus doesn't launch from the command line. Then it all fires back into life after the delay is over (eg lots of Nautilus windows launch if I've tried to run them).

I have noticed that while Nautilus is frozen, either nautilus, gnome-volume-manager, or usb-storage tend to run at 4-7% of CPU, which is unusual.

This delay used to happen when I first installed Gutsy tribe 4, back in the days when gnome-volume-manager/gnome-mount could auto-mount the external drive (it can't anymore - see bug 132349). It would mount the drive, then when I first tried to access it through nautilus, I'd get this delay. I can't test it now because I can't get the removable drives to auto-mount anymore. :(

Some application versions I'm running are:

gnome-volume-manager 2.17.0-ubuntu1
gnome-mount 0.6.1-ubuntu2
nautilus 1:2.19.90-0ubuntu1
hal 0.5.9.1-ubuntu2

I've tried with both the 2.6.22-9 and 2.6.22-10 kernels.

yostral (y-o) wrote :

I have exactly the same problem. When I plug in a vfat external usb HDD, Nautilus freezes during about 30 secondes before I can do something (except using other programs like firefox). The window of hdd content opens, but nothing appears and I have the "waiting cursor".

I've attached a backtrace file, but nothing happens, it's not a crash. I had to stop manually the gdb process (Ctrl+C) when "continuing".

I don't do anything special to mount my drive, I just plug it in.

It does that with both 2.6.22-9 and 2.6.22-10 kernels on 32 and 64 bits.

If you need more informations...

Majorix (axabert) wrote :

I have the same problem too. Any fix?

Tom Vetterlein (smbm) wrote :

Ditto here too, FAT32 formatted iPod.

yostral (y-o) wrote :

I can add that does it with my vfat usb hdd, but not with my vfat usb key.

Rocko (rockorequin) wrote :

I noticed that the drive light flickers furiously during the delay. Might nautilus be trying to build a directory listing or run fsck on the drive?

I tried an "strace nautilus <folder>" command, but the process detaches before the delay starts.

I installed tribe5 from scratch in case it would fix it. It fixed another problem (drives not automounting) but not this one.

gnome-volume-manager is at 2.17.0-2ubuntu1 (or maybe I mistyped it in earlier - my previous entry didn't have a '2' in front of ubuntu1).

Sebastien Bacher (seb128) wrote :

No, nautilus doesn't run fsck on the disk. Could you try gnomevfs-ls on the disk, is it as slow as nautilus? Do you have files which are thumbnailed on the disk? Does it happen with a blank one?

Changed in nautilus:
status: Incomplete → New
Rocko (rockorequin) wrote :

gnomevfs-ls is fast. I tried it on the drive immediately after mounting it and it works pretty much instantly. If I mount the drive, then try to open it in nautilus, then run gnomevfs-ls on the drive, it works straight away, even while nautilus is frozen.

I haven't thumbnailed the files on the drive, but there is about 80 GB in 1800 files, so I need to find some spare room elsewhere before I can move the files off the disk to test it on a blank one.

Nautilus in Feisty doesn't experience this delay when I first open this disk, by the way.

Rocko (rockorequin) wrote :

I tried emptying the vfat drive completely of all files (including trash), and it still experienced the delay in first opening nautilus.

I tried reformatting the drive using gparted (which incidentally crashed when it went to rescan the drives afterwards, and now my external drives no longer automount), and there is still the delay in first opening nautilus.

The behaviour does seem slightly different from before, though. Now when I mount the drive manually, its light flickers for a while during which gnome-volume-manager and usb-storage consume the most CPU cycles (4-5%). Also during this time, umount reports that the device is busy. gnomevfs-ls still works at normal speed during this time.

When all this finishes, if I run nautilus on the directory, it appears pretty much instantly. So now it seems there is some automated process running when the drive is mounted instead of when nautilus first tries to access it, but nautilus is still freezing waiting for this process to complete.

The only software difference I can see is that hal is now at 0.5.9.1-1ubuntu3 instead of ubuntu2 and nautilus is 1:2.19.90-0ubuntu1 instead of .91-0ubuntu1.

I checked again that this delay isn't happening on my external ext3 drives.

Rocko (rockorequin) wrote :

Re my previous comment, after rebooting, my drives are auto-mounting again, and now I can confirm a difference in operation between automounting and manually mounting the drive:

a) If the drive automounts, gnome-volume-manager doesn't spend ages doing something with it until I try to open it in nautilus. Then gnome-volume-manager gets busy and nautilus freezes until it has finished.

b) If I manually mount the drive with sudo mount, gnome-volume-manager immediately spends ages doing something with the drive. If I try to open the drive in nautilus during this time, it freezes until gnome-volume-manager is finished, but if I wait until gnome-volume-manager is finished before opening nautilus on the drive, nautilus shows the contents immediately.

This is on a freshly formatted drive. (gparted reports that 55.91 MB out of 111.79 GB are used.)

Sebastien Bacher (seb128) wrote :

That doesn't look like a nautilus bug if gnome-volume-manager is have issues as well. Do you have anything about the drive to /var/log/messages or /var/log/syslog?

Rocko (rockorequin) wrote :

I can't see anything too unusual in those files except that I get two "nm_policy_device_change_check" messages every five seconds in syslog. But this happens whether the drive is plugged in or not.

Attached is a file showing:

(a) what appeared in syslog and messages when I plugged the drive into Gutsy just now. Nothing was added to the logs after I issued the mount command, which is when gnome-volume-manager experiences its delay. (My drives are not automounting anymore after today's updates, so I had to manually mount it.)

(b) what appeared in syslog and messages when I plugged the drive into Feisty earlier.

Rocko (rockorequin) wrote :

I think the problem lies within the code that the system call sys_statfs64 executes, perhaps when it calls the vfs code for the vfat file system.

I straced sudo nautilus to stop it sending the request to any existing process:

1. killall gnome-volume-manager
2. Attach drive
3. sudo -i
4. mkdir athena
5. mount -t vfat /dev/sdb1 athena
6. strace -T -e trace=statfs64 nautilus athena/ 2>&1 | tee nautilus.log

On the console display, the strace output stops at:

statfs64("/root/athena", 84,

The long delay occurs at this point, after which the strace output continues. The complete statfs64 call is:

statfs64("/root/athena", 84, {f_type="MSDOS_SUPER_MAGIC", f_bsize=16384, f_blocks=7322563, f_bfree=4030796, f_bavail=4030796, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=260, f_frsize=16384}) = 0 <30.477798>

I did an strace on gnomevfs-ls and it doesn't call sys_statfs64 on "/root/athena", which would explain why it executes quickly.

If I do the same on an ext3 drive, which brings up the listing very quickly, instead of making a single call to sys_statfs64 on the folder, it makes a number of very quick calls to statfs64 on the folder. An example is:

statfs64("/root/500gb", 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=120179764, f_bfree=10120650, f_bavail=10120650, f_files=61063168, f_ffree=61031300, f_fsid={-446547190, 219755455}, f_namelen=255, f_frsize=4096}) = 0 <0.000216>

Mathias Gaunard (loufoque) wrote :

I am having this problem too, be it with IDE or SATA drives.

Sebastien Bacher (seb128) wrote :

opening a linux-source-2.6.22 task, maybe the kernel team knows about some vfat issue

Rocko (rockorequin) wrote :

Can someone from linux-source look at this? It is still marked as importance: ''Undecided'. Is it readily reproducible or do just some people have problems with it?

Imho I think it's quite important, as having to waiting 30-60 seconds to mount an external drive (during which all other nautilus windows freeze) is very annoying.

Cesium (benjamin-r-lewis) wrote :

Same symptom on first access to a FAT32 partition (added per the standard recommendation for sharing data between dual-boot) on the same internal SATA drive that gutsy is installed on.

Wousser (wousser) wrote :

I can reproduce this bug. I Have an external usb disk drive containing a fat32 partition and a ntfs partition. If I can help please let me know.

modred (bobanderson) wrote :

I have the same bug. It affects both a Fat32 partition on my internal SATA hard drive and a Fat32-formatted USB external hard drive.

Xavi Francisco (srxavi) wrote :

Same to me here, but I also noticed that the time taken to open the disk is proportional to the size. So a 1 Gb USB drive takes a few seconds (10 or so) and a 250Gb USB drive takes about 10 minutes to mount. Using HTOP I could also notice that the kernel process is using 100% of the CPU while I cannot access the drive. When it stops being at 100% I can start accessing the drive.

Sika (sikamikaniboots) wrote :

Same problem here with a partition on my main HDD. I think it might be related to the kernel.
I had feisty installed and I updated the kernel to the gutsy one (see http://ubuntuforums.org/showthread.php?t=511974) (because my wifi chipset wasn't supported in feisty). The problem only happened when I used the gutsy kernel. No problem with the feisty one, using the same nautilus version.
I thought this was due to some sort of incompatibility but now I've just completely upgraded to gutsy and the problem is still here.

I think (but not completely sure) that at startup, I had the same problem when fsck was trying to access this partition. I can check if it's still happening if it is important for you.

Cameron Gorrie (sastraxi) wrote :

Happening here too, a Vantec Nexstar 3 external harddrive/Seagate 500GB. The delay can be up to 5 minutes, on a Dell Inspiron 6400 (gutsy).

Nick B. (futurepilot) wrote :

I can also confirm this. I have an Iomega 160GB USB hard drive (FAT32) and whenever I first try to access it, Nautilus hangs.

wusch (christoph-pojer) wrote :

can confirm this bug too. It did not happen in feisty (though I only used it to format and then to copy files to it, but there were no hangs or lags at all). I reinstalled my computer yesterday with gutsy and all latest updates. Everytime nautilus freezes, which is really anoying, since nautilus takes a little time to come back after killing the process. It is a Western Digital USB2.0 with 320 GB and fat32 partitioning, with around 40 GB of files.

Michael R. Head (burner) wrote :

Yep, this is really annoying. I have 2 500GB drives and 2 250GB drives that I attach via a USB2.0 hub. I've been using this setup for a while now, and have just upgraded to gutsy and run into this. It takes several minutes to open the drives in nautilus.

I assume this has to do with the new "pacman" disk usage feature.

Nick B. (futurepilot) wrote :

I found out that I can access the drives through other programs while Nautilus is frozen. I have all my music on my external drive and I can play it off that drive with a media player while Nautilus is frozen. I can also initially access the drive without any problems using a different file browser other than Nautilus.

Sebastien Bacher (seb128) wrote :

Could anybody get a backtrace of nautilus while it's hanging? I don't get the issue on my gutsy installation using a disk partition or an usb key

Michael R. Head (burner) wrote :

What's the best way to go about getting a backtrace?

wusch (christoph-pojer) wrote :

I'd like to help of course, but I don't know how to backtrace it. Would you be so kind telling me? I really would like to see a fix until gutsy release since it is an annoying bug :D

Sebastien Bacher (seb128) wrote :

the informations have been requested with an uri to a wiki page which has explanations in the first comment to this bug, users interested to an issue could read the comments

Michael R. Head (burner) wrote :

I take it the existing backtraces attached to this report aren't good enough?

Wousser (wousser) wrote :

I hope I did it the right way.

Nick B. (futurepilot) wrote :

I thought maybe something had gone wrong with the upgrade, so I downloaded the latest daily live CD and it's still happening on the live CD.
Like Xavi Francisco said, the length of time Nautilus hangs is related to the size of the drive. It's barely noticeable with a 2GB USB flash drive, but with a hard drive that is a few hundred GB in size Nautilus hangs for many minuets.

Sebastien Bacher (seb128) wrote :

No, there is no correct backtrace attached yet

Martin Pitt (pitti) wrote :

This is evidently not a kernel bug. Mounting, ls, gnomevfs-ls, etc. all work fine immediately.

I get this bug, too, BTW. I'll have a look at gdb'ing the problem.

Changed in linux-source-2.6.22:
status: New → Invalid
Martin Pitt (pitti) wrote :

Confirmed here:

19545 12:28:26 statfs("/media/PittiHD", <unfinished ...>
[...]
19545 12:29:25 <... statfs resumed> {f_type="MSDOS_SUPER_MAGIC", f_bsize=16384, f_blocks=15254800, f_bfree=559138, f_bavail=559138, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=260, f_frsize=16384}) = 0 <59.423616>

Martin Pitt (pitti) wrote :

When booting current gutsy with the feisty kernel, the hang does not occur, so it is a VFAT specific kernel regression. Sorry for prematurely closing the kernel task.

Changed in linux-source-2.6.22:
status: Invalid → Confirmed
wusch (christoph-pojer) wrote :

which is quite interesting since every program but nautilus works fine without any slowdowns or freezes.

Martin Pitt (pitti) wrote :

The bug can easily be reproduced by attempting "df" right after mounting. This also does a statvfs() call and thus will hang.

Martin Pitt (pitti) wrote :

Hacking on a workaround.

Changed in nautilus:
assignee: desktop-bugs → pitti
status: New → In Progress
Martin Pitt (pitti) wrote :

nautilus (1:2.20.0-0ubuntu6) gutsy; urgency=low

  * Add debian/patches/12_vfat_no_free_space.patch: Do not show the free space
    for VFAT volumes in the file browser. This avoids the most prominent
    incarnation of the "statfs() takes minutes after mounting a vfat
    partition" kernel bug. (LP: #133567)

 -- Martin Pitt <email address hidden> Thu, 04 Oct 2007 17:08:53 +0200

Changed in nautilus:
status: In Progress → Fix Released
Martin Pitt (pitti) on 2007-10-04
Changed in linux-source-2.6.22:
importance: Undecided → Medium
wusch (christoph-pojer) wrote :

It now hangs on right click -> properties. And it does not show the free space left on the drive, so it is not really a good solution I think.

Michael R. Head (burner) wrote :

That's why it's a "workaround," not a "solution."

Hi,

wusch [2007-10-04 19:33 -0000]:
> It now hangs on right click -> properties.

That is known. However, I feel that it is better for the dialog to
take a minute to appear and display correct results than to break this
as well. After a few minutes, the dialog does not hang any more
anyway. OTOH the 'free space' message is put into the browser dialog
immediately, there is no chance for delaying this.

> And it does not show the free space left on the drive, so it is not
> really a good solution I think.

It is not intended to be a solution. But since there is no way to fix
the Gutsy kernel in time, we have to live with this hack, I'm afraid.

Rocko (rockorequin) wrote :

The hanging problem has just been moved to later, and worse still, you can now experience data loss.

I did the following in Nautilus:

1. Unmount drive
2. Mount drive.
3. Open folder. (Folder appears quickly, no hanging.)
4. Move a file on the drive from folder A into a subfolder B of A. Nautilus hangs with the 'Moving file' window.

The data loss occurs thus: I press 'cancel' in the 'Moving file' window while it is hanging, and when it stops, my file is in neither A nor B. It completely disappears. If I select 'Paste' at this point, it reappears in folder A. However, if you do other copy/cut operations in the meantime, the file is lost.

Nick B. (futurepilot) wrote :

I also noticed that this will hang Conky if you have a disk monitor for that drive. I guess I could just remove it for now, but I like to keep an eye on my hard drive.

wusch (christoph-pojer) wrote :

the current workaround is not really suitable. Nautilus now hangs on the properties dialog and while copying files. Right now I copy a random file via nautilus after booting my computer to avoid any serious data losses. Don't get me wrong, but this really is a major problem!

Sebastien Bacher (seb128) wrote :

Do you have any other suggestion knowing that the bug is a linux vfat one and that the package will not likely change again before gutsy?

wusch (christoph-pojer) wrote :

didn't want to be rude, sorry. Just wanted to say that it is not only a medium problem since I think a lot of people will run into this problem

Sebastien Bacher (seb128) wrote :

you are not rude, the bug tracker is about working on bugs and such comments are not really constructives in this context, maybe the issue will be fixed in a stable linux updates

Bogdan Butnaru (bogdanb) wrote :

I know this is a bit complex to work-around, but we could hack Nautilus to work around this whenever it encounters a VFAT volume.

If I understand correctly, Nautilus uses the statfs call to determine the free space on the drive, to show it on the bottom of the window.

I would suggest that Nautilus start a new thread to call statfs; since other programs can read the drive contents correctly, I suppose Nautilus should be able to do the same. It would work as usually, minus whatever the statfs call is needed for, until the separate thread finishes the call.

I know this is complicated and probably not worth it, I just wanted to have the suggestion.

Otherwise, I strongly advise to revert the patch with data-loss possibility. The delay after mount is annoying, but it's less than a minute long and it only happens at mount time, I think it's much less annoying than loosing files and locking up randomly.

Daniel R. (danielr-es) wrote :

Hello,

I am a Debian user, but got the same problem when testing a recent vanilla kernel release.

Asking the source of knowledge seems to be always the best way... This is the response from FAT kernel developer (available in MAINTAINERS file in kernel sources' root):

>Thanks for report. This is known issue.
>
> This slowdown is a necessary to avoid the "free clusters" issue, we
> can optimize it more or less although.
>
> If the partition is shared with recent Windows, Windows may write the
> wrong "free clusters" value. Then if you are not using "usefree" (IOW
> if you are enough with previous behavior, you can use "usefree"
> option), FAT may display and assume the wrong free space.
>
> It means FAT will stop to write at "free clusters" == 0, even if there
> is the free space actually.

In fact, that option is documented in file /Documentation/filesystems/vfat.txt (in kernel sources' root, at least for last development kernel release):

> VFAT MOUNT OPTIONS
> (...)
> usefree -- Use the "free clusters" value stored on FSINFO. It'll
> be used to determine number of free clusters without
> scanning disk. But it's not used by default, because
> recent Windows don't update it correctly in some
> case. If you are sure the "free clusters" on FSINFO is
> correct, by this option you can avoid scanning disk.

Maybe "mount" man page should be updated.

Daniel R. (danielr-es) wrote :

The original thread explaining the origin of this behaviour can be found here:

http://lkml.org/lkml/2007/4/19/126

Michael R. Head (burner) wrote :

Confirmed that usefree fixes this. I manually mounted one of my USB drives with usefree, and df didn't hang.

However, when I popped open gconf-editor, and updated /system/storage/default_options/vfat/mount_options to have the additional option "usefree", I get an error window saying "Invalid mount option when attempting to mount the volume ..."

So I guess g-v-m needs to be updated to know that this is a valid option?

Michael R. Head (burner) wrote :

Actually, I guess hal needs to be updated.

There should be an <append key="volume.mount.valid_options" type="strlist">usefree</append>

around line 181 in 20-storage-methods.fdi

Once that's there, then you can use "usefree" in values for the gconf key /system/storage/default_options/vfat/mount_options

Michael R. Head (burner) wrote :

(BTW, you can just "sudoedit /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi" and add that in there and use gconf-editor to add the string to the option list and it should all work)

Martin Pitt (pitti) wrote :

Michael, thanks for the research upstream. Indeed I just had the same idea of fixing it in hal, before I saw your recent comments. Let's do that then.

Changed in linux-source-2.6.22:
assignee: nobody → pitti
importance: Medium → High
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

Let's revert the nautilus change.

Changed in nautilus:
status: Fix Released → Fix Committed
Martin Pitt (pitti) on 2007-10-08
Changed in gnome-mount:
assignee: nobody → pitti
importance: Undecided → High
status: New → In Progress
Michael R. Head (burner) wrote :

I've been trying to figure out what the implications are for using the "usefree" mount parameter.

Using the drive with some (which? Vista?) versions of Windows doesn't update the filesystem's free_clusters, and Linux's vfat driver doesn't know where the data is now written (if it is at all).

So, if I use the drive with only Linux, and older versions of Windows (which? XP? 2000?), everything will work peachy, but if I use the drive with some version of Windows, the free counts will be incorrect in Linux.

Is this a severe problem? What are the implications if this happens? Can data loss occur, or is there just a chance that incorrect free space will be displayed?

Martin Pitt (pitti) wrote :

hal (0.5.9.1-6ubuntu5) gutsy; urgency=low

  * Add debian/patches/76-allow_vfat_usefree.patch: Allow vfat mount option
    "usefree". (LP: #133567)

 -- Martin Pitt <email address hidden> Mon, 08 Oct 2007 19:35:05 +0200

Martin Pitt (pitti) wrote :

gnome-mount (0.6-1ubuntu4) gutsy; urgency=low

  * debian/patches/ubuntu-default-mount-options.patch: Use "usefree" VFAT
    mount option by default, to avoid very long blocking of statfs() calls on
    VFAT. (LP: #133567)

 -- Martin Pitt <email address hidden> Mon, 08 Oct 2007 19:37:08 +0200

Martin Pitt (pitti) wrote :

nautilus (1:2.20.0-0ubuntu7) gutsy; urgency=low

  * Drop debian/patches/12_vfat_no_free_space.patch again. It just causes more
    serious effects (up until data loss) later. (LP: #133567)

 -- Martin Pitt <email address hidden> Mon, 08 Oct 2007 19:09:57 +0200

Changed in gnome-mount:
status: In Progress → Fix Released
Changed in hal:
status: In Progress → Fix Released
Changed in nautilus:
status: Fix Committed → Fix Released
Daniel R. (danielr-es) wrote :

Hello, just for you to know (news from upstream):

Expect for the next kernel releases (if everything goes well) a dramatic decrease in statfs() time (without "usefree" option).

I have tested a patch from FAT maintainer (OGAWA Hirofumi) which reduces the time to about 6-8 seconds, in a 15 GByte partition (before it was 60 seconds)

(I applied the patch to Linus Torvalds' git kernel repository - 2.6.23-rc9 )

I include his patch here so you can test (for further info I suggest contacting him).

Regards,

Martin Pitt (pitti) wrote :

Hi Daniel,

Daniel R. [2007-10-09 16:30 -0000]:
> Expect for the next kernel releases (if everything goes well) a dramatic
> decrease in statfs() time (without "usefree" option).
>
> I have tested a patch from FAT maintainer (OGAWA Hirofumi) which reduces
> the time to about 6-8 seconds, in a 15 GByte partition (before it was 60
> seconds)

Thank you for the heads-up! It's too late for Gutsy, so we'll leave
the current workaround, but good to know that this will be fixed
properly in Hardy. Then we can revert the 'usefree by default' change
in gnome-mount.

Daniel Błażewicz (klajok) wrote :

After standard upgrade from feisty to gutsy (32-bit) I noticed the same problem. First usage of "nautilus" or "df" lasts a several seconds - the problem is only with vfat partitions (I have two pata discs):
/dev/sdb1 on /media/kontener2 type vfat (rw,utf8,umask=007,gid=46) []
/dev/sda6 on /media/kontener1 type vfat (rw,utf8,umask=007,gid=46) []

sequence: "umount /dev/sda6; mount -a; time df" gives ca. real 6.3s, user 0.0s, sys 3.3s.
sequence: "umount /dev/sdb1; mount -a; time df" gives real 1.85s, user 0.0s, sys 1.05s
(in both cases: next "time df" give times under 0.01s)

df:
(...)
/dev/sda6 124828304 73965376 50862928 60% /media/kontener1
/dev/sdb1 39058992 35982816 3076176 93% /media/kontener2

=> time is proportional to size of partition.

Daniel Błażewicz (klajok) wrote :

Oh, I'm sorry. I didn't notice that this bug has been solved... I added "usefree" to /etc/fstab and the problem has gone.
If I may, I have one question: Why this "manipulation at /etc/fstab" wasn't automatic with update of gnome-mount to version 0.6-1ubuntu4 or with upgrade system to gutsy?

Martin Pitt (pitti) wrote :

We do not add non-Ubuntu partitions to /etc/fstab by default any more, so this should only affect people who manually added them and thus know where to change it. Automatically changing fstab on upgrades is not an option, since we do not always know what the admin actually put there deliberately.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers