4GB file size limit on SMBFS

4GB file size limit on SMBFS

[Petr Titera]

Hello,

	I tested patches from Urban Wildmark to give SMBFS LFS support and found, 
that limit on file size has only moved from 2GB to 4GB. Is this expected 
behaviour?

Petr Titera
P.Titera@century.cz

Re: 4GB file size limit on SMBFS

[Matti Aarnio]

On Wed, Dec 12, 2001 at 02:22:15PM +0100, Petr Titera wrote:
> Hello,
> 
> 	I tested patches from Urban Wildmark to give SMBFS LFS support and
> found, that limit on file size has only moved from 2GB to 4GB.
> Is this expected behaviour?

  It is a possible behaviour.
  There are no public official documents about how M$ has extended the SMB
  protocol in various systems.  Apparently there are discrepancies even
  within M$ about how to do those extensions, thus newer M$ systems have
  more and more tests and work-arounds to handle various extensions.

> Petr Titera
> P.Titera@century.cz

/Matti Aarnio

Re: 4GB file size limit on SMBFS

[Urban Widmark]

On Wed, 12 Dec 2001, Petr Titera wrote:

> Hello,
> 
> 	I tested patches from Urban Wildmark to give SMBFS LFS support and found, 
> that limit on file size has only moved from 2GB to 4GB. Is this expected 
> behaviour?

I have never tested it vs a NT server with more than 3G of disc, but it's
a 64bit offset so it should be a bit more ... I'll try and dig up a
machine with more space to test with.

It is possible that the readX/writeX SMB is used incorrectly and that
while it does make the low 32 bits be unsigned the top 32 bits are set to
0.

But I have tested it with >4G files on samba servers and that seemed to
work. You did patch smbmount too?

/Urban

Re: 4GB file size limit on SMBFS

[Urban Widmark]

On Fri, 14 Dec 2001, Petr Titera wrote:

> simple
> 	dd if=/dev/zero of=test bs=1024k count=8000
> 
> gives 4GB file on server without any error. I cannot what would whappen 
> if I use real file as my test machine has only 2GB of disk space :( So 
> portions of output file can be rewriten.

The first patch was incomplete. It contained a calculation bug on the
smbfs side limiting the possible offset to 32bits unsigned.

New patch vs 2.4.16 (and others) available here:
    http://www.hojdpunkten.ac.se/054/samba/lfs.html


The annoying thing is that someone pointed that bug out to me some time
ago in an earlier version. I made the change and verified it then, but now
I used an unfixed patch as base for the 2.4.15-pre version ... grr.

I have successfully tested this with a winXP machine someone had. Not the
'dd test' but truncating it to 4.5G (less network transfer time), writing
something above the 4G mark and then checking that it doesn't end up
below. Also works with samba.

(But not with win2k and FAT, which all win2k users around here seems to be
 using, that gives ENOSPC after 4G. Should perhaps be EFBIG ... or not)


Let me know if this works better for you.

/Urban

Re: 4GB file size limit on SMBFS

[Ville Herva]

On Sat, Dec 15, 2001 at 10:02:00PM +0100, you [Urban Widmark] claimed:
> On Fri, 14 Dec 2001, Petr Titera wrote:
> 
> The first patch was incomplete. It contained a calculation bug on the
> smbfs side limiting the possible offset to 32bits unsigned.
> 
> New patch vs 2.4.16 (and others) available here:
>     http://www.hojdpunkten.ac.se/054/samba/lfs.html

BTW: the fsx test Dave Jones just pointed out pretty quickly fails on smbfs
on 2.4.8ac2 (mounting a share from NT4SP6a). I don't have anything never to
play with just now (1), but if you can't immediately reproduce it, I can
compile a newer kernel for the left over box and give it a longer whirl.


-- v --

v@iki.fi

(1) I have a 2.4.16/ia64 on the corner, but fsx fails on IA64 with any fs
    ("mmap: Invalid argument"). Smbfs seems to work on ia64 otherwise...

Re: 4GB file size limit on SMBFS

[Urban Widmark]

On Sat, 15 Dec 2001, Ville Herva wrote:

> BTW: the fsx test Dave Jones just pointed out pretty quickly fails on smbfs

Yes, I saw that too on a more recent (somewhat modified) kernel. I'm not
very surprised considering it has found flaws in fs' that have a lot more
support.

I will be looking into it, others are welcome to join in the fun :)

/Urban