[Samba] vfat / ftruncate problem
Tom Schaefer
tom at umsl.edu
Thu Apr 10 15:36:38 GMT 2003
I recently added a 60Gig HD to my little linux server at home with the intention of sharing it via Samba to all my PCs which run Windows 98SE. I really want to use vfat file system on it.
The server is running Mandrake 8.1, so kernel 2.4.something, and the Samba that came with it.
Much to my disappointment I quickly discovered poor performance copying files to it, the copy is like slow to get going, and trying to copy big files to it (like 750Meg is the size of the file I keep testing with) just fails outright.
I tried it on a different system on my Lan, also running Mandrake 8.1, same story copying to vfat from Win98SE.
I downloaded, compiled, and installed Samba 2.2.8a, same story.
I installed Mandrake 9.1, also kernel 2.4.something and used the samba it came with it, 2.2.7 I think, same story.
It all works completely fine copying to ext2 or ext3 partitions from Windows Explorer.
Here's a real kicker, it even works completely fine with no delays from Win98SE copying to a Samba shared vfat partition, IF, I just open a DOS command prompt and do the copy from there. But if I just exit the command prompt and attempt the exact same copy in Windows Explorer, it will fail.
I messed with a multitude of samba options and mount options for the vfat partition all to no avail. I finally think I've homed in on the problem when I set Samba to log level 10, (log level 9 was not sufficient) at which point I discovered its hanging up on a ftruncate command.
When I attempt to copy my 750Meg file to the samba shared vfat partition, the last couple things logged are an fallocate IIRC, and then an ftruncate, the server just sits there 90 seconds or so grinding and grinding then I guess something times out and either Samba drops the connection to the Win98SE client or Win98SE drops it itself, Win98SE gives an error for the copy that the resource is no longer available, but the connection restablishes itself right away then, but the copy attempt has been aborted.
I think its the same type of deal copying smaller files to the Samba shared vfat partition that does work except there is a long pause before the copy really gets going, I think Samba is doing the fallocate deal and it just takes quite a while which is where the pause comes in before the copying gets going, but doesn't take so long that the connection times out.
I imagine this could be easily be reproduced by anyone willing to try as I reproduced it on two very different machines running samba (one is a Pentium II system, the other an AMD Duron) two different versions of Mandrake and 3 different versions of Samba.
I did a bunch of googling and saw that in Samba 2.2.1a some kind of fix was added in for the vfat/fallocate bug, but the impression I got from an archived message on some Samba developers list was that what Samba actually does is go ahead and attempt the fallocate on vfat partitions and if it fails, which apparently it always will on vfat, then Samba does something else instead. More of a workaround than a fix. Maybe thats the best Samba can do and this is really something that should be handled by the kernel/file system people. My hunch is that the problem with the workaround Samba has implemented is that with great big files the time it takes for fallocate to fail on a vfat partition is just to long so the Samba workaround doesn't even kick in, something times out before fallocate can return the failure code and the workaround can kick in.
Comments anyone?
Thankyou,
Tom Schaefer
More information about the samba
mailing list