I'm seeing the same symptoms here, although the 250GB USB drive is mounted at boot via fstab.

The delay is particularly noticeable between the KDM login and the desktop loading.

openSUSE 11.2 (same kernel and architecture as OP) 
KDE 4.3.85

I have the same problem with my external USB HD 320GB & opensuse 11.2 with KDE4. It takes 60 second to mount.

Yes, I see the same with various USB drives of various sizes. I did discover that I only see this with drives formatted as FAT though. When formatting the drives as ext3/4 then they mount instantly.

(In reply to comment #3)
> Yes, I see the same with various USB drives of various sizes. I did discover
> that I only see this with drives formatted as FAT though. When formatting the
> drives as ext3/4 then they mount instantly.

Interesting. I can confirm my issue was with FAT, but I have not tried other formats and I'm not able to at this time.

please try on the commandline as root and tell me if there is the same delay

Yes, I see the same delay. From the command line, if I mount the disk and then try access a folder or manipulate a file on it I get the message:

umount: /media/disk: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Sorry i don't understand. Why do you get a message from umount? What exactly are you executing?

Sorry my mistake. I was flicking between this and a forum and got my posts
crossed up.

From the command line, it appears to be mounting normally, i.e. quickly -
within a second, and I can access folders on the drive immediately afterwards
from the cli. So yes it appears to work normally when mounting from the cli as
root.

But if I mount the drive from the cli and then go directly to Dolphin to access
the drive after mounting the drive, I find that Dolphin doesn't see the drive
as mounted and just sits there for a while before the mounted drive appears.
This delay also appears in the device manager plasmoid.

Hope that helps explain it.

(In reply to comment #5)
> please try on the commandline as root and tell me if there is the same delay

The same result. For me
su -

mount /dev/sdc1 /media

delay 45seconds

I have tried this in KDE4.4RC2 (where is automount option in device applet instead of KDE4.3). The problem with very slow mounting is the same - KDE4.4RC2 freezes near 1 minute during boot as soon as I choose the automount option for my external USB drive (WD MyBook 500GB formatted as FAT32).

In other words: mounting of external FAT USB drive is always very slow, it doesn't depend on the way of its mounting (fstab, manual, device applet...). This problem wasn't in earlier distributions with KDE 3.5 (e.g. - for me - in openSUSE 11.0 and older ones), the mounting was instant here...

Mr. Vogelsang, can you do something with this very "unfriendly" bug? Thank you.

BTW: the same problem is described for example on http://forums.opensuse.org/install-boot-login/428750-boot-very-slow-after-adding-hd-fstab.html ...

I can not reproduce it - on my 11.2 64b system, mounting 500 GB external USB drive (with vfat fs) is instant, both from CLI via mount(8) and from dolphin.

Anybody who can reproduce this from command line: could you please provide output of 'strace -T mount /dev/sdXn /mnt/mountpoint' ? Dmesg after mount could be also useful.

Also, can anybody reproduce this with other than vfat filesystem?

TIA

I cannot supply feeback to this bug I started as I converted all partitions/disks to ext4

OK, I understand it as it has been quite long time since this has been reported. Anybody else still seeing this issue? G J? Jiri?

Created attachment 371226 [details]
'strace -T mount /dev/sdXn /mnt/mountpoint'

OK, I too converted all my disks to ext4. I had to dig out a spare 80GB disk to
experiment with. Firstly, I'm using openSUSE 11.2 with KDE4.4.4 on a 32 bit
system - Thinkpad X60s.

I formatted the 80GB drive with vfat fs and copied about 50GB of data onto it.
When I mount the drive using dolphin it takes ~18 seconds to mount during which
time my desktop is unusable. This problem was far more severe when I was using
250GB and 500GB disks which would cause close to a 60 second delay.

Mounting the drive using the cli, seems to work much better fine and the
command cursor drops back to ready in ~1.5 seconds.

I ran your trace 'strace -T mount /dev/sdXn /mnt/mountpoint' and have attached
the file.

I'm not sure if this is the part of the dmesg that you require or will be of any help. if you require something more specific let me know.

[26739.720213] usb 1-6.3: new high speed USB device using ehci_hcd and address 9
[26739.806178] usb 1-6.3: New USB device found, idVendor=152d, idProduct=2339
[26739.806205] usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[26739.806224] usb 1-6.3: Product: USB to ATA/ATAPI Bridge
[26739.806238] usb 1-6.3: Manufacturer: JMicron
[26739.806251] usb 1-6.3: SerialNumber: 152D203380B6
[26739.806480] usb 1-6.3: configuration #1 chosen from 1 choice
[26739.809041] scsi8 : SCSI emulation for USB Mass Storage devices
[26739.809345] usb-storage: device found at 9
[26739.809350] usb-storage: waiting for device to settle before scanning
[26741.153292] scsi 8:0:0:0: Direct-Access     HTS54108 0G9SA00               PQ: 0 ANSI: 2 CCS
[26741.153694] sd 8:0:0:0: Attached scsi generic sg1 type 0
[26741.224271] sd 8:0:0:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[26741.225868] sd 8:0:0:0: [sdb] Write Protect is off
[26741.225879] sd 8:0:0:0: [sdb] Mode Sense: 00 38 00 00
[26741.225883] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[26741.226710] usb-storage: device scan complete
[26741.227231] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[26741.227244]  sdb: sdb1
[26741.251735] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[26741.251758] sd 8:0:0:0: [sdb] Attached SCSI disk

Created attachment 371287 [details]
Zipped output after command strace -T mount /dev/sdc1 /mnt/MY_BOOK

After command

strace -T mount /dev/sdc1 /mnt/MY_BOOK

is mounting delay about 45 sec (as described above), during this interval any component of my KDE does not react to any activity of mouse, keyboard etc.

I see just now in specifications of this bug "Hardware: x86-64". I have 32bit system (Intel Pentium IV HT) and the bug is the same...

Created attachment 371289 [details]
Zipped dmesg output after USB HDD mount

This is the whole dmesg output (I don't know what part is important for you).

G J, Jiri: thanks for the logs. However, I can not see anything unusual neither in the straces nor in the kernel logs. Something weird must be happening in mount.

I have built util-linux RPMs with profiling support - Jiri, could you please do the following steps?

- install util-linux*.rpm from http://download.opensuse.org/repositories/home:/puzel:/branches:/openSUSE:/11.2/standard/x86_64/
- run mount /dev/sdXn /mnt/dir (This should create file called gmon.out in the current directory.)
- post the gmon.out file here
- run "df /mnt/dir" and post the output
- reinstall util-linux ("zypper update util-linux" will give you pointers how to recover original util-linux)

Thanks in advance

Petr Uzel: I think the right repository for me is http://download.opensuse.org/repositories/home:/puzel:/branches:/openSUSE:/11.2/standard/i586/ instead of .../x86-64/, isn't it so?

I have 32bit system, see above (https://bugzilla.novell.com/show_bug.cgi?id=566614#c20)

Thanks.

Created attachment 371588 [details]
Installed RPMs from puzel repository

Petr Uzel: well, I have installed util-linux rpms from your repository (see screenshot from YAST), I have restarted the PC after installation, but after command

mount /dev/sdc1 /mnt/MY_BOOK

there is no gmon.out file (anywhere on the whole filesystem). I have only output after command

df /mnt/MY_BOOK

here it is:

Souborový systém      1K blok?   Použité     Volné Uži% P?ipojeno do
/dev/sdc1            488264736 325056480 163208256  67% /mnt/MY_BOOK

Jiri,

> I think the right repository for me is
> http://download.opensuse.org/repositories/home:/puzel:/branches:/openSUSE:/11.2/standard/i586/
> instead of .../x86-64/, isn't it so?

Yes, sorry for not being clear.

> there is no gmon.out file (anywhere on the whole filesystem).
Hm, that's because the 32bit build failed (so the resulting RPM is the old - without profiling support) and I only checked 64bit build. Sorry again :/

I'll let you know once I fix that.

OK, the RPMs with profiling support are fixed now. Could you please retry the 'install, mount, post gmon.out' steps? TIA

Created attachment 371768 [details]
Zipped gmon.out after USB HDD mount

OK, here it is... Second output - after command

df /mnt/MY_BOOK

remains the same.

Jiri, thanks for the info. While mounting with the profiling support (the mount that produced gmon.out) - did it also take 'long' (>10s) time?

Petr Uzel: yes, any way of mounting (standard via "mount", your method with profilling support, automatic or manual mount via device notifier applet) has the same long delay about 45 sec.

Just to be sure I repeat: any older openSUSE distribution (I use it from cca 10.0 version with one exception - 11.1) mounted my external USB disc near instant (several seconds)... Physically on the same PC, the same HDD (and the same USB cable, of course ;-) ).

I had the same problem with my external USB HDD Samsung G3 Station 1 TB, formatted with vfat from the manufacturer. The delay from mount to appearing the Dolphin was 90 s. 

I found the bug 581585 - plasma desktop (KDE4) freezes during the free cluster scan on vfat removable partitions - https://bugzilla.novell.com/show_bug.cgi?id=581585. The workaround described there solved the problem with long delay. If the vfat partition is mounted with the option "usefree" (without scanning the disk), the mount process is almost instant. However I don't know what happens when the trusted value of free clusters is wrong (man mount). Can it damage the filesystem? 

I have openSUSE 11.2 32bit, kernel 2.6.31.12-0.2-default #1 SMP, KDE 4.3.5

I am using the workaround described in bug 581585 since half a year or so.

I had no problems so far and I'm using very often vfat devices.

(In reply to comment #30)
> I found the bug 581585

Thanks! These are clearly duplicates.

*** This bug has been marked as a duplicate of bug 581585 ***