Bug 121985 - synchronous subfs mounts are very slow when writing to floppy or flash
Summary: synchronous subfs mounts are very slow when writing to floppy or flash
Status: RESOLVED DUPLICATE of bug 105871
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: i686 All
: P5 - None : Normal
Target Milestone: ---
Assignee: Adrian Schröter
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-10 15:08 UTC by Ulrich Windl
Modified: 2005-10-20 09:14 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
/etc/lilo.conf before update (2.40 KB, application/octet-stream)
2005-10-12 06:31 UTC, Ulrich Windl 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2005-10-10 15:08:41 UTC 
Synchronous mounts through subfs (submount) are very slow for floppy disks and
flash devices (like MP3 player). There are significant delays between writes for
USB 1, and the floppy seeks also cause a terrible slowdown.
Mounting the device asynchronous fixes the performance problem (increase of at
least 200%).
Related note: Release notes state how to change to asnc mounts for hotplug
devices, but they do not state how to safely unplug the devices.
Comment 1 Dr. Werner Fink 2005-10-10 15:20:12 UTC 
Problem: asynchronous mounts increase the risk of data loosage due
         to early removed devices.
Comment 2 Danny Al-Gaaf 2005-10-11 14:32:26 UTC 
low write performance with sync and subfs are well know problems (in this case 
the bug is a dublicate). 

What is the goal of the report? To fix the problem with low performance and 
sync, to mount always without sync or to change the release notes?
Comment 3 Ulrich Windl 2005-10-11 14:44:57 UTC 
Maybe it was slow in 9.3, but for 10.0 it even seems slower. Actually it's so
slow that I cannot use it with my Vorbis player: The old 4x CD-ROM where I copy
my Ogg files pauses most of the time waiting for the USB player. With
synchronous mounts, the CD-ROM is mostly busy.
Comment 4 Danny Al-Gaaf 2005-10-11 14:50:04 UTC 
In this case the bug is a duplicate of #105871. This difference between 9.3 and 
10.0 is known. If o.k. for you mark the bug as duplicate of this bug.
Comment 5 Ulrich Windl 2005-10-12 06:31:30 UTC 
Created attachment 53800 [details]
/etc/lilo.conf before update

You can use the lilo.conf to test your code. I know that this lilo.conf is not
the typical user's conf, but anyway...
Comment 6 Ulrich Windl 2005-10-12 06:33:55 UTC 
Comment on attachment 53800 [details]
/etc/lilo.conf before update

Sorry, atatched to wrong bug (bugzilla mis-feature)
Comment 7 Ulrich Windl 2005-10-12 07:15:40 UTC 
(In reply to comment #4)
> In this case the bug is a duplicate of #105871. This difference between 9.3 and 
> 10.0 is known. If o.k. for you mark the bug as duplicate of this bug.

As long as it's unclear what the actual reason is, I'd tend to keep the bug
report as it is. If "sync write" is broken per se, the proper solution is not to
disable sync mounts, but to fix the real problem (maybe too frequent or
unnecessary writes).
Comment 8 Danny Al-Gaaf 2005-10-12 09:34:28 UTC 
I would prefer to set this to duplicate of #105871. This is the same problem 
(extrem slow write with sync, maybe the Summary of the bug should be changed).

@adrian: what do you think?
Comment 9 Adrian Schröter 2005-10-17 10:08:37 UTC 

*** This bug has been marked as a duplicate of 105871 ***
Comment 10 Ulrich Windl 2005-10-20 06:43:22 UTC 
Reopening, because sync writes are about 10 times slower than necessary, and bug #105871 only deals with turning sync writes off, but not with fixing the problem (subfs mounts were sny already in 9.2, but they were not that slow).
Comment 11 Danny Al-Gaaf 2005-10-20 09:14:36 UTC 
Only because the ppl speak about disable sync this bug is not a other than this. I changed the summary of the bug. The bug is assigned to the right person.

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