setting allocation size in cifs/smb3

setting allocation size in cifs/smb3

[Steve French]

I created a patch to cifs.ko to add fallocate FALLOC_FL_KEEP_SIZE
support and did some tests against a Samba server (Samba 4.1.6 on ext4
on Ubuntu) and also a Windows 8.1 server (NTFS file system) and ran
into an obvious problem.  How to tell if the allocation size is
changed?  Neither stat on the Samba server local file system nor the
Windows 8.1 properties show the size on disk changing.

I am sending SMB3 SetInfo level 0x13 (set allocation size) and getting
success back from the Windows server and from Samba server.

If I set the length past the end of file I get no error, but the
properties of the file in Windows Explorer still show the same (e.g.
zero) as the file size.  If I try setting it to a size smaller than
the size of the file, the file shrinks (by the way this is an awkward
behavior to work around since on Linux fallocate can't shrink the file
- so if you have any ideas short of revalidating the file size before
deciding whether to send the fallocate request to Windows ...).

Any ideas why Samba shows success but doesn't actually call ext4 to
update the allocation size?

Also any ideas how to implement the normal fallocate behavior (mode =
0, grow the file if length past end of file,  but don't shrink file
length if you set it shorter than end of file) which is basically the
opposite of how the level 0x19 works.  I think mode=1 (keep size) is
going to be ok - if I can figure out why Samba ignores it and how to
make sure it is working to Windows.


-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Jeremy Allison]

On Fri, Jul 18, 2014 at 01:15:07AM -0500, Steve French wrote:
> I created a patch to cifs.ko to add fallocate FALLOC_FL_KEEP_SIZE
> support and did some tests against a Samba server (Samba 4.1.6 on ext4
> on Ubuntu) and also a Windows 8.1 server (NTFS file system) and ran
> into an obvious problem.  How to tell if the allocation size is
> changed?  Neither stat on the Samba server local file system nor the
> Windows 8.1 properties show the size on disk changing.
> 
> I am sending SMB3 SetInfo level 0x13 (set allocation size) and getting
> success back from the Windows server and from Samba server.
> 
> If I set the length past the end of file I get no error, but the
> properties of the file in Windows Explorer still show the same (e.g.
> zero) as the file size.  If I try setting it to a size smaller than
> the size of the file, the file shrinks (by the way this is an awkward
> behavior to work around since on Linux fallocate can't shrink the file
> - so if you have any ideas short of revalidating the file size before
> deciding whether to send the fallocate request to Windows ...).
> 
> Any ideas why Samba shows success but doesn't actually call ext4 to
> update the allocation size?

smbd does use VFS_FALLOCATE_KEEP_SIZE, which maps
into fallocate FALLOC_FL_KEEP_SIZE if the underlying
storage supports it.

You need to set "strict allocate = true" on the
share in order to get this behavior though.

If you're setting allocation size smaller
than file size we just use ftruncate, I
don't see another possibility here. What
behavior do you expect in the shrink case ?

Jeremy.

Re: setting allocation size in cifs/smb3

[Steve French]

On Fri, Jul 18, 2014 at 12:09 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Fri, Jul 18, 2014 at 01:15:07AM -0500, Steve French wrote:
>> I created a patch to cifs.ko to add fallocate FALLOC_FL_KEEP_SIZE
>> support and did some tests against a Samba server (Samba 4.1.6 on ext4
>> on Ubuntu) and also a Windows 8.1 server (NTFS file system) and ran
>> into an obvious problem.  How to tell if the allocation size is
>> changed?  Neither stat on the Samba server local file system nor the
>> Windows 8.1 properties show the size on disk changing.
>>
>> I am sending SMB3 SetInfo level 0x13 (set allocation size) and getting
>> success back from the Windows server and from Samba server.
>>
>> If I set the length past the end of file I get no error, but the
>> properties of the file in Windows Explorer still show the same (e.g.
>> zero) as the file size.  If I try setting it to a size smaller than
>> the size of the file, the file shrinks (by the way this is an awkward
>> behavior to work around since on Linux fallocate can't shrink the file
>> - so if you have any ideas short of revalidating the file size before
>> deciding whether to send the fallocate request to Windows ...).
>>
>> Any ideas why Samba shows success but doesn't actually call ext4 to
>> update the allocation size?
>
> smbd does use VFS_FALLOCATE_KEEP_SIZE, which maps
> into fallocate FALLOC_FL_KEEP_SIZE if the underlying
> storage supports it.
>
> You need to set "strict allocate = true" on the
> share in order to get this behavior though.
>
> If you're setting allocation size smaller
> than file size we just use ftruncate, I
> don't see another possibility here. What
> behavior do you expect in the shrink case ?

Windows shrinks the file (unlike Linux) when you do the allocate
before end of file, but when I tried the same call to
Samba it seemed to ignore it, return success and leave
file size alone.


-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Jeremy Allison]

On Fri, Jul 18, 2014 at 11:49:04PM -0500, Steve French wrote:
> Windows shrinks the file (unlike Linux) when you do the allocate
> before end of file, but when I tried the same call to
> Samba it seemed to ignore it, return success and leave
> file size alone.

That's a bug - the code does use ftruncate if
the new allocated size is less than file size.

Can you send me a wireshark trace of what
you're sending please ?

Re: setting allocation size in cifs/smb3

[Steve French]

wireshark trace sent to jra

Also related strange behavior to Samba 4.1.9 ... It is not just that I
see the allocation size not set when I send an allocation size of 5.4M
for a 2M file.  I see the file size shrunk when I sent the request for
a MUCH smaller size.  I sent a request to set allocation size to
length 10000 and the file size of the 2M file (and interestingly also
allocation size) was set to 1MB..

On Sat, Jul 19, 2014 at 12:14 AM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Fri, Jul 18, 2014 at 11:49:04PM -0500, Steve French wrote:
>> Windows shrinks the file (unlike Linux) when you do the allocate
>> before end of file, but when I tried the same call to
>> Samba it seemed to ignore it, return success and leave
>> file size alone.
>
> That's a bug - the code does use ftruncate if
> the new allocated size is less than file size.
>
> Can you send me a wireshark trace of what
> you're sending please ?



-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Jeremy Allison]

On Sun, Jul 20, 2014 at 11:47:53PM -0500, Steve French wrote:
> wireshark trace sent to jra

"strict allocate = true" not set in the smb.conf,
so bug report isn't useful :-). No fallocate
calls will be made by smbd unless strict allocate
is set.

This might explain the problem (in case anyone
else is tracking :-).

Re: setting allocation size in cifs/smb3

[Steve French]

What about shrinking the file to the wrong size?

On Mon, Jul 21, 2014 at 1:28 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Sun, Jul 20, 2014 at 11:47:53PM -0500, Steve French wrote:
>> wireshark trace sent to jra
>
> "strict allocate = true" not set in the smb.conf,
> so bug report isn't useful :-). No fallocate
> calls will be made by smbd unless strict allocate
> is set.
>
> This might explain the problem (in case anyone
> else is tracking :-).



-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Jeremy Allison]

On Mon, Jul 21, 2014 at 01:43:12PM -0500, Steve French wrote:
> What about shrinking the file to the wrong size?

In the set allocation path info it's going through:

        if (allocation_size) {
                allocation_size = smb_roundup(conn, allocation_size);
        }

which by default uses 1MB allocation roundup values.

If you need to set the file length, set the file length :-).

It's arguable if the server can mess with allocation
requests on file shrink, but this hasn't caused a
problem in the SMB1/Windows SMB2 code paths so far,
so I'm guessing it might be allowable....

More research needed !

Re: setting allocation size in cifs/smb3

[Steve French]

So depending on the file sizes and with strict allocate enabled in
smb.conf it does shrink the file (I will also experiment with e.g.
allocation roundup size)

What I was trying to do was extend allocation for a 4MB file to 5.4MB,
shrink it to 10K (which ended up shrinking it to 1MB for the Samba
case).

[sfrench@localhost cifs-2.6]$ stat /mnt/test/4M ; fallocate -n -l
5400000 /mnt/test/4M ; sleep 3 ; stat /mnt/test/4M ; fallocate -n -l
10000 /mnt/test/4M ; sleep 2; stat /mnt/test/4M
  File: ‘/mnt/test/4M’
  Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
Device: 26h/38d Inode: 393820      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:19:30.596249500 -0500
Modify: 2014-07-21 14:19:30.731591000 -0500
Change: 2014-07-21 14:19:30.731591000 -0500
 Birth: -

  File: ‘/mnt/test/4M’   (after fallocate 5400000)
  Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
Device: 26h/38d Inode: 393820      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:19:30.596249500 -0500
Modify: 2014-07-21 14:20:17.141270500 -0500
Change: 2014-07-21 14:20:17.141270500 -0500
 Birth: -

  File: ‘/mnt/test/4M’  (after fallocate 10000)
  Size: 1048576   Blocks: 2048       IO Block: 16384  regular file
Device: 26h/38d Inode: 393820      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:19:30.596249500 -0500
Modify: 2014-07-21 14:20:20.157755800 -0500
Change: 2014-07-21 14:20:20.157755800 -0500
 Birth: -

(I will send jra the wireshark trace).

On Mon, Jul 21, 2014 at 1:55 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Mon, Jul 21, 2014 at 01:43:12PM -0500, Steve French wrote:
>> What about shrinking the file to the wrong size?
>
> In the set allocation path info it's going through:
>
>         if (allocation_size) {
>                 allocation_size = smb_roundup(conn, allocation_size);
>         }
>
> which by default uses 1MB allocation roundup values.
>
> If you need to set the file length, set the file length :-).
>
> It's arguable if the server can mess with allocation
> requests on file shrink, but this hasn't caused a
> problem in the SMB1/Windows SMB2 code paths so far,
> so I'm guessing it might be allowable....
>
> More research needed !



-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Steve French]

To Windows 8.1 it appears to round to 4K boundaries when shrinking but
also not extend the allocation size when allocating beyond end of file
as the documentation would imply

[sfrench@localhost cifs-2.6]$ stat /mnt/test/4M ; fallocate -n -l
5400000 /mnt/test/4M ; sleep 3 ; stat /mnt/test/4M ; fallocate -n -l
10000 /mnt/test/4M ; sleep 2; stat /mnt/test/4M
  File: ‘/mnt/test/4M’
  Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
Device: 26h/38d Inode: 1407374883618316  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:36:20.249486200 -0500
Modify: 2014-07-21 14:36:20.389204200 -0500
Change: 2014-07-21 14:36:20.389204200 -0500
 Birth: -
  File: ‘/mnt/test/4M’
  Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
Device: 26h/38d Inode: 1407374883618316  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:36:20.249486200 -0500
Modify: 2014-07-21 14:38:01.677837600 -0500
Change: 2014-07-21 14:38:01.677837600 -0500
 Birth: -
  File: ‘/mnt/test/4M’
  Size: 12288     Blocks: 24         IO Block: 16384  regular file
Device: 26h/38d Inode: 1407374883618316  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:cifs_t:s0
Access: 2014-07-21 14:36:20.249486200 -0500
Modify: 2014-07-21 14:38:04.693266400 -0500
Change: 2014-07-21 14:38:04.693266400 -0500
 Birth: -

On Mon, Jul 21, 2014 at 2:27 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> So depending on the file sizes and with strict allocate enabled in
> smb.conf it does shrink the file (I will also experiment with e.g.
> allocation roundup size)
>
> What I was trying to do was extend allocation for a 4MB file to 5.4MB,
> shrink it to 10K (which ended up shrinking it to 1MB for the Samba
> case).
>
> [sfrench@localhost cifs-2.6]$ stat /mnt/test/4M ; fallocate -n -l
> 5400000 /mnt/test/4M ; sleep 3 ; stat /mnt/test/4M ; fallocate -n -l
> 10000 /mnt/test/4M ; sleep 2; stat /mnt/test/4M
>   File: ‘/mnt/test/4M’
>   Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
> Device: 26h/38d Inode: 393820      Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:cifs_t:s0
> Access: 2014-07-21 14:19:30.596249500 -0500
> Modify: 2014-07-21 14:19:30.731591000 -0500
> Change: 2014-07-21 14:19:30.731591000 -0500
>  Birth: -
>
>   File: ‘/mnt/test/4M’   (after fallocate 5400000)
>   Size: 4194304   Blocks: 8192       IO Block: 16384  regular file
> Device: 26h/38d Inode: 393820      Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:cifs_t:s0
> Access: 2014-07-21 14:19:30.596249500 -0500
> Modify: 2014-07-21 14:20:17.141270500 -0500
> Change: 2014-07-21 14:20:17.141270500 -0500
>  Birth: -
>
>   File: ‘/mnt/test/4M’  (after fallocate 10000)
>   Size: 1048576   Blocks: 2048       IO Block: 16384  regular file
> Device: 26h/38d Inode: 393820      Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:cifs_t:s0
> Access: 2014-07-21 14:19:30.596249500 -0500
> Modify: 2014-07-21 14:20:20.157755800 -0500
> Change: 2014-07-21 14:20:20.157755800 -0500
>  Birth: -
>
> (I will send jra the wireshark trace).
>
> On Mon, Jul 21, 2014 at 1:55 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
>> On Mon, Jul 21, 2014 at 01:43:12PM -0500, Steve French wrote:
>>> What about shrinking the file to the wrong size?
>>
>> In the set allocation path info it's going through:
>>
>>         if (allocation_size) {
>>                 allocation_size = smb_roundup(conn, allocation_size);
>>         }
>>
>> which by default uses 1MB allocation roundup values.
>>
>> If you need to set the file length, set the file length :-).
>>
>> It's arguable if the server can mess with allocation
>> requests on file shrink, but this hasn't caused a
>> problem in the SMB1/Windows SMB2 code paths so far,
>> so I'm guessing it might be allowable....
>>
>> More research needed !
>
>
>
> --
> Thanks,
>
> Steve



-- 
Thanks,

Steve

Re: setting allocation size in cifs/smb3

[Jeremy Allison]

On Mon, Jul 21, 2014 at 02:41:58PM -0500, Steve French wrote:
> To Windows 8.1 it appears to round to 4K boundaries when shrinking but
> also not extend the allocation size when allocating beyond end of file
> as the documentation would imply

You can make Samba do the same as Windows by setting:

allocation roundup size

to 4k.