Hallo,
I checked out suse10 lately and discovered some annoying behaviour in
hotplugging an USB Stick.
It seems that the hal daemon mounts a usbstick in fat32 mode, where
default the sync option ist on. Actually this is a nice behaviour,
because a cp to the stick should last so long until the file was
completly written.
Actually the performance is very bad. A 200 MB file needs around 10
Minutes in sync mode, while it needs around 1 Minute in not synchronous
mode + executing a sync command later.
I guess that the kernel checks after every block of the file, which is
written, if the stick has really written it, which leads to such a big
slowdown. There are already lots of comments of this in the web, where
the solution is always to disable the sync mode in the hal daemon device
files.
Wouldnt it be a nice behaviour, if you could mount a file in a new sync
mode, where it isnt synchronized during writing a file, only when a
close ioctl command was executed on a filehandle?
sync writing to hotplugged devices would be a lot faster then.
greetings,
patrick
On Thu, Dec 15, 2005 at 07:28:09PM +0100, Patrick Fritzsch wrote:
> Hallo,
> I checked out suse10 lately and discovered some annoying behaviour in
> hotplugging an USB Stick.
>
> It seems that the hal daemon mounts a usbstick in fat32 mode, where
> default the sync option ist on. Actually this is a nice behaviour,
> because a cp to the stick should last so long until the file was
> completly written.
This is a HAL issue, just have it mount without sync enabled and your
speed will return.
> Actually the performance is very bad. A 200 MB file needs around 10
> Minutes in sync mode, while it needs around 1 Minute in not synchronous
> mode + executing a sync command later.
>
> I guess that the kernel checks after every block of the file, which is
> written, if the stick has really written it, which leads to such a big
> slowdown. There are already lots of comments of this in the web, where
> the solution is always to disable the sync mode in the hal daemon device
> files.
>
> Wouldnt it be a nice behaviour, if you could mount a file in a new sync
> mode, where it isnt synchronized during writing a file, only when a
> close ioctl command was executed on a filehandle?
> sync writing to hotplugged devices would be a lot faster then.
Yes it would, and I'm pretty sure people are already working on this :)
But if you have some patches that enable this functionality already,
please post them.
thanks,
greg k-h
Patrick Fritzsch <[email protected]> wrote:
> It seems that the hal daemon mounts a usbstick in fat32 mode, where
> default the sync option ist on. Actually this is a nice behaviour,
> because a cp to the stick should last so long until the file was
> completly written.
[...]
> I guess that the kernel checks after every block of the file, which is
> written, if the stick has really written it, which leads to such a big
> slowdown. There are already lots of comments of this in the web, where
> the solution is always to disable the sync mode in the hal daemon device
> files.
The situation is worse: It will update the FAT each time a block is written.
Therefore the FAT area will wear out very quickly.
> Wouldnt it be a nice behaviour, if you could mount a file in a new sync
> mode, where it isnt synchronized during writing a file, only when a
> close ioctl command was executed on a filehandle?
> sync writing to hotplugged devices would be a lot faster then.
IMO it should sync on committed dentry updates, too.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Patrick Fritzsch <[email protected]> wrote:
>
> Wouldnt it be a nice behaviour, if you could mount a file in a new sync
> mode, where it isnt synchronized during writing a file, only when a
> close ioctl command was executed on a filehandle?
> sync writing to hotplugged devices would be a lot faster then.
Yeah, this was discussed recently: `mount -o flush'. It'll sync each file
on the final close(). I forget who was doing that, but it's gone quiet
lately.
It's not completely trivial - some work in each fs will be needed to check
that we sync everything which should be sunc. Such as the superblock...