舒尔sm58:Fedora Core 4.0 HAL设置即插即用移动存储（USB及1394）的实践

提要：对于FedoraCore 4.0 中，普通用户对即插即用支持的比较好；只是适当改一下，就能适合我们的需要；和新手弟兄同学中~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
正文：
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
由于本人思维固化，对新事物接受不足，所以在学习Fedora Core 4.0总是用老思维；对于对移动存储，比如U盘；移动硬盘；数码相机，目前大多能在Linux即插即用；只有少数不行；比如笔记本集成的6合1读卡器（好多都不支持，也有支持的）；
我对Fedora 用的极少，感觉Fedora是实验室，新的特性都会在Fedora 中出现，这增强Linux桌面版的易用性；其实这也是好事；
对即插即用的USB存储的原理，bbbush兄弟已在《设置 fc3 HAL 的 storage-policy自动挂载优盘上的 vfat 分区》中已谈过。大家能去看一下，看过后思路就清晰多了；看过后此文后，功力也会大长；:)
HAL - HardwareAbstraction Layer （硬件提取层），这是我直译的，不知道怎么译才好，以我的理解和视窗系统的硬件管理类似；
而我写的这篇其实一文不值，为什么这样说呢？因为没有技术含量，只是为了解决问题而写，没有原理，只是改几行或加几行的字；可能对新手更有点用；
一、USB移动存储；
数码相机；MMC 卡， SD卡；USB MINI盘；USB移动硬盘（有个USB接口的盒子，里面装的是笔记本硬盘、大计算机硬盘），1394接口的移动存值储；录音笔；DV等，大多都是用的移动存储；
二、fat 、ntfs、fat32、reiserfs 、ext3及hfs文件系统的支持；
Fedora core 4.0几乎支持所有文件系统，所以没有必要编内核，如果你和我相同有一个移动硬盘是NTFS分区的，请安装内核NTFS模块的支持；
内核已支持了fat格式的，无论是 fat16fat32都已支持；对于NTFS格式的文件系统的支持，要安装NTFS的kernel-moduls；我感觉NTFS移动磁盘分区，没有太大的意义（但我有一个移动硬盘，有一个分区就是ntfs的），因为NTFS是不可写的；所以还是用fat或fat32吧；
如果你的机器有1394接口，如果想购买容量比较大的存储设备，建议还是买1394接口的盒子，USB对大文件的写入支持并不好，无论是什么文件系统（以事实说话，我试过）；另外1394接口的硬盘，能在系统启动的过程中稳定的加载；
三、即插即用，系统自动mount 移动存储设备；
1、首先确保 以下的几个服务是打开的；
[root@localhost beinan]# chkconfig --list |grep haldaemon
haldaemon 0:启用 1:启用 2:启用 3:启用 4:启用 5:启用 6:启用
[root@localhost beinan]# chkconfig --list |grep messagebus
messagebus 0:启用 1:启用 2:启用 3:启用 4:启用 5:启用 6:关闭
如果在3和5模式并未启用，则需要打开；
[root@localhost beinan]# chkconfig --level 0123456 haldaemon on
[root@localhost beinan]# chkconfig --level 0123456 messagebus on
在所有模式化全部打开；查看我们所提及的服务是否在所有模式运行；请用前面所说的 chkconfig --list |grep 服务器名；
如果这样做后，我们提到的这些服务，开机自动在所有模式下运行；不用我们人为去干涉了；不过有时为了调试，还得我们自己来打开和关闭；看下一部分；
2、以standalone模式运行的服务，大多是在 /etc/init.d目录中；
用法：
/etc/initrd 服务器 start|stop|status|restart|condrestart
举例：
比如我们要开启 haldaemon 服务器则是：
[root@localhost beinan]# /etc/init.d/haldaemon start
启动 HAL 守护进程： [ 确定 ]
[root@localhost beinan]# /etc/init.d/haldaemon restart
正在关闭 HAL 守护进程： [ 确定 ]
启动 HAL 守护进程： [ 确定 ]
[root@localhost beinan]# /etc/init.d/haldaemon stop
正在关闭 HAL 守护进程： [ 确定 ]
[root@localhost beinan]# /etc/init.d/haldaemon status
hald 已停
这个初学的弟兄都懂；start 启动；restart 重启； stop 停止；status 状态；
我们在本文提到的三个服务器，都在/etc/init.d目录中；
3、其实如果能把上面的几步弄好了，其实移动存储设备大多都是即插即用的，同时也是自动挂载的；
虽然系统即插即用了，但对权限可能不太符合我们的需要；另外如果在fat和ntfs文件系统中存放了文本，对文件名的中文支持不太友好；所以......解决.....
四、解决vfat和ntfs文件系统正常显示中文文件名和文件权限的解决；
1、确认系统的locale ；
[beinan@localhost ~]$ locale
LANG=zh_CN.UTF-8
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=
[beinan@localhost ~]$
如果你的系统编码是gb2312、gbk、gb18030的；就不要改locale；我们只是改hal服务器的一个文件就行；
2、改hal的设置文件；
在Fedora 4.0 中，hal服务器关于移动存储设置文件
/usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi；
在更改之前，请备份；
[root@localhost 10osvendor]# cp 10-storage-policy.fdi 10-storage-policy.fdiBAK
我们打开10-storage-policy.fdi 文件；然后能加下面的两段；



true
true
true
true
true






true
true
true
true
true



加在下面这段的后面；


/media
true
managed
kudzu
true
true
true


注：如果你的系统的编码是gb2312、gbk、gb18030或其他的，请改我们加的那两段中的 utf8的，改为cp936或 gb2312；一步一步的实验，总会行的通的；
3、重启 hal守护程式；
[root@localhost beinan]# /etc/init.d/haldaemon restart
正在关闭 HAL 守护进程： [ 确定 ]
启动 HAL 守护进程： [ 确定 ]
4、插上USB或1394设备；点桌面的计算机就能看到磁盘的图标；
有时可能慢一点出来，是不是挂载了，挂载到哪去了，我们能用 df -lh 来查看；
[root@localhost beinan]# df -lh
Filesystem 容量 已用 可用 已用% 挂载点
/dev/hda8 11G 5.9G 4.5G 58% /
/dev/shm 236M 0 236M 0% /dev/shm
/dev/sdc5 5.2G 63M 4.9G 2% /media/usbdisk2
/dev/sdc1 4.2G 1.4G 2.8G 34% /media/usbdisk1
/dev/sdb1 988M 3.7M 984M 1% /media/usbdisk
/dev/sda1 56G 22G 35G 39% /media/ieee1394disk
5、是不是权限能让普通用户可写的测试；
如果是fat 或 fat32的文件格式，我们在 10-storage-policy.fdi中这个文件中已定义了mount的option ，比如 user 和rw，用户可读可写；
如果是ntfs的分区，我们设置了mount的option 的umask=000 ，这样所有的用户都有所有的权限，但ntfs分区只能在 Linux 下可读；没有太大的意义；
如果是ext3、reiserfs、ext2文件系统，如果能让普通用户拥有可读写的能力，查看挂载点到哪里了，执行一下 chmod -R 777 目录名 ；这样所有的用户就可读可写可
执行；而且每个用户的文件相互独立，相互之间保密；中文支持不存在问题，如果出现乱码，能用export LANG= 来临时设置一下编码；比如export LANG=zh_CN
如果是其他文件格式，一是要支持内核才行；大多FC4已支持了，比如hfs文件系统；
五、关于hal设置文件的学习的几点提示；
1、查看 /usr/share/doc/hal-0.5.2/conf
2、查看hal的包分而在系统的何处，也能打到一点提示的；
[root@localhost beinan]#rpm -ql hal
3、文件在/usr/share/doc/hal-0.5.2/ 的目录；有设置文件的示例；
4、HAL - HardwareAbstraction Layer （硬件提取层），
这是我直译的，还是硬件抽象层？感觉和windows的硬件管理有点类似；我们能通过lshal|more 来查看；
[root@localhost beinan]#lshal |more
更有一个更为直观的工具； hal-gnome，能通过apt 或 yum 获取；安装完成后，有一个更为直观的hal图像界面；
[root@localhost beinan]#hal-device-manager
5、hal设置硬件较为灵活；而且语法也比较简单
我们应该根据 lshal 或hal-device-manager 来查看系统的设备；hal 能管理所有的设备；而且结构清晰清了；我也是为了解决问题，看了man 才找到hal；后来又找到bbbush 兄弟的帖子，通过bbbush兄弟的帖子（一个大大的精华），我却没有发现，浪费了我好多的时间；:(
目前我也只是在实践中即插USB ；1394移动存储设备而用hal ，更直接的说是为了解决问题而做一些测试和实践；更多的就不懂了:(
如果想指定一个设备以 开头，以结层，和html语法类似；匹配，如果想要把设置更精确的区配，应该在多次匹配；在这里面放上我们对设备所指行的动作，比如是否加载，如果是，就true ，是否关系是逻辑关系bool 型；也就是1和0,通过lshal能得到；另外string 是字符串，比如mout_root （挂载点） /media ，这也在lshal中能找到；所有的条件信息，都能在 lshal中得到；
一个条件一行，是我们要未系统执行我们的动作的合集；而 是我们需求系统匹配硬件更为精确，应该是交集，比如有些设备，有些参数是相同的，这种情况下要多次匹配；不过说越精确越好；比如移动存储，我们能找到所有的移动存储的相同信息来 ，这样共性的设备就能动起来了；
我只是说一点点原理，其实系统默认的设置文件足能让我们的设备动起来；没有必要改动的太多；
后记：为新手而写；和新手弟兄同学，希望能和弟兄们交流；
Bug 105871 - High speed usb storage device with low data rates: syncmounts are very slow
FirstLastPrevNext  No search results available
Bug #105871 Overview   —  Thisbug has6duplicates
Opened: 2005-08-19 15:04 UTC Last modified: 2009-06-11 10:52:35 UTC
Classification Product Component Found in Version
openSUSE SUSE Linux 10.1 Hotplug Final
Severity Priority Status Target Milestone for Fix
Major P2 - High RESOLVED ---
Hardware OS Resolution Keywords
All SuSE Linux 10.1 FIXED
ViewBug Activity — FormatFor Printing
Summary: High speed usb storage device with low data rates: sync mounts are very slow
Collapse All Comments -Expand All Comments [reply][-]Description Andreas Schneider 2005-08-19 15:04:11 UTC
I can only copy files to my usb disk with data rates about 100kb/s. It is an
USB
2.0 storage at a usb 2.0 connector.
udev and hald log will follow.
[reply][-]Comment 1 Andreas Schneider 2005-08-19 15:06:17 UTC
Created an attachment (id=46703)[details]
udev log
udev log of the usb attach
[reply][-]Comment 2 Andreas Schneider 2005-08-19 15:07:26 UTC
Created an attachment (id=46704)[details]
hald.log
hald log file
[reply][-]Comment 3 Olaf Kirch 2005-08-19 15:09:33 UTC
This could be the same issue asbug 105798
[reply][-]Comment 4 Greg Kroah-Hartman 2005-08-19 18:21:32 UTC
Can you attach /proc/bus/usb/devices with the device plugged in?
It sounds like you do not have the usb2 host controller driver loaded (ehci-hcd)
and the device is running at usb 1 rates, but need to see that file to make sure
or not.
[reply][-]Comment 5 Andreas Schneider 2005-08-19 18:45:20 UTC
Created an attachment (id=46721)[details]
/proc/bus/usb/devices output
Looks like it is loaded...
horas:~ # lsmod | grep hci
uhci_hcd 36384 0
ohci_hcd 22916 0
ehci_hcd 36744 0
usbcore 140852 7
usb_storage,usbserial,usbhid,uhci_hcd,ohci_hcd,ehci_hcd
[reply][-]Comment 6 Greg Kroah-Hartman 2005-08-19 19:14:18 UTC
Yeah, it's connected, thanks.
Are there _any_ kernel log messages that show up when you plug the device in
and start talking to it?
[reply][-]Comment 7 Andreas Schneider 2005-08-20 11:08:53 UTC
There are no kernel messages during random access.
[reply][-]Comment 8 Olaf Hering 2005-08-22 09:44:11 UTC
please provide the full hwinfo output.
[reply][-]Comment 9 Andreas Schneider 2005-08-22 09:49:09 UTC
Created an attachment (id=46849)[details]
full hwinfo log
Here is the full hwinfo log
[reply][-]Comment 10 Vojtech Pavlik 2005-08-22 15:12:14 UTC
According to the logs and other info, the device is operating correctly at
480 Mbps (high-speed). It's likely a limitation of the device's flash
memory that it can't handle a faster write rate.
[reply][-]Comment 11 Andreas Schneider 2005-08-22 15:21:25 UTC
It works perfectly under SUSE 9.3 and Windows
[reply][-]Comment 12 Vojtech Pavlik 2005-08-22 15:39:47 UTC
Thanks for that datapoint.
Another possible reason for a speed regression from 9.3 to 10.0 is that
in recent kernels, sync write support was added to the vfat filesystem.
That could slow down writes considerably and is controlled by a mount option.
You can verify that is your case by running:
cat /proc/mounts | grep vfat
If 'sync' is one of the options listed, then it's the case.
[reply][-]Comment 13 Olaf Hering 2005-08-23 14:34:18 UTC
can you post the /proc/mounts output?
Is it also slow if mounted manually?
mount /dev/sdaN /mnt
dd if=/dev/zero of=/mnt/foo bs=1M count=1
[reply][-]Comment 14 Andreas Schneider 2005-08-23 15:03:29 UTC
/dev/sda1 on /media/usbdisk type subfs
(rw,nosuid,nodev,sync,fs=floppyfss,procuid,utf8=true)
I've mounted the device without the sync parameter and hey it's fast as hell :)
[reply][-]Comment 15 Olaf Hering 2005-08-23 15:11:47 UTC
find * -type f -print0 | env -i xargs -0 grep -w MS_SYNCHRONOUS
this finds nothing but nfs, no filesystem forces sync. So it must come from subfs.
grep -r HOTPLUG_MOUNT_SYNC /etc/sysconfig , set it to no or off or whatever.
submount seems to look for some hal flags. Its not a kernel bug.
[reply][-]Comment 16 Andreas Schneider 2005-08-23 15:37:09 UTC
HOTPLUG_MOUNT_SYNC is only valid for HOTPLUG_MOUNT_TYPE=fstab, not for subfs.
[reply][-]Comment 17 Klaus Singvogel 2005-08-26 12:47:10 UTC
Just for information: previously (SuSE 9.3) it took around 10 seconds to copy
my history.dat to my USB-2.0 memory stick; with beta3 it takes now around 120
seconds.
[reply][-]Comment 18 Christoph Thiel 2005-08-27 22:34:51 UTC
Klaus, did you check if the module ehci_hcd was loaded orderly on your box?
[reply][-]Comment 19 Andreas Schneider 2005-08-29 09:11:09 UTC
I found a documentation which describes how to disable the sync mount options
of
a subfs mounted device.
http://portal.suse.de/sdb/de/2005/06/dkukawka_halnosync_html.html
https://bugzilla.novell.com/show_bug.cgi?id=85413#c5
Mounting hotplugged devices without "sync"
-------------------------------------------
If writing to USB storage devices like USB sticks or USB hard drive is
rather slow or if you do not want synchronized writing to these devices,
disable the sync mount option.
1.
Create the directory /usr/share/hal/fdi/policy/95userpolicy:
mkdir -p /usr/share/hal/fdi/policy/95userpolicy/
2.
Create a file with the name nosync.fdi and the following contents:
vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi







type="bool">false





3.
Adjust the line according to
your hardware. Run 'lshal' to retrieve the "volume.uuid" and enter this id
instead of ==UUID==
4.
Finally restart the HAL service with
rchal restart
[reply][-]Comment 20 Kirk Coombs 2005-08-29 17:13:43 UTC
I noticed the same problem with my device.
I tried the manual mount without sync and that seems to do the trick:
- Copying file with normal HAL mount (1.5 MB): 1:06 (plus a few seconds w/
light still blinking on device)
- Copying file with manual mount (1.5 MB): 0:04 (includes copy and umount)
Obviously this default behavior is unacceptable, but we can't mount without
synchronization either or people will pull out their devices and loose their
data. I don't know what 9.3 did, but it seemed to combine speed with data
synchronization quite well (I never manually umounted my devices and I never
lost data).
[reply][-]Comment 21 Adrian Schroeter 2005-09-05 08:15:20 UTC
These might be cause by the wrong USB speed detection. Olaf ?
[reply][-]Comment 22 Olaf Hering 2005-09-05 11:45:44 UTC
no, kernel does everything alright, because manual mounting gives high
performance.
either do not mount with sync or trick mason and axboe into fixing the kernel,
by providing a sync_interval mount option or some other blocklayer tweaks to
sync every N seconds.
[reply][-]Comment 23 Adrian Schroeter 2005-09-06 06:58:40 UTC
we discussed the sync_on_close mode, which would solve this issue in every
case, but this seems to not to be possible according to some irc discussion,
is that right Chris / Jens ?
[reply][-]Comment 24 Chris L Mason 2005-09-06 13:44:37 UTC
Definitely possible, but not 1 week before release. This can actually be coded
without
changing specific filesystems and the patch will be rather small.
I don't think including it right now is a great idea, you'll have to convince
AJ first.
[reply][-]Comment 25 Adrian Schroeter 2005-09-06 14:46:47 UTC
sure, not for 10.0 ... I just got a negative answer some month ago.
However, can we agree that we should do this for 10.1 and close this bug with
LATER now ?
AJ, can you add it to the feature document or shall I ?
[reply][-]Comment 26 Andreas Jaeger 2005-09-06 15:30:47 UTC
Adrian, could you do it, please?
[reply][-]Comment 27 Andreas Jaeger 2005-09-08 12:54:15 UTC
Moving on to 10.1
[reply][-]Comment 28 Adrian Schroeter 2005-09-19 14:12:29 UTC
removing sync seems to workaround this issue, but since we do mount with sync
since quite some time and Andreas said he had not the problem on 9.3, it must
be a more general issue.
Chris, can we figure out somewho which (kernel ?) change did cause the slow
down ? Anything else what could be tested ?
[reply][-]Comment 29 Adrian Schroeter 2005-09-19 15:30:35 UTC
***Bug 114024 has been marked as a duplicate of this bug. ***
[reply][-]Comment 31 Kevin Ivory 2005-09-19 15:40:45 UTC
How do I interpret the SUSE version 10.1?:
SUSE 10.0 is not even public yet and you have already decided there will be no
fast writing to USB devices for this version? That seems quite a show stopper to me.
[reply][-]Comment 32 Pavel Nemec 2005-09-20 08:04:48 UTC
it is very strange,
when i mount in s93 WITH sync speed is about 1.5 Mb/s
on 9.3
trin:/ # cat proc/mounts | grep vfat
/dev/sdb1 /mnt vfat rw,sync,nodiratime,fmask=0022,dmask=0022,codepage=cp437,
iocharset=iso8859-1 0 0
trin:/tmp # ll -h test
-rw-r--r-- 1 root root 20M Sep 20 09:25 test
trin:/tmp # time cp test /mnt/
real 0m11.548s
user 0m0.004s
sys 0m0.225s
so speed about 2MB/s
on 10.0
wintermute:~> cat /proc/mounts | grep vfat
/dev/sdc1 /media/usbdisk vfat rw,sync,nodiratime,nosuid,nodev,uid=10019,gid=100,
fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,utf8 0 0
wintermute:/tmp> ll -h test
-rwxr-xr-x 1 root root 20M 2005-09-20 09:38 test
wintermute:/tmp # time cp test /media/usbdisk/
real 5m32.887s
user 0m0.024s
sys 0m0.944s
60kB/s it is terible
it is realy sync problem?
and make usb sticks under 10 unusable
could someone check extern hard disk via usb (i do not have any)
i tried (manualy cancled)
wintermute:/tmp # dd if=test of=/media/usbdisk/test bs=1024
10223616 bytes (10 MB) copied, 334,656 seconds, 30,5 kB/s
wintermute:/tmp # dd if=test of=/media/usbdisk/test bs=10240
6656000 bytes (6,7 MB) copied, 84,3576 seconds, 78,9 kB/s
and last but realy interesting result with mount without sync
wintermute:/tmp # cat /proc/mounts | grep vfat
/dev/sdc1 /mnt vfat rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,
iocharset=iso8859-1 0 0
wintermute:/tmp # time cp test /mnt/
real 0m0.204s
user 0m0.000s
sys 0m0.128s
wintermute:/tmp # time sync
real 0m10.647s
user 0m0.000s
sys 0m0.040s
speed again on ~2MB/s
[reply][-]Comment 33 Pavel Nemec 2005-09-20 11:51:45 UTC
i borrow usb extern hard disk
on suse 93
trin: mount | grep /dev/sdb1
/dev/sdb1 on /mnt type ext3 (rw)
trin:/tmp # dd if=test of=/mnt/test
40960+0 vstoupivších záznam?
40960+0 vystoupivších záznam?
20971520 bytes (21 MB) copied, 0,497808 seconds, 42,1 MB/s
#since is not neded to run manualy !
with sinc
trin:/tmp # mount | grep /dev/sdb1
/dev/sdb1 on /mnt type ext3 (rw,sync)
trin:/tmp # dd if=test of=/mnt/test #cancled
665600 bytes (666 kB) copied, 4,64604 seconds, 143 kB/s
on suse 10
wintermute:/tmp # mount | grep usbdisk_1
/dev/sdd6 on /media/usbdisk_1 type subfs (rw,nosuid,nodev,sync,fs=ext3)
wintermute:/tmp # dd if=test of=/media/usbdisk_1/test
1754112 bytes (1.8 MB) copied, 57.3608 seconds, 30.6 kB/s
with switching sync of
20971520 bytes (21 MB) copied, 0.637884 seconds, 32.9 MB/s
i do not get it
how is possible that usbstick work great on suse 9.3 while hard drive not?
[reply][-]Comment 34 Martin Sommer 2005-09-26 15:48:18 UTC
I think this should not be moved to 10.1. I moved it back to 10.0. For me it's
a
really critical bug of 10.0 if users need ages to copy some data to their USB
stick which needed only seconds in SL 9.3. The exchange (writing) rate is about
100 time slower than SL 9.3. It should be a high priority to fix this in 10.0.
[reply][-]Comment 35 Juergen Weigert 2005-09-26 16:24:12 UTC
I have two USB-memorysticks here.
One takes 8 seconds for the Megabyte and is
Disk /dev/sda: 1048 MB, 1048576000 bytes
64 heads, 32 sectors/track, 1000 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1000 1023983+ 6 FAT16
Partition 1 has different physical/logical endings:
phys=(998, 63, 32) logical=(999, 63, 31)
The other takes 2 Minutes per megabyte and is
Disk /dev/sda: 260 MB, 260046848 bytes
16 heads, 50 sectors/track, 634 cylinders
Units = cylinders of 800 * 512 = 409600 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 634 253527 b W95 FAT32
Partition 1 has different physical/logical endings:
phys=(990, 15, 50) logical=(633, 14, 4)
Does FAT16 vs FAT32 make that difference?
Both devices write 1MB and umount instantaneously if mounted manually without
'sync' option.
[reply][-]Comment 36 Roland Wolters 2005-10-03 14:44:14 UTC
I see the same problems with an attached usb stick and with an attached usb
hard drive. I do not have problems when I mount a encrypted partition manually
from the same hard drive.
I had no problems with Fedora Core 4.
Should I provide any data, logs or whatever?
[reply][-]Comment 38 Sebastien ROHAUT 2005-10-14 07:15:17 UTC
I have the very same problem with my USB stick on SUSE 10.0, the problem didn't
appeared on SUSE 9.3. Data Transfer rate is about 40 kb/s which is
catastrophic.
I don't want to spend more than 1 hour to transfer 200 Mb on my USB key !
If I can help you to resolve this bug, I can send you all infos you want.
[reply][-]Comment 39 Juergen Weigert 2005-10-14 16:37:49 UTC
I use the workaround shown incomment 19 without any problems for quite a
while. I believe the workaround is correct. As the drive gets unmounted
shortly after every write, all data is synced soon enough.
So, whenever the device stops blinking, I can unplug. This is sufficiently
safe for me. Yes, (Sync_on_close would still be better.)
[reply][-]Comment 40 Sebastien ROHAUT 2005-10-14 19:28:27 UTC
No, it's not a good workaround. I tried it. Ok, when I copy some files it
works. But did you try to copy about 100MB of files in your USB stick ? It
takes via KDE about 15/20 seconds, but... It become impossible to use the SB
stick during sync, one or two minutes... During this time, I'm unable to copy
another file on my usb stick, or I'm unable to refresh the konqueror Window,
and so.
And, this hack works for only one USB stick, and you have to modify this XML
file for every Usb Stick model you wan't to put in your PC ????
Say me if I'm wrong, but in Suse 9.3 sync was enabled, and this was very fast,
over 1 or 2 MB/s...
I expect a patch will soon be distributed because this situation is not
acceptable. Some web sites become to report it, as Slyuni.org or alionet.org...
[reply][-]Comment 41 Danny Kukawka 2005-10-14 20:17:18 UTC
(In reply tocomment #40)
> And, this hack works for only one USB stick, and you have to modify this XML
> file for every Usb Stick model you wan't to put in your PC ????
No, this is not correct. You can change the fdi file to do this for all
USB-storage devices. You need only to replace this line (untested):

with

[reply][-]Comment 42 Sebastien ROHAUT 2005-10-15 06:20:12 UTC
ok, I will try this, thanks. But the sync problem isn't resolved...
[reply][-]Comment 43 Matteo Ceriotti 2005-10-16 10:02:29 UTC
(In reply tocomment #41)
> (In reply tocomment #40)
> No, this is not correct. You can change the fdi file to do this for all
> USB-storage devices. You need only to replace this line (untested):
>
>
>
> with
>
>
>
Thank you very much! This worked well!
maTTeo
[reply][-]Comment 44 Adrian Schroeter 2005-10-17 10:08:37 UTC
***Bug 121985 has been marked as a duplicate of this bug. ***
[reply][-]Comment 45 Klaus Singvogel 2005-10-17 10:22:17 UTC
Will anybody update referenced SDB article that it is relevant for 10.0 either?
[reply][-]Comment 46 Danny Kukawka 2005-10-17 12:15:06 UTC
I take a look at the SDB-articel, but should they not merged to opensuse? or or
is this a misunderstanding? (I can't see actual more than one articles for 10.0
in SDB)
[reply][-]Comment 47 Greg Kroah-Hartman 2005-10-17 16:43:42 UTC
***Bug 128627 has been marked as a duplicate of this bug. ***
[reply][-]Comment 48 Alberto Passalacqua 2005-10-17 18:30:42 UTC
@Holaf Hering: I did the grep -w sync /proc/mounts, and the result is:
/dev/fd0 /media/floppy subfs rw,sync,nosuid,nodev 0 0
/dev/sda1 /media/usbdisk subfs rw,sync,nosuid,nodev 0 0
I tried to disable the sync and seems to be better.
Definetly this bug is serious and I don't thing it can be postponed to 10.1!
[reply][-]Comment 49 Ulrich Windl 2005-10-18 07:23:33 UTC
I know I'll repeat facts, but performance problems sometimes don't show up
clear enough on fast devices. Here are the facts for USB 1 (writing to an USB 2
memory stick with "dd"):
~> time dd if=SUSE-10.0-CDs.wav bs=512 of=/media/USBDISKPRO/xxx
201306 bytes (201 kB) copied, 24,3431 seconds, 8,3 kB/s
real 0m24.811s
user 0m0.000s
sys 0m0.104s
8kB over USB 1.0, that cannot be state of the art!!! Do we want to wait for
reviews to point that out, or do we try to fix that?
The opposite direction runs at virtually full speed:
~> time dd of=/dev/null bs=512 if=/media/USBDISKPRO/xxx
201306 bytes (201 kB) copied, 0,205332 seconds, 980 kB/s
Using traditional mount gives at least 268kB/s, over 30 times the speed of the
new sync mounts:
# time sh -c "dd if=SUSE-10.0-CDs.wav bs=512 of=/mnt/xxx;sync;sync;sync"
393+1 Datensätze ein
393+1 Datensätze aus
201306 bytes (201 kB) copied, 0,008398 seconds, 24,0 MB/s
real 0m0.750s
user 0m0.024s
sys 0m0.044s
Finally here are the results for a floppy disk:
:~> time dd if=SUSE-10.0-CDs.wav bs=512 of=/media/floppy/xxx
201306 bytes (201 kB) copied, 309,856 seconds, 0,6 kB/s
real 5m11.210s
user 0m0.004s
For comparison, using "mcopy" (which also writes synchronously, inclusing the
user's response time to the overwrite question):
~> time mcopy SUSE-10.0-CDs.wav a:xxx
Long file name "xxx" already exists.
a)utorename A)utorename-all r)ename R)ename-all o)verwrite O)verwrite-all
s)kip S)kip-all q)uit (aArRoOsSq): o
real 0m25.421s
user 0m0.004s
sys 0m0.016s
That's about 12 times faster!
[reply][-]Comment 50 Steffen Hanne 2005-10-18 07:39:46 UTC
(In reply tocomment #19)
> I found a documentation which describes how to disable the sync mount options
> of
> a subfs mounted device.
>
>http://portal.suse.de/sdb/de/2005/06/dkukawka_halnosync_html.html
>https://bugzilla.novell.com/show_bug.cgi?id=85413#c5
>
> Mounting hotplugged devices without "sync"
> -------------------------------------------
>
> If writing to USB storage devices like USB sticks or USB hard drive is
> rather slow or if you do not want synchronized writing to these devices,
> disable the sync mount option.
>
> 1.
> Create the directory /usr/share/hal/fdi/policy/95userpolicy:
>
> mkdir -p /usr/share/hal/fdi/policy/95userpolicy/
>
> 2.
> Create a file with the name nosync.fdi and the following contents:
>
> vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi
>
>
>
>
>
>
>
>
> > type="bool">false
>
>
>
>
>
>
> 3.
> Adjust the line according to
> your hardware. Run 'lshal' to retrieve the "volume.uuid" and enter this id
> instead of ==UUID==
>
> 4.
> Finally restart the HAL service with
>
> rchal restart
>
Hi,
I used the settings described incomment 19 and it works! Data rates are now as
high as ever.
One tip: if you looking for the right string for "volume.uuid, you can run
lshal with lshal > /root/lshal_out.txt within a console during the USB-Stick is
mounted and open the Textfile with kwrite /root/lshal_out.txt, Then you can
search within the textfile for the volume,uuid-string according to the
mountpoint of your USB-Stick. These are the outputs for my usb-stick.
>>>>>
volume.mount_point = '/media/usbdisk' (string)
volume.label = '' (string)
volume.uuid = 'E4DE-3250' (string)
<<<<<
Another tip:
If you want to disable sync-option in every usb-device, you can change the
nosync.fdi-file to this:







type="bool">false





Copy the lines above to a texteditor and save the nosync.fdi file to
/usr/share/hal/fdi/policy/95userpolicy
After "rchal restart" the sync option is disabled for every usb-device.
A comment: I used Suse 9.3 before and didnt had the problems with my usb-stick
there. I also find, that this is a very serious bug and should fixed in Suse
10.0.
Greetings
Steffen
[reply][-]Comment 51 Michael Noname 2005-10-19 01:41:31 UTC
I tried the "Another tip" inComment 50 to disable the sync-option. No gain in
speed was achieved and writing to a USB flash drive is still very slow. I
didn't
change the configuration according toComment 19 or SUSE 10.0 Release Notes,
since I hoped thatComment 50's suggestion will allow not to enter the volume
id
of every USB flash memory device I use.
And I couldn't find any mention of USB device problems in SUSE Support
Database.
Was anybody able to to:
1) disable the sync option for all possible USB memory devices;
2) maintain high (nominal) writing speed?
Thanks.
[reply][-]Comment 52 Steffen Hanne 2005-10-19 14:18:09 UTC
(In reply tocomment #51)
> I tried the "Another tip" inComment 50 to disable the sync-option. No gain in
> speed was achieved and writing to a USB flash drive is still very slow.
Sorry, there was a line wrap in the text. I will made my nosync.fdi as an
attachment.
Steffen
[reply][-]Comment 53 Steffen Hanne 2005-10-19 14:20:07 UTC
Created an attachment (id=54777)[details]
nosync.fdi file
[reply][-]Comment 54 Juergen Weigert 2005-10-19 17:45:12 UTC
Steffen's idea work fine for me. Even for the machine, where my previous
attempts failed to remove the sync flag.
[reply][-]Comment 55 Michael Noname 2005-10-19 23:36:42 UTC
I followed the guide in Comments 50, 52, 53, and didn't get the high speed
anyhow. When I hand-mount the USB flash drive with "mount -t vfat ...", I get
very high writing speed. Following the comments of Steffen, I get writing speed
40 KBytes/s.
I think that there are probably different sub-classes of USB devices, and the
nosync.fdi inComment 53 is not effective for my device.
[reply][-]Comment 56 Sebastien ROHAUT 2005-10-20 07:18:50 UTC
THis hack worked correcty for me. Michael, did you :
1 - Put this file in the good directory ?
2 - unplugged/unmounted the usb stick/key/drive BEFORE restart hal ?
3 - restarted HAL (rchal restart) as root after ?
So, if you think you have another subclass of USB device, can you put here the
dmesg logs when you put your device plugged and the hald log ?
[reply][-]Comment 57 Danny Kukawka 2005-10-20 09:14:36 UTC
***Bug 121985 has been marked as a duplicate of this bug. ***
[reply][-]Comment 60 Michael Noname 2005-10-20 21:37:28 UTC
Yes, I did all in Comments 52, 53, 56. I rebooted the PC without the USB flash
drive. I restarted the hal daemon. Didn't work.
Where is the hald's log file? I couldn't find hal.log, hald.log or similar.
When I find it, I will attach that log file, hwinfo and dmesg.
Thanks,
Michael.
(In reply tocomment #56)
> THis hack worked correcty for me. Michael, did you :
> 1 - Put this file in the good directory ?
> 2 - unplugged/unmounted the usb stick/key/drive BEFORE restart hal ?
> 3 - restarted HAL (rchal restart) as root after ?
>
> So, if you think you have another subclass of USB device, can you put here the
> dmesg logs when you put your device plugged and the hald log ?
[reply][-]Comment 61 Danny Kukawka 2005-10-20 21:45:32 UTC
I would prefer to stop this discussion about changing fdi-files. This should
not be discussed in the bugzilla, this is not a support forum. Please discuss
this on openssuse or suse-linux mailinglist so we can concentrate to a solution
of the problem/bug.
Thanks.
[reply][-]Comment 62 Hans Meier 2005-10-21 06:53:08 UTC
Same problem here - write speed of 170kB/s under 10.0, whereas it used to be
5MB/s under 9.3.
Let me recap: It was working with full speed and sync under 9.3, so this should
also be possible under 10.0 without any hacks (e.g. turning off sync). At the
moment, this bug is really more than critical, as most users will use USB
sticks once in a while and with this speed it is just useless.
[reply][-]Comment 63 Matiss Piesins 2005-10-22 12:28:36 UTC
Let me point You to this post on HAL mailinglists:
http://lists.freedesktop.org/archives/hal/2005-October/003596.html
It is, supposedly, not only about the speed of writing, but also about possible
hardware damage....
I'll keep flash-drives away from suse for now :(
[reply][-]Comment 71 Klaus Singvogel 2005-10-27 23:14:17 UTC
The given solution fromcomment#19 doesn't work at my private host at home.
The modification, given incomment#41, doesn't work neither.
If I call "mount", I see this:
/dev/sde1 on /media/KLAUS256 type subfs
(rw,nosuid,nodev,sync,fs=floppyfss,procuid,utf8=true)
I will attache the output of lshal.
I don't know, if this is related, but I connect my usbstick via a multi-in-many
front panel to my Linux box. This is a kind of "usbhub" and only capable of
USB-1.1, whereas my motherboard is USB-2.0?
[reply][-]Comment 72 Klaus Singvogel 2005-10-27 23:21:46 UTC
Oops... After downloading nosync.fdi attachment file and diffing it with mine,
I noticed that mine missed a line. Inserting this missing line fixed problem at
my host. Shame on me. :-(
Sorry for confusion.
[reply][-]Comment 73 Ulrich Windl 2005-10-28 06:29:34 UTC
On the missing line (but slightly off-topic): I had realized that there is a
DTD (Document Type efinition) for such files, but the files themselves don't
specify it. Thus XML validation fails due to lack of that DTD. This all means:
If tthose files would specify the DTD, and if the DTD is well-written, such an
error should have been detected by validating the XML file.
[reply][-]Comment 74 Joe Harmon 2005-10-31 17:04:15 UTC
Here is some testing that was done by another user. I asked for permission to
add it to the bug and he said that would be fine. Below are the results.
----
My first test was with the 250gb hard drive formatted as ReiserFS Copying
a 494mb iso image from my internal HD.
/dev/sda5 on /media/testvol type subfs (rw,nosuid,nodev,sync,fs=reiserfs)
linux:/home/jjennings/temp # time cp smartstart-7.40-0.iso /media/testvol/
real 8m24.695s
user 0m0.132s
sys 1m17.989s
So it took 8 minutes to copy the iso image
Next test is with Sync disabled which took 30 seconds
real 0m30.157s
user 0m0.100s
sys 0m8.233s
Final test, I remounted the drive bypassing subfs(USB sub system), the
copy only took 2 seconds
/dev/sda5 on /media/testvol type reiserfs (rw)
linux:/home/jjennings/temp # time cp smartstart-7.40-0.iso /media/testvol/
real 0m2.638s
user 0m0.044s
sys 0m2.568s
Next I wondered if another Format would work better, plus I am beginning
to hate ReiserFS with a passion.
Same tests but with Ext3 Format
Sync Enabled
real 36m44.669s
user 0m0.008s
sys 0m0.656s
Sync Disabled
real 0m5.890s
user 0m0.076s
sys 0m5.496s
manual Mount (1.9 Seconds to copy 495MBs)
real 0m1.973s
user 0m0.072s
sys 0m1.856s
[reply][-]Comment 75 chaneu misanthrope 2005-11-09 09:40:49 UTC
Hello
I'm using KDE 3.4.2 level b on OpenSuse 10
I've this slow transfer rate problem only from my pc to my usbdrive/microdrive
(copying or moving file at less than 2Mb/s). In the other direction (usbdrive
to my pc) the speed rate is normal (moving at 6Mb/s or copying at 15-16 Mb/s).
On my external usb hard drive the transfer rate are around 80kb/s
My usbdrive is fat32 formated and my pc is reiserFS formated.
Is it possible that there's a link with this other bug : 117945 ?
Also, kdf don't estimate the % of occupation of my usbdrive (seems not
mounted).
I'd no problems at all with ubuntu/kubuntu breezy badger and mandriva 2005.
I hope these details could help you to resolve the usb probs.
Thank you.
[reply][-]Comment 76 Martin Lasarsch 2005-11-09 10:57:55 UTC
***Bug 132831 has been marked as a duplicate of this bug. ***
[reply][-]Comment 77 Danny Kukawka 2005-11-11 17:56:22 UTC
***Bug 132631 has been marked as a duplicate of this bug. ***
[reply][-]Comment 78 Benjamin Xiao 2005-11-12 02:26:51 UTC
This bug also affects my usb 1.1 flash drive. I am getting 30 KB/s and
sometimes it even stalls. I have tried both ports on my computer under Linux it
doesn't work. Funny thing though the first time I installed OpenSuSE 10 the usb
drive worked perfectly, then one day POOF gone. I tried reinstalling OpenSuSE
but that didn't help. I tried my drive under windows, it works perfectly.
[reply][-]Comment 79 marten smidt 2005-11-15 18:15:56 UTC
This bug also affects all my usb storage devices (usb flash disk (usb1.1 and
2.0) and external harddisk (usb2) (opensuse10.0 final on intel centrino
chipset)
Interestingly, if the file system is changed to for example ext3 or
reiser. the transfer rates are normal !! (both on external harddisk as usb
flash device).
I am curenly using an usb flash device with an ext3 file system and this works
fine.
The only thing i noticed on my external hardrive was a temporal lock-up of
konqueror when using the device. It seems that the device is unmounted and
mounted again quickly (This behaviour is similar as found with Suse 9.2).
Notably, the vfat filesystem is not accessible for the user accounts. This was
not the case in suse 9.1, 9.2 and 9.3 !!
In my humble view the problem seems to link to the fat/vfat file system. At
least for the the external devices i tested (both usb1.1 and 2.0 on an Usb2
port).
I hope this info helps to fix the problem.
[reply][-]Comment 81 Stefan Hundhammer 2005-11-22 11:05:50 UTC
If that helps any, I have a (VFAT formatted) USB stick here that shows the very
same problem with 10.0. I get data transfer rates in the order of 150 kB/sec
with 10.0 and sync. On 9.3 and 9.2 without sync it used to be about 13 MB/sec.
My external USB HD on the same machine (formatted with ext2) drops from
normally 20 MB/sec to about 13 MB/sec - i.e. to about 60% of the original
performance, not like 0.1% like the USB stick.
This behaviour makes that USB stick unusable with that system.
[reply][-]Comment 86 Michael Noname 2005-12-02 00:14:41 UTC
It seems that up to now there is no comfortable way to operate the USB flash
drives under 10.0.
I have found that the only adjustment that helps to regain the writing speed is
the one described in the Release Notes (file =
/usr/share/doc/release-notes/RELEASE-NOTES.en.html
In addition, I have found that the following works the best (or doesn't work):
1) Before performing the instructions in Release Notes, create in advance and
change the ownership (not only the read/write/execute mode) of directory
/media/usbdisk to the user who will use the device. If there are several
filesystem types, do the same with, e.g., /media/usbdisk_fat
2) After performing the instructions in Relaese Notes, reboot the computer:
restarting the daemon is not enough.
3) Use reiserfs for highest speed (a modern USB flash drive gives up to 40
MBytes/s maximal writing speed and about 5 MBytes/s sustained speed).
4) For fun, I have tried installing SUSE on the USB flash drive: it began, but
hung after 300 MB was written to the USB drive.
5) Partitioning into more than two or three partitions doesn't work properly.
[reply][-]Comment 87 Ulrich Windl 2005-12-02 07:29:45 UTC
Regardingcomment #86: Please: The issue is about "sync mounts are very slow",
and not: "sync mounts are used by mistake". This all doesn't fix the problem of
slow sync mounts.
[reply][-]Comment 88 Mubashir Cheema 2005-12-02 08:05:34 UTC
Like many others I too have suffered through this bug. It is a very critical
bug. I have several Suse machines and implementing the workaround on all of
them would be very tedious. Also, I recommend Suse to a lot of people. This
bug rather shakes my confidence in Suse. It has been 4 months since it was
submitted and a fix has not yet been released for Suse 10.0?
[reply][-]Comment 89 Juergen Weigert 2005-12-02 10:42:27 UTC
Ulrich, nobody has shown that sync mounts can be as fast as async mounts. I
fear, they can not. We seek to get back to *full* speed, while retaining the
needed safety. I would not care, if the end result is called a sync mount, or a
just-do-it-right mount.
[reply][-]Comment 90 Ulrich Windl 2005-12-02 16:07:03 UTC
Oncomment #89: This report also is not about the fact that sync mounts are
slower than async mounts. THIS REPORT IS ABOUT THE FACT THAT SYNC MOUNTS ARE AT
LEAST FIVE TIMES AS SLOW AS THEY WERE IN SUSE LINUX 9.2 or 9.3. Please put a
floppy into your drive and save a 200kB file to it. Do't use an empty floppy,
but use a heavily used one. The floppy head will move around like crazy while
you wait and wait. Compared to USB the advantage is that you can hear what's
going on.
[reply][-]Comment 91 Danny Kukawka 2005-12-02 16:35:22 UTC
Ulrich, please note:
* sync on 9.x was nearly so fast as async, because this was simply not
implemted as sync. sync worked not in this kernel version. Now its correct
implemented in the kernel from 10.0 and it's slower than "before".
* we work on this issue, but's not so simple as some people maybe think
[reply][-]Comment 92 Ulrich Windl 2005-12-07 07:57:46 UTC
OK, what are the semantics of the "sync" option now? Is it O_DSYNC (data
written syncronously, but not necessarily file attributes), O_SYNC (R_DSYNC
with attributes being written synchromously as well? I'd wish for a O_CSYNC
(sync all file data and attributes when a file is closed).
[reply][-]Comment 93 Jeff Mahoney 2005-12-07 19:05:10 UTC
-osync means that any time on-disk data is changed, it is written immediately.
This applies to data and metadata alike.
We've been experimenting with a few different solutions for this problem,
including the -osync_on_close (your O_CSYNC). The problem is that for a work
load of say, "cp /usr/lib /media/usbdisk" where usbdisk is a flash device, the
performance is still quite a bit worse than with -oasync. Further, in order to
be truly safe, it needs to be also mounted with -odirsync (implied with -osync,
so you wouldn't see it now), so that things like deletes and renames are still
handled safely.
This is an issue we take very seriously, and we're trying to find a workable
solution for all the most common workloads.
[reply][-]Comment 94 Quentin Jackson 2005-12-16 23:25:14 UTC
Obviously I have this problem too, however only on a vfat connected memory
stick and a vfat connected MP3 player. My DVD writer (USB Connected) and my
120GB HDD (USB Connected with ReiserFS) do not experience this problem.
However I have what I believe to be a related problem, so I'm putting it in
here as I think it should be considered WITH the fix for this problem.
What I have noticed from Suse 9.2, 9.3, and now 10, is that externally
connected ReiserFS and NTFS devices (therefore filesystem independant) using
submount continuously sync something with the device, slowing or 'pausing' the
whole system about every 10 seconds or so. I can connect the external HDD
devices via USB or Firewire with the same results. I expect it is something to
do with the sync option. I would point out this has happened on various
hardware and is not in my opinion related to the hardware in any way.
It's interesting that in Suse 10 this seems to only happen if I open a
konqueror window and browse to the drive and leave it open (although I'm sure
there are other things I could open this probably just means it's not actually
mounted until you connect something to it), in previous versions of Suse it
happened after simply connecting the device and then doing nothing.
The fix for me is to use console and cd into a directory and type ls once and
leave the console open, it appears this tricks the drive into thinking it's in
use and therefore doesn't attempt to run this sync option (if that is what is
happening) and therefore runs like you would expect, as I said I only have
performance issues with the VFAT submount connected flash devices. Annoyingly
I have to do this for every submount connected device, so when you have a
USB/Firewire DVD Writer, two USB/Firewire connected Hard Disks, and two vfat
connected USB flash memory devices it's obviously an amazingly large annoyance.
I figured if you are fixing a sync issue of some sort it would be important to
resolve this with it and that it may also be a part of the problem. Obviously
I'll leave that call up to someone who knows more about the technical aspects
of submount.
Thanks!
[reply][-]Comment 95 Michael Stather 2005-12-23 11:52:03 UTC
Please fix this before 10.1!
MP3 players and digital cameras aren´t really usable with SuSE ATM
[reply][-]Comment 96 Christian Boltz 2005-12-30 17:32:26 UTC
***Bug 141106 has been marked as a duplicate of this bug. ***
[reply][-]Comment 99 Jonathon Robison 2006-01-27 20:35:37 UTC
I have done my 95userpolicy.fdi as:
/usr/share/hal/fdi/policy/20thirdparty/95userpolicy.fdi, rather than in the
directory above that, and it seems to work well. Is there a reason folks didn't
place it under 20thirdparty?
[reply][-]Comment 100 marten smidt 2006-01-29 15:23:48 UTC
Increasing the logical sector size in generating the fatfs will increase speed:
LSZ=512 results in ~ 20kb/s
LSZ=4096 results in ~120kb/s
usb1 device on an USB port
Moreover, the speed differences are connect to specific hardware, dpending on
the attached device i recorder between 20 and360kb/s all usb1 devices and all
with fat16.
i hope this info helps
[reply][-]Comment 101 Felix Rommel 2006-02-01 15:32:48 UTC
This bug is still in SUSE 10.1 Beta2. When I wrote on my USB stick the speed
was very bad. Only a few KB/s...
If you want to have some information about my USB stick I can attach more
infos.
[reply][-]Comment 102 Stephan Kulow 2006-02-01 15:41:05 UTC
Felix: KDE? GNOME? /proc/mounts?
[reply][-]Comment 103 Felix Rommel 2006-02-04 00:51:49 UTC
Stephan: Beta3
Right now under Gnome. Copied a 8 MB ZIP file in Nautilus. Stopped after 40 s,
it still showed me 25 minutes...
Same behaviour when copying in Gnome terminal, stopped after more than one
minute.
As a reference: mounted manually without sync: about 10 s. That's also not very
fast but much, much faster than with the sync option.
See attachements.
lsusb -v for my USB stick and the proc-mounts
[reply][-]Comment 104 Felix Rommel 2006-02-04 00:52:34 UTC
Created an attachment (id=66449)[details]
cat /proc/mounts
[reply][-]Comment 105 Felix Rommel 2006-02-04 00:53:34 UTC
Created an attachment (id=66450)[details]
lsusbt -v for my Alcor Micro USB stick
[reply][-]Comment 106 Felix Rommel 2006-02-04 01:12:51 UTC
My Trekstore USB hard disk is very fast but it's NOT mounted with sync option
in Gnome.
Copy 8 MB ZIP without sync: 1-2 sec
with sync (manually mounted): 7 sec
Don't understand why my memory stick IS mounted with sync option but /dev/sda1
IS NOT mounted with sync option although it is formatted with FAT.
Maybe it's because I have also two EXT3 partitions on it? see attachement
proc-mount-trekstore.
Shall I open a bug report that a Stick with one partition is mounted WITH sync
while a USB disk with multiple partitions is mounted WITHOUT sync?
[reply][-]Comment 107 Felix Rommel 2006-02-04 01:13:52 UTC
Created an attachment (id=66451)[details]
cat /proc/mounts for my Trekstore USB hard disk
[reply][-]Comment 108 Chris L Mason 2006-02-04 01:24:44 UTC
SL10.1 has a new mount option for fat, which should get used by default by the
gnome and kde automounting tools. This should use -o flush instead of -o sync,
which will be much faster. -o flush is only available for fat, but it will
start all io immediately without waiting for it to finish. This means you have
to wait for io activity to stop before pulling out the disk/stick (look for the
flashing light).
So, the disk incomment #103 should have been mounted with -o flush. Coolo?
[reply][-]Comment 109 Felix Rommel 2006-02-04 01:44:19 UTC
With my installation I get different mounts with KDE and Gnome. I attached the
/proc/mounts in KDE, too.
In Gnome I had the sync option and in KDE I had no sync and no flush option -
see attachements.
But maybe it's my fault - had problems with Beta3 installation: it stopped
after CD1 because of a LVM problem. So I installed everything by hand from CD2.
I have seen no KDE nor Gnome directories in /etc. As far as I know are there
the default configs for both DE's. So maybe that's why I got these different
results!?
I will wait till next Beta and post bugs then with a clean installed system ;)
[reply][-]Comment 110 Felix Rommel 2006-02-04 01:45:16 UTC
Created an attachment (id=66453)[details]
cat /proc/mounts in KDE
[reply][-]Comment 111 Stephan Kulow 2006-02-04 07:09:14 UTC
The missing flush option in KDE is #145851 - will be fixed with beta4 I assume.
The GNOME default are still sync, but depend on #145851 too. But for KDE this
bug is fixed (as no sync mount anymore :)
[reply][-]Comment 112 Ulrich Windl 2006-02-06 07:30:24 UTC
(In reply tocomment #108)
> SL10.1 has a new mount option for fat, which should get used by default by the
> gnome and kde automounting tools. This should use -o flush instead of -o sync,
[...]
(In reply tocomment #109)
> With my installation I get different mounts with KDE and Gnome.
I think it's poor design, to make the GUI components decide on how the media is
going to be mounted.
[reply][-]Comment 113 Bernd Jantzen 2006-02-07 09:48:26 UTC
Before this problem is definitely fixed with a patch for SUSE 10.0 (hopefully)
or in SUSE 10.1, I suggest to change again the release-notes and add the
possibility to mount ALL usb storage devices without the sync option.
I mean, add what has been suggested above (comments #41 and #50, attachment
"nosync.fdi file") to the release-notes in order to enable "normal" users (who
do not search through bug reports) to use their usb devices with high speed.
I have had the problem of writing speed to usb storage devices on different
computers (PC and notebook) and on different devices (a memory stick and a
compact-flash card in a card reader). By adding a file
/usr/share/hal/fdi/policy/20thirdparty/95-storage-nosync.fdi
with the suggested content







false





and calling "rchal restart" (I did not have to restart the computer!), now my
usb devices are mounted without the sync option and the writing speed is as
fast as experienced under SUSE 9.2 before.
I have also written several MB to the usb memory stick and plugged it off
immediately after its LED stopped blinking. After plugging it in again I
compared the file on the stick with its copy on the hard disk, and they were
identical, so everything was written without problem.
I understand that you want to be sure about data integrity before installing a
patch for every SUSE user. But I really suggest to offer at least this
possibility to everyone by adding the above suggestion for all usb devices to
the release-notes.
[reply][-]Comment 114 Chris L Mason 2006-02-16 00:32:40 UTC
For 10.1, we'll have the flush option. At this point the functionality is more
or less done. This bug has become rather long and difficult to follow, I would
like people to open new bugs for problems they see in the 10.1 betas. Thank
you all for your input, and for helping us work through things.
I know the current solutions are not perfect, but I'll be adding support for
more filesystems to use -o flush in later releases, and we'll be able to fine
tune our subfs-free implementations over time.
[reply][-]Comment 115 Stefan Ziegler 2006-05-12 23:54:36 UTC
In freshly installed SUSE Linux 10.1, the USB flash drive is again mounted with
sync option.
I have tested this on two PCs. FAT partition of the memory stick is mounted
with flush option and has very high write speed. But the reiserfs partition is
mounted with sync option, and has write speed 400 kbytes/s.
This is the output of "mount":
/dev/sdc2 on /media/usbdisk type reiserfs (rw,nosuid,nodev,sync)
/dev/sdc1 on /media/usbdisk-1 type vfat
(rw,nosuid,nodev,noatime,flush,uid=1000,utf8,shortname=lower)
Unmounting and manually mounting the reiserfs partition, as in SUSE Linux 10.0,
allows writing with 20 Mbytes/s.
[reply][-]Comment 116 Stephan Kulow 2006-05-13 06:12:44 UTC
As #114 states: "I'll be adding support more filesystems to use -o flush in
later releases". Later as in after 10.1
So if you use KDE, go into sysinfo:/ and change the mount options for your
stick
[reply][-]Comment 117 Jonathon Robison 2006-11-27 14:42:22 UTC
Silly me, but one would think that KDE's sysinfo:/ for usb sticks would offer
all the options available for the filesystem type on the stick. My stick is
reiserfs, and yet I see no way to do acl and user_xattr (even when messing with
.kde/share/config/mediamanagerrc manually).
Or am I just expecting too much?
I've also tried adding options for acl and user_xattr to the
95-storage-nosync.fdi file under /usr/share/hal/fdi/policy/20thirdparty/ like
this:







type="bool">false
true
type="bool">true





but it doesn't work :-(. Probably since KDE isn't using it?
--Jon Robison
[reply][-]Comment 118 Jeff Mahoney 2006-11-27 15:21:32 UTC
Hi Jonathon -
This is a separate issue than the one for which the bug was originally filed.
Can you open a new bug describing this problem, please?