slow sync of fat 32 hotplugged devices
Patrick Fritzsch
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
> 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
Bodo Eggert
> 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.
Andrew Morton
>
> 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...