Bug 581585

Created attachment 343649 [details]
workaround to set mount option "usefree" for device notifier mounting vfat devices

The same here with x86_64 openSUSE 11.2 with different KDE versions and on diverse computers.

I experience the same with openSUSE 11.2 on both 32 and 64 bit machines. The same problem is also being discussed here Bug 566614 although under a different bug title.

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

Assigning to HAL maintainer to decide what to do.

It is only a HAL issue if by default the usefree option should be set or if HAL should be modified such that one could configure the default mount options. But the question remains, why can the free cluster scan stress some KDE components that much? Probably users would like to stick to the scan. As long as it just behaving like heavy io in the background and the desktop just responds a little slower, things would be fine. I have already mentioned in the bug report that the disk can actually be read during the scan - only writing is delayed until the scan is finished.

I think the KDE maintainers should look into this issue. If an application has the focus it behaves pretty well during the scan - why does KDE behave so badly? I still think there is an event flooding problem and it might well be, that the vfat free cluster scan reveals a problem on the KDE side.

The Problem is probably solved in OpenSuse 11.3. It seems that the free cluster scan has been reworked. Timing it on both system looks promising:

On 11.2:

linux-nida:/home/rfb # mount -t vfat /dev/sdb1 /mnt;time df -h /dev/sdb1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             233G  169G   65G  73% /mnt

real    0m22.603s
user    0m0.004s
sys     0m0.492s

The same machine with 11.3 and the same disk in identical state:

linux-ioee:/home/rfb # mount -t vfat /dev/sdb1 /mnt;time df -h /dev/sdb1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             233G  169G   65G  73% /mnt

real    0m1.187s
user    0m0.000s
sys     0m0.000s

On 11.3 the scan is 19 times faster. It looks as if the old scan was behaving badly and thus might have been the cause of the problem. With a scan which only lasts a second it is not possible to check how the plasma desktop behaves. Somebody with a huge vfat partition should make a similar test. Of course the scan then lasts longer. But that's not a problem. We already know that during the scan the disk is accessible. df is probably the only type of disk access which has to wait until the scan is over. The new well behaved scan will probably not harm the plasma desktop and we can stick with it (which is good) and don't need to use the usefree option. This means, the default mount options don't need to be changed and HAL doesn't need to be touched for this.

By the way, without the scan we have this:
linux-ioee:/home/rfb # mount -t vfat -o usefree /dev/sdb1 /mnt;time df -h /dev/sdb1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             233G  169G   65G  73% /mnt

real    0m0.025s
user    0m0.000s
sys     0m0.000s

Yes, I can confirm that the vfat HDD mounting in 11.3 is much more faster - it takes only several seconds (WD MyBook 500GB). Test was made via mounting applet in KDE 4.4.4.

I can also confirm that the vfat mounting in 11.3 is about 20 times faster than in 11.2. There are the same tests as in comment #7 with USB HDD Samsung G3 Station 1 TB on the same machine (11.2 installed, 11.3 live CD):

11.2 with the scan:
david@ls01:~> sudo mount -t vfat /dev/sdb1 /mnt/samsung_G3;time df -h /dev/sdb1
Souborový systém  Velikost Užito Volno Uži% Připojeno do
/dev/sdb1             932G   38G  895G   4% /mnt/samsung_G3

real    1m31.777s
user    0m0.000s
sys     0m0.004s


11.2 without the scan:
david@ls01:~> sudo mount -t vfat -o usefree /dev/sdb1 /mnt/samsung_G3;time df -h /dev/sdb1
Souborový systém  Velikost Užito Volno Uži% Připojeno do
/dev/sdb1             932G   38G  895G   4% /mnt/samsung_G3

real    0m0.004s
user    0m0.000s
sys     0m0.000s

11.3 with the scan:
linux@linux:~> sudo mount -t vfat /dev/sdb1 /mnt/samsung_g3;time df -h /dev/sdb1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             932G   38G  895G   4% /mnt/samsung_g3

real    0m4.340s
user    0m0.000s
sys     0m0.000s


11.3 without the scan:
linux@linux:~> sudo mount -t vfat -o usefree /dev/sdb1 /mnt/samsung_g3;time df -h /dev/sdb1
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             932G   38G  895G   4% /mnt/samsung_g3

real    0m0.020s
user    0m0.000s
sys     0m0.000s

Is there really a fix needed for openSUSE 11.2 since it's fixed in 11.3 and since there is a workaround available? Btw. it looks to me like a kernel/mount  and not a HAL bug.

Either we reassign it to Kernel or I tend to close the bug as WONTFIX.

It is definitively not a HAL issue. It is not clear whether it is fixed in 11.3. What we know is that the scan has been reworked such that it goes 20 times faster. My impression is that the freeze still happens. But I have no large vfat partitions to really test that. On mine I now see 2 seconds in maximum. David sees scans of 4-5 seconds. I was hoping that somebody has partitions of a size, that even on 11.3 the scan takes that long that he/she can see whether the freeze occurs. Of course if altogether even on the largest vfat partitions the scan now only takes a few seconds, nobody gets bothered any more and it would be of pure academic interest to figure out whether the kernel generates to many events or whether the plasma desktop can't handle the event flood. Taking into account, that large vfat partitions will disappear anyway, it is OK to close the bug. If the phenomen was really pointing to a general underlying eventhandling issue, the problem will eventually show up elsewere again.

Okay. I close it as WONTFIX.