# UMS speed slowdown by factor 20!?

## expose

Hi guys.

my usbstick seems to work fine. i cant see any error messages or anything, but still it just reaches 8 to 16kB/s while it did more than 200 a few days ago.

if you have any idea of what could cause this, a setting i'm not aware of, please tell me  :Smile: 

What i found out is that it seems to be still somewhat faster when i run it not with "sync" as a mount option. so, i copied on file with "sync" and mc said the ETA would be 5 minutes, and things went on slow. when i tried the same and unmounted it, the "umount" process was finished within half a minute or so, which would be normal.

But i cannot see a reason for such a behaviour, and anyway i would like to run the stick "sync"ed so i can remove it without the need to wait for umount to finish.

it also doesnt matter if i'm root or not. a small output by dmesg concerning the stick is:

```
usb 2-1: new full speed USB device using ohci_hcd and address 5

scsi3 : SCSI emulation for USB Mass Storage devices

usb-storage: device found at 5

usb-storage: waiting for device to settle before scanning

  Vendor: iRiver    Model: iFP Mass Driver   Rev: 1.00

  Type:   Direct-Access                      ANSI SCSI revision: 00

SCSI device sda: 256000 512-byte hdwr sectors (131 MB)

sda: Write Protect is off

sda: Mode Sense: 45 00 00 08

sda: assuming drive cache: write through

SCSI device sda: 256000 512-byte hdwr sectors (131 MB)

sda: Write Protect is off

sda: Mode Sense: 45 00 00 08

sda: assuming drive cache: write through

 sda:

Attached scsi removable disk sda at scsi3, channel 0, id 0, lun 0

usb-storage: device scan complete
```

kernel options concerning usb

```
CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB=y

CONFIG_USB_DEVICEFS=y

CONFIG_USB_SUSPEND=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_OHCI_HCD=y

CONFIG_USB_OHCI_LITTLE_ENDIAN=y

CONFIG_USB_UHCI_HCD=y

CONFIG_USB_PRINTER=y

CONFIG_USB_STORAGE=y

CONFIG_USB_HID=y

CONFIG_USB_HIDINPUT=y
```

and finally the line from /etc/fstab

```
/dev/sda                /mnt/ifp        vfat            noauto,users,utf8               0 0
```

so long...

daniel

----------

## aries

Hi Daniel,

Iám afraid I can help you: I have the same problem:

- the device is automounted under KDE at /media

- some weeks ago downloading with normal USB 1.1 speed

- now about 20kb/s

maybe it has to do with a kernel update

----------

## expose

 *Quote:*   

> maybe it has to do with a kernel update

 

I'd also guess so. Let's try it out...

If you find a solution to the problem, please post it here, so i can fix it too...

Do you use OHCI or UHCI, btw?

iirc i tested both, with the same result.

----------

## aries

Hello!

I'm back, sorry for my late answer but last two weeks I was in France for holiday.

The slowdown is caused by the kernel, with kernel 2.6.11 the write speed is > 800k/s.

These links give an explanation  

http://bugme.osdl.org/show_bug.cgi?id=4882 and http://www.spinics.net/lists/usb/msg04174.html

The thing that worked was to change manually fstab:

```
 #  tryout for mp3 player

/dev/sda   /mnt/ext/sda   vfat defaults,rw,umask=0,user,showexec     0 0 
```

At [url]  https://forums.gentoo.org/viewtopic-t-356789-highlight-usb+slowdown.html[/url] I found this

```
          <!-- Use noatime and sync options for all hotpluggable or removable 

                volumes smaller than 2GB --> 

           <match key="volume.size" compare_lt="2147483648"> 

             <match key="@block.storage_device:storage.hotpluggable" bool="true"> 

                                                             <!-- Was true before --> 

               <merge key="volume.policy.mount_option.sync" type="bool">false</merge> 

               <merge key="volume.policy.mount_option.noatime" type="bool">true</merge> 

             </match> 

             <match key="@block.storage_device:storage.removable" bool="true"> 

                                                             <!-- Was true before --> 

               <merge key="volume.policy.mount_option.sync" type="bool">false</merge> 

               <merge key="volume.policy.mount_option.noatime" type="bool">true</merge> 

             </match> 

           </match>  
```

I have tried it, but it did not work.

Maybe it is because I use pmount and kde:/media instead of fstab-sync

I use UHCI:

```
  │ │---   USB Host Controller Drivers                                              │ │

  │ │<M>   EHCI HCD (USB 2.0) support                                               │ │

  │ │[*]     Full speed ISO transactions (EXPERIMENTAL)                             │ │

  │ │[ ]     Root Hub Transaction Translators (EXPERIMENTAL)                        │ │

  │ │<M>   OHCI HCD support                                                         │ │

  │ │<*>   UHCI HCD (most Intel and VIA) support                                    │ │

  │ │< >   SL811HS HCD support    

```

OHCI and EHCI are compiled as a module but are not used.

with 

```
lspci -v 
```

 you can check what usb device you have.

And this is the ouput for the USB devices, search for prog-if to find the type of USB device.:

```

0000:00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02) (prog-if 00 [UHCI])

        Subsystem: Intel Corporation Latitude C640

        Flags: bus master, medium devsel, latency 0, IRQ 11

        I/O ports at bf80 [size=32]

0000:00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #3) (rev 02) (prog-if 00 [UHCI])

        Subsystem: Intel Corporation: Unknown device 4541

        Flags: bus master, medium devsel, latency 0, IRQ 11

        I/O ports at bf20 [size=32]

```

----------

## aries

Hi,

An addition to the previous message:

I switched to fstab-sync instead of pmount and changed the file /usr/share/hal/fdi/90defaultpolicy/storage-policy.fdi 

```

             <!-- Use noatime and sync options for all hotpluggable or removable 

                volumes smaller than 2GB --> 

           <match key="volume.size" compare_lt="2147483648"> 

             <match key="@block.storage_device:storage.hotpluggable" bool="true"> 

                                                             <!-- Was true before --> 

               <merge key="volume.policy.mount_option.sync" type="bool">false</merge> 

               <merge key="volume.policy.mount_option.noatime" type="bool">true</merge> 

             </match> 

             <match key="@block.storage_device:storage.removable" bool="true"> 

                                                             <!-- Was true before --> 

               <merge key="volume.policy.mount_option.sync" type="bool">false</merge> 

               <merge key="volume.policy.mount_option.noatime" type="bool">true</merge> 

             </match> 

           </match>
```

Now this code works and the write speed to my USB flash with kernel 2.6.12 is > 800kb/s .

Conclusion:

Write speed to usb FAT32 storage with -o sync on kernel 2.6.12 is very low 

Question:

Is it possible to change the mount options for pmount?

----------

## expose

Thanks!

Will read it after i got some sleep, although i currently cant test it anyway - my machine is broken  :Neutral: 

----------

## halfgaar

And, note (if not noted already) that with the sync option, you will destroy your USB-flash drive with one large file. Click.

Edit:

BTW, you shouldn't change the default policy, because it will be overridden when hal is updated. The proper place to put it, is in /usr/share/hal/fdi/95userpolicy/ (although, the newer versions of HAL (0.5 or something) use /usr/share/hal/fdi/policy/20thirdparty. And, for those versions, this fix would seem to be unnecessary. Check if you insert a device, if "sync" is part of the mount options (with mount). If not, this fix should not be needed). Create a file name (like storage-policy.fdi), and put this in it:

```
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">

  <device>

      <match key="@block.storage_device:storage.removable" bool="true">

          <merge key="volume.policy.mount_option.sync" type="bool">false</merge>

      </match>

  </device>

</deviceinfo>
```

Last edited by halfgaar on Sun Mar 19, 2006 4:31 pm; edited 3 times in total

----------

## Tarball

I have found this problem myself.

I have added a hal fdi file to mount USB VFAT devices without sync option.  

However, I now need to allow users to mount/umount so the device can be unmounted to maintain data integrity, as the first-post stated without sync option I guess it is dodgy for the user to just pull the device.

I haved played around with the setting but I can't get hal/ivman to mount the device with the 'users' option to no avail.

Anyone solved this?

----------

## halfgaar

Is your problem that the "users" options is not enabled in the fstab, or that ivman mounts it as root? I get the "users" option in fstab, I didn't need to do anything for it. As for ivman, I don't use it. KDE mounts it automaticly by going to media:/. 

However, browsing through this media:/ errors somewhat on Konquerer. It insists on using big icons, I have to set it back to detailed view all the time. It's very annoying. And there were some problems with playing some movies from cd or whatever from the media:/ handle. For some movies, I have to go to /media/cd* manually and open it.

----------

## Matteo Azzali

I have the same issue, but I don't use ivman, pmount nor anything except

KDE media:// directory (I'm using the same storage policy of ivman)...... 

storage-policy.fdi "removing removable sync option"

should works, but what if I unplug the flash drive (for error) whitout unmounting???

(p.s: kernel 2.6.13 , speed below 80kb/sec with sync option)

@halfgaar : could you please post (here, pm) your /etc/fstab (cdroms and usb only) 

and hal storage-policy.fdi ? Thank you.

----------

## halfgaar

HAL puts the following two lines for my cdroms in fstab:

```
dev/hdd                /media/cdrecorder       auto    user,exec,noauto,managed 0 0

/dev/hdc                /media/cdrom            auto    user,exec,noauto,managed 0 0
```

As you can see, the "user" options is enabled. These entries are created by the "50-fstab-sync.hal" device file in "/etc/hal/device.d". That file is a symlink to "/usr/sbin/fstab-sync".

The following is my storage-policy.fdi (the one in the 90defaultpolicy dir). It is a standard file, which comes with hal 0.4.7-r2.

```
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> 

<deviceinfo version="0.2">

  <!-- Default policies merged onto computer root object  -->

  <device>

    <match key="info.udi" string="/org/freedesktop/Hal/devices/computer">

      <merge key="storage.policy.default.mount_root" type="string">/media</merge>

      <merge key="storage.policy.default.use_managed_keyword" type="bool">true</merge>

      <merge key="storage.policy.default.managed_keyword.primary" type="string">managed</merge>

      <merge key="storage.policy.default.managed_keyword.secondary" type="string">kudzu</merge>

      <merge key="storage.policy.default.mount_option.noauto" type="bool">true</merge>

      <merge key="storage.policy.default.mount_option.pamconsole" type="bool">false</merge>

      <merge key="storage.policy.default.mount_option.user" type="bool">true</merge>

      <merge key="storage.policy.default.mount_option.exec" type="bool">true</merge>

    </match>

  </device>

  <device>

    <!-- Whitelist bus types of storage devices we care about  -->

    <match key="info.category" string="storage">

      <match key="storage.bus" string="usb">

   <merge key="storage.policy.should_mount" type="bool">true</merge>      

      </match>

      <match key="storage.bus" string="ide">

   <merge key="storage.policy.should_mount" type="bool">true</merge>

      </match>

      <match key="storage.bus" string="ieee1394">

   <merge key="storage.policy.should_mount" type="bool">true</merge>

      </match>

      <match key="storage.bus" string="sata">

   <merge key="storage.policy.should_mount" type="bool">true</merge>

      </match>

      <match key="storage.bus" string="platform">

   <merge key="storage.policy.should_mount" type="bool">true</merge>

      </match>

    </match>

    <!-- Also add SCSI optical drives -->

    <match key="storage.bus" string="scsi">

      <match key="storage.drive_type" string="cdrom">

        <merge key="storage.policy.should_mount" type="bool">true</merge>

      </match>

    </match>

    <!-- Handle drives with non-partitioned media  -->

    <match key="storage.no_partitions_hint" bool="true">

      <!-- optical drives -->

      <match key="storage.drive_type" string="cdrom">

   <merge key="storage.policy.mount_filesystem" type="string">auto</merge>

   <merge key="storage.policy.desired_mount_point" type="string">cdrom</merge>

   <match key="storage.cdrom.cdr" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.cdrw" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.dvdplusr" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.dvdplusrw" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.dvdram" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.dvdr" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="storage.cdrom.dvdrw" bool="true">

     <merge key="storage.policy.desired_mount_point" type="string">cdrecorder</merge>

   </match>

   <match key="/org/freedesktop/Hal/devices/computer:linux.is_selinux_enabled" bool="true">

     <merge key="storage.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

   </match>

      </match>

      <!-- floppy drives -->

      <match key="storage.drive_type" string="floppy">

   <merge key="storage.policy.mount_filesystem" type="string">auto</merge>

   <merge key="storage.policy.desired_mount_point" type="string">floppy</merge>

   <match key="/org/freedesktop/Hal/devices/computer:linux.is_selinux_enabled" bool="true">

     <merge key="storage.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

   </match>

      </match>

      <!-- zip drives -->

      <match key="storage.drive_type" string="zip">

   <merge key="storage.policy.mount_filesystem" type="string">auto</merge>

   <merge key="storage.policy.desired_mount_point" type="string">zip</merge>

   <match key="/org/freedesktop/Hal/devices/computer:linux.is_selinux_enabled" bool="true">

     <merge key="storage.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

   </match>

      </match>

      <!-- jaz drives -->

      <match key="storage.drive_type" string="jaz">

   <merge key="storage.policy.mount_filesystem" type="string">auto</merge>

   <merge key="storage.policy.desired_mount_point" type="string">jaz</merge>

   <match key="/org/freedesktop/Hal/devices/computer:linux.is_selinux_enabled" bool="true">

     <merge key="storage.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

   </match>

      </match>

    </match>

    <!-- Normal volumes; use volume label, uuid or drive_type -->

    <match key="block.is_volume" bool="true">

      <match key="volume.fsusage" string="filesystem">

   <!-- skip for drives with the no partitions hint (they are handled above) -->

   <match key="@block.storage_device:storage.no_partitions_hint" bool="false">

     <merge key="volume.policy.should_mount" type="bool">true</merge>

     <merge key="volume.policy.mount_filesystem" type="copy_property">volume.fstype</merge>

     

     <!-- Fallback is '<storage.bus>', appended with 'disk', e.g. usbdisk,

          idedisk, scsidisk etc. -->

     <merge key="volume.policy.desired_mount_point" type="copy_property">@block.storage_device:storage.bus</merge>

     <append key="volume.policy.desired_mount_point" type="string">disk</append>

         <!-- zip drives -->

         <match key="storage.drive_type" string="zip">

       <merge key="storage.policy.desired_mount_point" type="string">zip</merge>

         </match>

     

          <!-- Best: If available use filesystem label -->

          <match key="volume.label" empty="false">

            <!-- unless it's a path (e.g. /boot, /, /home etc) -->

            <match key="volume.label" is_absolute_path="false">

         <!-- and only if the label is ascii -->

              <match key="volume.label" is_ascii="true">

      <merge key="volume.policy.desired_mount_point" type="copy_property">volume.label</merge>

              </match>

            </match>

          </match>

     

     <!-- Should never mount Apple Bootstrap partitions (it would be

          a security hole) - should use the bootable flag from the

          Mac partition table instead -->

     <match key="volume.fstype" string="hfs">

       <match key="volume.label" string="bootstrap">

         <merge key="volume.policy.should_mount" type="bool">false</merge>

       </match>

     </match>

     

     <!-- Use selinux mount options for hotpluggable and removable

          volumes -->

     <match key="/org/freedesktop/Hal/devices/computer:linux.is_selinux_enabled" bool="true">

       <match key="@block.storage_device:storage.hotpluggable" bool="true">

         <merge key="volume.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

       </match>

       <match key="@block.storage_device:storage.removable" bool="true">

         <merge key="volume.policy.mount_option.fscontext=system_u:object_r:removable_t" type="bool">true</merge>

       </match>

     </match>

     <!-- Use noatime and sync options for all hotpluggable or removable

          volumes smaller than 2GB -->

     <match key="volume.size" compare_lt="2147483648">

       <match key="@block.storage_device:storage.hotpluggable" bool="true">

         <merge key="volume.policy.mount_option.sync" type="bool">true</merge>

         <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>

       </match>

       <match key="@block.storage_device:storage.removable" bool="true">

         <merge key="volume.policy.mount_option.sync" type="bool">true</merge>

         <merge key="volume.policy.mount_option.noatime" type="bool">true</merge>

       </match>

     </match>

     <!-- Use UTF-8 charset for vfat -->

     <match key="volume.fstype" string="vfat">

       <merge key="volume.policy.mount_option.utf8" type="bool">true</merge>

     </match>

     

     <!-- whitelist of partition table id's, if from a msdos partition table -->

     <match key="volume.partition.msdos_part_table_type" exists="true">

       <!-- Default to no mount and punch holes -->

       <merge key="volume.policy.should_mount" type="bool">false</merge>

       <!-- Linux -->

       <match key="volume.partition.msdos_part_table_type" int="0x83">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- FAT12 -->

       <match key="volume.partition.msdos_part_table_type" int="0x01">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- FAT16 <32M -->

       <match key="volume.partition.msdos_part_table_type" int="0x04">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- FAT16 -->

       <match key="volume.partition.msdos_part_table_type" int="0x06">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- HPFS/NTFS -->

       <match key="volume.partition.msdos_part_table_type" int="0x07">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- W95 FAT32 -->

       <match key="volume.partition.msdos_part_table_type" int="0x0b">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- W95 FAT32 (LBA) -->

       <match key="volume.partition.msdos_part_table_type" int="0x0c">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

       <!-- W95 FAT16 (LBA) -->

       <match key="volume.partition.msdos_part_table_type" int="0x0e">

         <merge key="volume.policy.should_mount" type="bool">true</merge>

       </match>

     </match>     

   </match>

      </match>

    </match>

    

  </device>

  <!-- Dont want to mount non-hotpluggable fixed disks since ideraid

       detection isnt complete as hald wrongly detects e.g. partitions

       from some IDE RAID controllers -->

  <device>

    <match key="storage.hotpluggable" bool="false">

      <match key="storage.removable" bool="false">

   <merge key="storage.policy.should_mount" type="bool">false</merge>

      </match>

    </match>

  </device>

</deviceinfo>

```

I already gave you my storage-policy.fdi which I put in 95userpolicy, which caused the sync option not to be set.

 *Quote:*   

> but I don't use ivman (...snip...) I'm using the same storage policy of ivman

 

So are you using ivman or not?

I'm guessing your problems are because when ivman mounts, it mounts it as root. What happens on my machine, is that only the fstab entry is created, then when going to media:/ in KDE, it is mounted by the user accessing it.

 *Quote:*   

> but what if I unplug the flash drive (for error) whitout unmounting??? 

 

All data which still lingers in the cache is lost. If you pull it out when the cache is being flushed to disk, you will end up with trouble. In any event, filesystem corruption is very likely. With the sync option, I guess ivman would cleanly unmount the drive when you just yank it out, but without sync, this is not possible.

And as long as the sync option behaves too badly, it is simply out of the question to enable it.

 *Quote:*   

> (p.s: kernel 2.6.13 , speed below 80kb/sec with sync option) 

 

I wouldn't benchmark very often. With the sync option, you destroy your flashdrive.Last edited by halfgaar on Sat Feb 11, 2006 11:30 am; edited 1 time in total

----------

## Matteo Azzali

OK, I was thinking to use the ivman recommended storage policy modified only for the sync, but that was givin troubles

(mounting bad, as msdos partition). Also I was thinking (I was wrong) some line in /etc/fstab was needed.

Changed the 95.../storage-policy.fdi, removed any line for usb from fstab, working like a charm.

----------

## Gentree

 *Quote:*   

> However, browsing through this media:/ errors somewhat on Konquerer. It insists on using big icons, I have to set it back to detailed view all the time. It's very annoying.

 

You did choose KDE because it works like windows , right? LOL

Thanks for the info in this post tho' , the rare times I use my usb key I mount it manually but I've past this on to some freinds. This will become more of a issue as drives get bigger and get used for bigger ang bigger files.

Any idea how windows copes with this? I dont see any umount on XP and I have not heard usb devices getting Altzheimered on windows boxes.

 :Cool: 

----------

## halfgaar

 *Quote:*   

> You did choose KDE because it works like windows , right? LOL

 

No, I chose it because of its pleasent windowmanager and rich amount of peripheral apps. But, I'm thinking of switching to XFCE, but that's a different story alltogether...

 *Quote:*   

> Any idea how windows copes with this? I dont see any umount on XP and I have not heard usb devices getting Altzheimered on windows boxes.

 

I believe this is simply a bug in the kernel. But it's possible they don't see it as a bug, because it exists for so long now. With the "sync" option (which effectively disables write-caching, which is disabled for removable media in windows as well), the FAT is updated after each block written. I would guess Windows only updates the FAT after each file-transfer is complete. The fact that you have "lost clusters" in Windows on FAT partitions when resetting your box during copying files kind of confirms that.

You can enable write-caching on windows for removable media BTW. That would force you to software eject everything. It's very possible that for bigger drives, like harddiscs instead of pendrives, windows enables write-cache anyway. Hal on Linux does too. For drives > 2 GB, the sync option is not enabled, even without my hal policy mentioned above.

----------

## Matteo Azzali

 *Gentree wrote:*   

> 
> 
> You did choose KDE because it works like windows , right? LOL
> 
> 

 

LOL. KDE doesn't "works like windows". Instead, Kde is "as easy to manage/customize" as windows,

stable at least as windows (NT and XP, not others) but works like an X Desktop Environment plus

some more services that others doesn't have (ok, and that crap that is arts, I have to admit).....  :Very Happy: 

----------

## halfgaar

I don't want to turn this into a KDE discussion, but I have to say one more thing: most things don't work in KDE  :Smile: . Kmail is unusable for me because of bugs, Kopete doesn't show type notifcations with Jabber, Koquerer has some annoying bugs, Korn (shows popup for new mails) often displays empty popup instead one with sender and subject, Kooka (scan tool) is unusable because of bugs. What I mean by this is, that KDE is far from stable...

----------

## Gentree

I relayed this info to a mate who installed suse 10 for his daughter with a USB device for large daily backups! 

Looks like I got there in time, at least to save some of the life of her stick. So many thanks.

He reports that with sync a large file copy on suse was about half the speed of the same copy on XP. Now it's nearly 4x faster!

I dont use hal on gentoo so it's a bit second-hand but it appears that hal-subfs mounts and unmounts the usb device on demand so the sync is completely unnecessary anyway.

Can you comfirm that is the case ? 

 :Cool: 

----------

## Matteo Azzali

 *halfgaar wrote:*   

> I don't want to turn this into a KDE discussion, but I have to say one more thing: most things don't work in KDE . Kmail is unusable for me because of bugs, Kopete doesn't show type notifcations with Jabber, Koquerer has some annoying bugs, Korn (shows popup for new mails) often displays empty popup instead one with sender and subject, Kooka (scan tool) is unusable because of bugs. What I mean by this is, that KDE is far from stable...

 

That's really strange, konqueror has no bugs here and Kooka is really the better linux option for scanner, my kopete is really fine (but I don't use jabber).

For Kmail I don't use, I share mail with old dos partition so I use thunderbird, Korn never heard about it. (KDE-3.5.1)

Here instead is gnome that's awfully buggy, I tried 3 version from 2.6 to 2.10 and I should have been unlucky, since it was crashing often

and had lots of bugs here and there (oh, and that annoying nautilus...). ~x86 on a Sempron 3100+ rev.E + nforce 3 mobo here...

----------

## halfgaar

 *Quote:*   

> I relayed this info to a mate who installed suse 10 for his daughter with a USB device for large daily backups!
> 
> Looks like I got there in time, at least to save some of the life of her stick. So many thanks. 

 

You did explain the need for creating a rule which doesn't get overwritten on the next system-update, I hope? 

 *Quote:*   

> He reports that with sync a large file copy on suse was about half the speed of the same copy on XP. Now it's nearly 4x faster! 

 

Don't forget the time it takes to unmount the device  :Smile: . When copying to the device itself, the data is copied mainly to cache. It's when you unmount that the cache gets synced to the drive, and that can take a while. When you don't unmount the drive immediatly, this is still an improvement, because the cache-sync happens when the drive is idle.

To determine the real time, do "cp file file && sync".

 *Gentree wrote:*   

> 
> 
> I dont use hal on gentoo so it's a bit second-hand but it appears that hal-subfs mounts and unmounts the usb device on demand so the sync is completely unnecessary anyway.
> 
> Can you comfirm that is the case ? 
> ...

 

Automounting: to some extent. In KDE with media:/ yes, but when I go to the literal path /media/halfgaarusb (the dir created when stick is insterted), it's just a dir, and it's not mounted. But, I believe autmounting can be achieved through ivman or something. There are some notes above which also deal with automounting.

Auto unmounting: yes. When all cached data is synced, an unmount does nothing with the drive itself, so hal can unmount it cleanly after a pull-out.

But, the sync option is very necessary for this, because when the data still only resides in cache, it cannot be synced to the drive after you pull it out.... So, always unmount your drives first  :Smile: 

 *Quote:*   

> That's really strange, konqueror has no bugs here and Kooka is really the better linux option for scanner, my kopete is really fine (but I don't use jabber).
> 
> For Kmail I don't use, I share mail with old dos partition so I use thunderbird, Korn never heard about it. (KDE-3.5.1)
> 
> Here instead is gnome that's awfully buggy, I tried 3 version from 2.6 to 2.10 and I should have been unlucky, since it was crashing often
> ...

 

I don't think the hardware is the cause. My KDE is kind of old BTW, 3.4.1. And korn, it exists under internet menu, under "more apps" here. 

But, we should seize talking about KDE here... You may PM me if you want details  :Smile: 

----------

## Gentree

Do you know the orgin of the sync default? Is it KDE dumbing down the user or is this part of a default hal config.

In either case I think every distro needs to correct this a.s.a.p as a local patch until a permament correction trickles down from "upstream".

Having determined the package responcible a critiical bug report should probably be opened on gentoo.

Thanks again for bringing this to our attention.

 :Cool: 

----------

## halfgaar

 *Quote:*   

> Do you know the orgin of the sync default? Is it KDE dumbing down the user or is this part of a default hal config. 

 

It's HAL which generates the fstab line with the sync enabled. That's why I wrote that HAL rule, which overrides the default.

But, HAL is not the problem. Sync is in theory not a bad idea, because it avoids data-loss when people yank out their drive without unmounting. It gives a more solid feel to it, that when the application is dony copying a file for example, it's also been written do disk, instead of to cache only. 

 *Quote:*   

> In either case I think every distro needs to correct this a.s.a.p as a local patch until a permament correction trickles down from "upstream".
> 
> Having determined the package responcible a critiical bug report should probably be opened on gentoo. 

 

Upstream in this event would be the kernel. Older kernel versions did nothing with sync on vfat, but since 2.6.12 or thereabouts, it does. And it's the implementation of sync in the kernel which is the root of the problem.  (edit: I can't seem to find where I learned which kernel started to do something with sync, but I can remember it was approximately 2.6.12. Anyway, don't trust me fully on it  :Smile: . Edit again: Ah, this was it. Let's see if I can reopen that bug. Edit 3: I commented on it, but I couldn't reopen it. I hope somewil will see it...)

However, they must be aware of the situation, I can't imagine they wouldn't be. I think this is a case of the developers of a program, in this case the kernel, putting the blame somewhere else. I'm not flaming or anything, it just happens a lot.

I just tested if my current kernel (2.6.14-gentoo-r2) perhaps had it fixed, but no. There is a newer one available as stable, 2.6.15-r1. Perhaps that kernel has the sync problem fixed.

There is something else wrong with USB speeds, at least here. My USB 1.1 stick can be written to at only 215 KB/s. This should be around 600-700, and it was in the past.Last edited by halfgaar on Sun Feb 12, 2006 3:41 pm; edited 1 time in total

----------

## Gentree

Well I agree a bit about the buck passing , I was reading some the thread on LKML that you posted and I see Alan Cox blaming it on "shite" flash devices. Like "good" put up with shite threatment, only cheap ones get burntout   :Rolling Eyes: 

There is damn sure a documentation bug since it says the opposite to what happens.

In other respects vfat is non journalling and if you ask for it to be mounted in sync mode it may be necessary to hammer the FAT to comply with that demand. Maybe an intermediate defered syncing policy could be invented to deal with this.

The apparent change around 2.6.12 is , in fact , what makes this relevant, since before that it made no difference to usb devices formatted as vfat since the kernel ignored it.(It could be argued that it was there for iPods with original HFS format).

Now I am aware that it's hal which is doing the job here, my previous question was whether sync for usb was hal defaults or something added by KDE to make it more "user-friendly" .

 :Cool: 

----------

## halfgaar

(I edited my above post at the same time you posted, so you may have missed some)

 *Quote:*   

> Well I agree a bit about the buck passing , I was reading some the thread on LKML that you posted and I see Alan Cox blaming it on "shite" flash devices. Like "good" put up with shite threatment, only cheap ones get burntout

 

I don't remember sending a mail to the Linux mailing list. Can you give the message you are referring to? It wasn't me, but I'd like to see it.

But if he is blaiming cheap flash drives, he should be educated. It is a theoretical issue when flash memory is concerned, no matter how many dollars/euros/etc you gave to the dude selling it.

 *Quote:*   

> There is damn sure a documentation bug since it says the opposite to what happens. 

 

Could you give the document in question? Since the bug was closed with "rejected documented", I'd like to see that doc.

 *Quote:*   

> my previous question was whether sync for usb was hal defaults or something added by KDE to make it more "user-friendly" . 

 

It's still HAL. The rule is specified in HALs default policy.

BTW, this is what I commented on the bug in question:

 *halfgaar at kernel bug stuff wrote:*   

> I think this bug should be reconsidered. Slowness is one thing, but how are you
> 
> going to explain to users that their flash drives will be destroyed after
> 
> writing to it once?
> ...

 

----------

## Gentree

I was refering to you post here linking to the LKML thread. My comment about the doc was taken from the original post in that thread . I assume it has now been corrected since this is about nine months old.

The fault seems to be that there was a small but critical change in kernel policy that was quietly slipped in around 2.6.12 like no-one thought it was that important. Turns out it is.

Since pre 2.6.12 ignores this option for fat32, I'm not sure why the rule is in there in the first place. 

The fact that it did nothing may explain why it was never picked up in testing by hal.

To me it looks like a series of compounded minor errors, a default in communication/documentation in distributed development.

 :Cool: 

----------

## halfgaar

 *Gentree wrote:*   

> Since pre 2.6.12 ignores this option for fat32, I'm not sure why the rule is in there in the first place. 

 

I found this in the kernel bug:

 *Quote:*   

> I don't know what "ignoring the sync option" is supposed to mean. However,
> 
> behaviour of mounting in 2.6.11 with sync is different than mounting in 2.6.12
> 
> without sync. 2.6.11 with sync still writes-as-it-goes, which is pretty much how
> ...

 

and this:

 *Quote:*   

> Old fatfs was not using sync option (MS_SYNCHRONOUS) and O_SYNC at
> 
> all. So, sync option or O_SYNC affects only the user data (VFS is
> 
> synchronizing user data).  In other word, old fatfs is synchronizing
> ...

 

Appearently, sync wasn't completely ignored. It would seem it used to work like it should (or, like I would expect it to). The HAL developers must have thought the same.

----------

## expose

Wow! After a year i finally find the time to read all this and the pages you linked to, kind of a shame, if i am honest (as i've been the one who initially asked).

For me it seems works perfectly now, when simply not using sync.

Thanks for all the notes - especially that one explaining how to quickly kill your (nand) flash pen drive - i always used sync in the past.

Cheers

----------

## expose

Just for completeness:

The problem is present with USB Mass Storage (UMS) Harddisk/Harddrive MP3 Players also. Quick answer: Dont use 'sync', long answer: Read the Thread   :Wink: 

Thanks to all those helpfull posters above.

----------

## halfgaar

This only applies to FAT file systems. 

Some developments have been going on. At least on my system, it's no longer necessary to override hal settings so that it doesn't use sync.

The sync option itself however, if enabled, is still implemented in the slow/destructive wat in the kernel, it seems.

----------

