FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-28-2010, 11:25 AM
Nilesh Govindarajan
 
Default Finally found a solution to slow USB on HAL

I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to
force async file transfer for vfat filesystems by commenting out flush
and sync as valid options from the list.

I checked the thing, now I'm getting the old high speed USB transfer.
Do take a look at it, and comment.

--
Regards,
Nilesh Govindarajan
Facebook: http://www.facebook.com/nilesh.gr
Twitter: http://twitter.com/nileshgr
Website: http://www.itech7.com
Cheap and Reliable VPS Hosting: http://j.mp/arHk5e

--- 20-storage-methods.fdi 2010-06-11 03:17:49.000000000 +0530
+++ /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi 2010-06-28 16:49:52.303623736 +0530
@@ -52,14 +52,14 @@
<!-- allow these mount options for all file systems -->
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
<append key="volume.mount.valid_options" type="strlist">ro</append>
- <append key="volume.mount.valid_options" type="strlist">sync</append>
+ <!--append key="volume.mount.valid_options" type="strlist">sync</append>
<append key="volume.mount.valid_options" type="strlist">dirsync</append>
+ <append key="volume.mount.valid_options" type="strlist">quiet</append-->
+ <append key="volume.mount.valid_options" type="strlist">remount</append>
+ <append key="volume.mount.valid_options" type="strlist">noexec</append>
<append key="volume.mount.valid_options" type="strlist">noatime</append>
<append key="volume.mount.valid_options" type="strlist">nodiratime</append>
<append key="volume.mount.valid_options" type="strlist">relatime</append>
- <append key="volume.mount.valid_options" type="strlist">noexec</append>
- <append key="volume.mount.valid_options" type="strlist">quiet</append>
- <append key="volume.mount.valid_options" type="strlist">remount</append>
<append key="volume.mount.valid_options" type="strlist">exec</append>
<!-- As this is removable media give some leeway -->
<append key="volume.mount.valid_options" type="strlist">utf8</append>
@@ -68,6 +68,7 @@
<append key="volume.mount.valid_options" type="strlist">iocharset=</append>
<append key="volume.mount.valid_options" type="strlist">umask=</append>
<append key="volume.mount.valid_options" type="strlist">uid=</append>
+ <append key="volume.mount.valid_options" type="strlist">async</append>
</match>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
<append key="volume.mount.valid_options" type="strlist">ro</append>
@@ -190,15 +191,15 @@
<!-- allow these mount options for all file systems -->
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux">
<append key="volume.mount.valid_options" type="strlist">ro</append>
- <append key="volume.mount.valid_options" type="strlist">sync</append>
+ <!--append key="volume.mount.valid_options" type="strlist">sync</append>
<append key="volume.mount.valid_options" type="strlist">dirsync</append>
+ <append key="volume.mount.valid_options" type="strlist">quiet</append-->
+ <append key="volume.mount.valid_options" type="strlist">remount</append>
+ <append key="volume.mount.valid_options" type="strlist">exec</append>
<append key="volume.mount.valid_options" type="strlist">noatime</append>
<append key="volume.mount.valid_options" type="strlist">nodiratime</append>
<append key="volume.mount.valid_options" type="strlist">relatime</append>
<append key="volume.mount.valid_options" type="strlist">noexec</append>
- <append key="volume.mount.valid_options" type="strlist">quiet</append>
- <append key="volume.mount.valid_options" type="strlist">remount</append>
- <append key="volume.mount.valid_options" type="strlist">exec</append>
</match>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
<append key="volume.mount.valid_options" type="strlist">ro</append>
@@ -217,7 +218,8 @@
<append key="volume.mount.valid_options" type="strlist">dmask=</append>
<append key="volume.mount.valid_options" type="strlist">fmask=</append>
<append key="volume.mount.valid_options" type="strlist">uid=</append>
- <append key="volume.mount.valid_options" type="strlist">flush</append>
+ <!--append key="volume.mount.valid_options" type="strlist">flush</append-->
+ <append key="volume.mount.valid_options" type="strlist">async</append>
</match>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="FreeBSD">
<append key="volume.mount.valid_options" type="strlist">longnames</append>
@@ -229,7 +231,7 @@
<append key="volume.mount.valid_options" type="strlist">-M=</append>
<append key="volume.mount.valid_options" type="strlist">-L=</append>
<append key="volume.mount.valid_options" type="strlist">-D=</append>
- <append key="volume.mount.valid_options" type="strlist">large</append>
+ <append key="volume.mount.valid_options" type="strlist">large</append>
</match>
</match>
 
Old 06-28-2010, 04:21 PM
Pálffy András Gergely
 
Default Finally found a solution to slow USB on HAL

Works here too. Great, thanks.

On Mon, Jun 28, 2010 at 1:25 PM, Nilesh Govindarajan <lists@itech7.com>wrote:

> I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to force
> async file transfer for vfat filesystems by commenting out flush and sync as
> valid options from the list.
> I checked the thing, now I'm getting the old high speed USB transfer.
> Do take a look at it, and comment.
>
> --
> Regards,
> Nilesh Govindarajan
> Facebook: http://www.facebook.com/nilesh.gr
> Twitter: http://twitter.com/nileshgr
> Website: http://www.itech7.com
> Cheap and Reliable VPS Hosting: http://j.mp/arHk5e
>
>
 
Old 06-28-2010, 04:33 PM
Denis A. Altoé Falqueto
 
Default Finally found a solution to slow USB on HAL

On Mon, Jun 28, 2010 at 1:21 PM, Pálffy András Gergely
<pagesailor@gmail.com> wrote:
> Works here too. Great, thanks.
>
> On Mon, Jun 28, 2010 at 1:25 PM, Nilesh Govindarajan <lists@itech7.com>wrote:
>
>> *I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to force
>> async file transfer for vfat filesystems by commenting out flush and sync as
>> valid options from the list.
>> I checked the thing, now I'm getting the old high speed USB transfer.
>> Do take a look at it, and comment.

Yes, but you should keep in mind that you'll spend extra time when you
want to unmount your USB stick. So I prefer a "slow" transfer and a
fast unmount, because usually I'm in hurry for taking off the USB
drive and the unmounting visualizations are not very smart (only in
KDE SC 4.4 it is really usable).

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-28-2010, 08:52 PM
Philipp Überbacher
 
Default Finally found a solution to slow USB on HAL

Excerpts from Denis A. Altoé Falqueto's message of 2010-06-28 18:33:30 +0200:
> On Mon, Jun 28, 2010 at 1:21 PM, Pálffy András Gergely
> <pagesailor@gmail.com> wrote:
> > Works here too. Great, thanks.
> >
> > On Mon, Jun 28, 2010 at 1:25 PM, Nilesh Govindarajan <lists@itech7.com>wrote:
> >
> >> *I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to force
> >> async file transfer for vfat filesystems by commenting out flush and sync as
> >> valid options from the list.
> >> I checked the thing, now I'm getting the old high speed USB transfer.
> >> Do take a look at it, and comment.
>
> Yes, but you should keep in mind that you'll spend extra time when you
> want to unmount your USB stick. So I prefer a "slow" transfer and a
> fast unmount, because usually I'm in hurry for taking off the USB
> drive and the unmounting visualizations are not very smart (only in
> KDE SC 4.4 it is really usable).

Actually I was recently wondering a bit about the unmounting part,
especially with USB sticks. I do have udev rules, taken from the wiki,
in place that handle automatic mounting. There's also a unmounting part,
which afair removes created dirs, but I guess this is only called after
the usb drive is removed. It did happen more than once to me that a file
transfer seemed to be complete, but when I just removed the drive, the
data was gone. Is there a way to provide automatic safe removal? Manual
unmounting is a bit of a PITA, as you need to have a terminal ready,
guess sdN and type a line, where the device guessing part is the most
problematic. I tend to use /dev/sdN to make sure that I remove the
device from all mount points. Thanks for any advice.
--
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
 
Old 06-28-2010, 10:09 PM
Denis A. Altoé Falqueto
 
Default Finally found a solution to slow USB on HAL

On Mon, Jun 28, 2010 at 5:52 PM, Philipp Überbacher
<hollunder@lavabit.com> wrote:
> Actually I was recently wondering a bit about the unmounting part,
> especially with USB sticks. I do have udev rules, taken from the wiki,
> in place that handle automatic mounting. There's also a unmounting part,
> which afair removes created dirs, but I guess this is only called after
> the usb drive is removed. It did happen more than once to me that a file
> transfer seemed to be complete, but when I just removed the drive, the
> data was gone. Is there a way to provide automatic safe removal? Manual
> unmounting is a bit of a PITA, as you need to have a terminal ready,
> guess sdN and type a line, where the device guessing part is the most
> problematic. I tend to use /dev/sdN to make sure that I remove the
> device from all mount points. Thanks for any advice.

Well, automounting is really easy, but auto-unmounting (!?) is
complex, because what triggers the event is the removal of the device,
but after you take it, the S.O. can't do anything about it anymore. I
use KDE, so I can mount and unmount easily. Gnome and XFCE also offer
good services for that. But without those, I fear that you'll need to
issue unmount manually.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------
 
Old 06-28-2010, 10:27 PM
Philipp Überbacher
 
Default Finally found a solution to slow USB on HAL

Excerpts from Denis A. Altoé Falqueto's message of 2010-06-29 00:09:11 +0200:
> On Mon, Jun 28, 2010 at 5:52 PM, Philipp Überbacher
> <hollunder@lavabit.com> wrote:
> > Actually I was recently wondering a bit about the unmounting part,
> > especially with USB sticks. I do have udev rules, taken from the wiki,
> > in place that handle automatic mounting. There's also a unmounting part,
> > which afair removes created dirs, but I guess this is only called after
> > the usb drive is removed. It did happen more than once to me that a file
> > transfer seemed to be complete, but when I just removed the drive, the
> > data was gone. Is there a way to provide automatic safe removal? Manual
> > unmounting is a bit of a PITA, as you need to have a terminal ready,
> > guess sdN and type a line, where the device guessing part is the most
> > problematic. I tend to use /dev/sdN to make sure that I remove the
> > device from all mount points. Thanks for any advice.
>
> Well, automounting is really easy, but auto-unmounting (!?) is
> complex, because what triggers the event is the removal of the device,
> but after you take it, the S.O. can't do anything about it anymore. I
> use KDE, so I can mount and unmount easily. Gnome and XFCE also offer
> good services for that. But without those, I fear that you'll need to
> issue unmount manually.

That's what I thought. At this time I still use XFCEs thunar in case I
want a graphical file manager, which uses HAL for mounting/unmounting,
but I never managed to configure it correctly, so all I get is an error.
But since HAL is gradually becoming unnecessary I don't want to bother
with it. Mounting works well with udev alone.
I was hoping that the device could, when inactive, be put into a state
that prevents data loss. Not sure, kind of mount-on-demand maybe. I know
far to little of what's going on to see a solution, I'm not even sure
what causes the data loss when the writing is apparently finished.
Indications for being finished is with my usb stick for example a
differently glowing light and the indication in software of course.
--
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
 
Old 06-28-2010, 11:18 PM
Dave Reisner
 
Default Finally found a solution to slow USB on HAL

On Mon, Jun 28, 2010 at 07:09:11PM -0300, Denis A. Altoé Falqueto wrote:
> On Mon, Jun 28, 2010 at 5:52 PM, Philipp Überbacher
> <hollunder@lavabit.com> wrote:
> > Actually I was recently wondering a bit about the unmounting part,
> > especially with USB sticks. I do have udev rules, taken from the wiki,
> > in place that handle automatic mounting. There's also a unmounting part,
> > which afair removes created dirs, but I guess this is only called after
> > the usb drive is removed. It did happen more than once to me that a file
> > transfer seemed to be complete, but when I just removed the drive, the
> > data was gone. Is there a way to provide automatic safe removal? Manual
> > unmounting is a bit of a PITA, as you need to have a terminal ready,
> > guess sdN and type a line, where the device guessing part is the most
> > problematic. I tend to use /dev/sdN to make sure that I remove the
> > device from all mount points. Thanks for any advice.
>
> Well, automounting is really easy, but auto-unmounting (!?) is
> complex, because what triggers the event is the removal of the device,
> but after you take it, the S.O. can't do anything about it anymore. I
> use KDE, so I can mount and unmount easily. Gnome and XFCE also offer
> good services for that. But without those, I fear that you'll need to
> issue unmount manually.
>
Not entirely true. You can assign the results of a blkid call to the
sysfs node that correlates to the flash drive. A snip from my mounted
flash drive..

...
E: SUBSYSTEM=block
E: DEVNAME=sde1
E: ID_FS_LABEL=Flashy
E: ID_FS_LABEL_ENC=Flashy
E: ID_FS_UUID=6E1B5F1E742ED9F4
E: ID_FS_UUID_ENC=6E1B5F1E742ED9F4
E: ID_FS_TYPE=ntfs
E: ID_FS_USAGE=filesystem
...

The ID_FS_xxxx info is from blkid. On the REMOVE event, this information
is still accessible, so I know where the drive is mounted because I
always mount by label. When I remove the drive (without calling umount),
the mount point is destroyed as well.

Ensure that you're mounting the flash drive with 'sync' if you want to
be able to remove it without calling umount. This will slow down
transfers, but data is written synchronously to disk rather than to an
intermediate buffer.

As always, the Arch Wiki has examples of this on the Udev page.

/dave
 
Old 06-29-2010, 12:11 AM
Javier Vasquez
 
Default Finally found a solution to slow USB on HAL

On 6/28/10, Dave Reisner <d@falconindy.com> wrote:
> On Mon, Jun 28, 2010 at 07:09:11PM -0300, Denis A. Altoé Falqueto wrote:
>> On Mon, Jun 28, 2010 at 5:52 PM, Philipp Überbacher
>> <hollunder@lavabit.com> wrote:
>> > Actually I was recently wondering a bit about the unmounting part,
>> > especially with USB sticks. I do have udev rules, taken from the wiki,
>> > in place that handle automatic mounting. There's also a unmounting part,
>> > which afair removes created dirs, but I guess this is only called after
>> > the usb drive is removed. It did happen more than once to me that a file
>> > transfer seemed to be complete, but when I just removed the drive, the
>> > data was gone. Is there a way to provide automatic safe removal? Manual
>> > unmounting is a bit of a PITA, as you need to have a terminal ready,
>> > guess sdN and type a line, where the device guessing part is the most
>> > problematic. I tend to use /dev/sdN to make sure that I remove the
>> > device from all mount points. Thanks for any advice.
>>
>> Well, automounting is really easy, but auto-unmounting (!?) is
>> complex, because what triggers the event is the removal of the device,
>> but after you take it, the S.O. can't do anything about it anymore. I
>> use KDE, so I can mount and unmount easily. Gnome and XFCE also offer
>> good services for that. But without those, I fear that you'll need to
>> issue unmount manually.
>>
> Not entirely true. You can assign the results of a blkid call to the
> sysfs node that correlates to the flash drive. A snip from my mounted
> flash drive..
>
> ...
> E: SUBSYSTEM=block
> E: DEVNAME=sde1
> E: ID_FS_LABEL=Flashy
> E: ID_FS_LABEL_ENC=Flashy
> E: ID_FS_UUID=6E1B5F1E742ED9F4
> E: ID_FS_UUID_ENC=6E1B5F1E742ED9F4
> E: ID_FS_TYPE=ntfs
> E: ID_FS_USAGE=filesystem
> ...
>
> The ID_FS_xxxx info is from blkid. On the REMOVE event, this information
> is still accessible, so I know where the drive is mounted because I
> always mount by label. When I remove the drive (without calling umount),
> the mount point is destroyed as well.
>
> Ensure that you're mounting the flash drive with 'sync' if you want to
> be able to remove it without calling umount. This will slow down
> transfers, but data is written synchronously to disk rather than to an
> intermediate buffer.
>
> As always, the Arch Wiki has examples of this on the Udev page.
>
> /dave

To auto mount/umount usb kind of media without needing even X, you can
use usbmount from debian:

http://packages.debian.org/sid/usbmount

Simple, light and pretty handy. However the umount part is done based
upon removal, and the recommended/default way for mounting is with
"sync" so that there's no data loss...

--
Javier.
 
Old 06-29-2010, 12:14 AM
Ross
 
Default Finally found a solution to slow USB on HAL

On 29/06/10 08:52, Philipp Überbacher wrote:

Excerpts from Denis A. Altoé Falqueto's message of 2010-06-28 18:33:30 +0200:

On Mon, Jun 28, 2010 at 1:21 PM, Pálffy András Gergely
<pagesailor@gmail.com> wrote:

Works here too. Great, thanks.

On Mon, Jun 28, 2010 at 1:25 PM, Nilesh Govindarajan<lists@itech7.com>wrote:


I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to force
async file transfer for vfat filesystems by commenting out flush and sync as
valid options from the list.
I checked the thing, now I'm getting the old high speed USB transfer.
Do take a look at it, and comment.


Yes, but you should keep in mind that you'll spend extra time when you
want to unmount your USB stick. So I prefer a "slow" transfer and a
fast unmount, because usually I'm in hurry for taking off the USB
drive and the unmounting visualizations are not very smart (only in
KDE SC 4.4 it is really usable).


Actually I was recently wondering a bit about the unmounting part,
especially with USB sticks. I do have udev rules, taken from the wiki,
in place that handle automatic mounting. There's also a unmounting part,
which afair removes created dirs, but I guess this is only called after
the usb drive is removed. It did happen more than once to me that a file
transfer seemed to be complete, but when I just removed the drive, the
data was gone. Is there a way to provide automatic safe removal? Manual
unmounting is a bit of a PITA, as you need to have a terminal ready,
guess sdN and type a line, where the device guessing part is the most
problematic. I tend to use /dev/sdN to make sure that I remove the
device from all mount points. Thanks for any advice.


I am no expert and am probably missing something here, but it should be
simple to create a desktop icon and/or menu option to issue the sync
command. That way you could have the speed of asynchronous mount and
clicking the icon or menu option before removing the drive will write
any buffered data to the device to prevent data loss if removing the
device without umounting. As the sync command syncs all mounted drives
you don't need to provide the /dev/sdN.


Ross.
 
Old 06-29-2010, 03:27 AM
Nilesh Govindarajan
 
Default Finally found a solution to slow USB on HAL

On 06/29/2010 05:44 AM, Ross wrote:

On 29/06/10 08:52, Philipp Überbacher wrote:

Excerpts from Denis A. Altoé Falqueto's message of 2010-06-28 18:33:30
+0200:

On Mon, Jun 28, 2010 at 1:21 PM, Pálffy András Gergely
<pagesailor@gmail.com> wrote:

Works here too. Great, thanks.

On Mon, Jun 28, 2010 at 1:25 PM, Nilesh
Govindarajan<lists@itech7.com>wrote:


I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi
to force
async file transfer for vfat filesystems by commenting out flush
and sync as
valid options from the list.
I checked the thing, now I'm getting the old high speed USB transfer.
Do take a look at it, and comment.


Yes, but you should keep in mind that you'll spend extra time when you
want to unmount your USB stick. So I prefer a "slow" transfer and a
fast unmount, because usually I'm in hurry for taking off the USB
drive and the unmounting visualizations are not very smart (only in
KDE SC 4.4 it is really usable).


Actually I was recently wondering a bit about the unmounting part,
especially with USB sticks. I do have udev rules, taken from the wiki,
in place that handle automatic mounting. There's also a unmounting part,
which afair removes created dirs, but I guess this is only called after
the usb drive is removed. It did happen more than once to me that a file
transfer seemed to be complete, but when I just removed the drive, the
data was gone. Is there a way to provide automatic safe removal? Manual
unmounting is a bit of a PITA, as you need to have a terminal ready,
guess sdN and type a line, where the device guessing part is the most
problematic. I tend to use /dev/sdN to make sure that I remove the
device from all mount points. Thanks for any advice.


I am no expert and am probably missing something here, but it should be
simple to create a desktop icon and/or menu option to issue the sync
command. That way you could have the speed of asynchronous mount and
clicking the icon or menu option before removing the drive will write
any buffered data to the device to prevent data loss if removing the
device without umounting. As the sync command syncs all mounted drives
you don't need to provide the /dev/sdN.

Ross.


Yeah exactly !
After copy your data to the drive, run the sync command or setup a
keyboard shortcut for it :-)

This will give you high speed transfer along with no data loss m/

But if you're very forgetful to remove the drive without pressing the
keyboard shortcut for sync, then you're in trouble and this patch is not
for you.


Alternatively, you could write a bash daemon as per this tutorial:
http://j.mp/9DRWOF


which will check for a usb stick's existence and if its mounted, sync
every 15-30 seconds.


--
Regards,
Nilesh Govindarajan
Facebook: http://www.facebook.com/nilesh.gr
Twitter: http://twitter.com/nileshgr
Website: http://www.itech7.com
Cheap and Reliable VPS Hosting: http://j.mp/arHk5e
 

Thread Tools




All times are GMT. The time now is 06:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org