Ubuntu
nautilus package

  1. Bug #133567
  2. Comment #14

Comment 14 for bug 133567

Revision history for this message
Rocko (rockorequin) wrote : Re: [gutsy] long delay in nautilus on first access to vfat drive

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>