smbclient disk space on volumes larger than 1 TB

[Guntram Blohm]

Am 26.05.2011 18:06, schrieb Jeremy Allison:
> On Wed, May 25, 2011 at 10:31:39PM +0200, Guntram Blohm wrote:
>> First, sorry for posting to this list without being subscribed - i
>> hope this is the right place to post, though.
>>
>> I am trying to monitor allocation on a remote share by using
>> smbclient, sending a 'dir' command, and parsing the 'XXX blocks of
>> size XXX. XXX blocks available' line at the end. The problem is,
>> smbclient uses the (very old) cli_diskattr family of calls, which
>> return a maximum of 65536 blocks of size 16777216, which amounts to
>> 1 TB of disk space. If the share is larger, this result is just
>> wrong.
>>
>> The source for libsmb/clifsinfo.c already contains a
>> cli_get_fs_full_size_info function, that uses a newer call that can
>> return the full disk space even for larger shares. So would it be
>> possible to make the client/client.c do_dskattr function use
>> cli_get_fs_full_size_info instead of cli_dskattr? (I did that in my
>> version, and it seems to work, but since i don't want to claim the
>> ability to forsee all implications, and the patch is trivial anyway,
>> i decided not to submit it unless asked).
> I'm asking :-). Looking at patches always makes things easier :-).
>
> Thanks,
>
> Jeremy.

Sorry for the long delay. Turned out things are never as easy as they 
seem. The vanilla smbclient works great against a samba server, but 
NetApp servers don't behave well. Unfortunately, i don't have a true 
windows share that is larger than 1 TB to test against.

There seem to be (at least) SMB requests to get the size of a disk:
a) SMBdskattr, 0x80, used by the cli_dskattr function
b) SMB_FS_FULL_SIZE_INFORMATION, subcommand 0x1007 of trans2, in 
cli_get_fs_full_size_info
c) SMB_QUERY_FS_SIZE_INFO, subcommand 0x103 of the Trans2 request, not 
provided by libsmb

(a) has always been used by smbclient. It seems to work against all 
server platforms, but on a NetApp server, it returns a maximum of 1 TB 
for a share.
(b) provides more details than the other two, but it seems to be 
relatively new, and isn't supported by NetApp.
(c) provides a bit less details than (b) and seems to work well on every 
platform, but needs to be added to libsmb.

So i added two patches; one to libsmb/clifsinfo to add a function to 
call SMB_QUERY_FS_SIZE_INFO, and another one to client/client.c, that 
makes it call each of the 3 functions in turn and outputs what it finds. 
(Of course this isn't what the client should do, maybe it should just 
try which of the calls work)?

Of course, since only NetApp exhibits this problem, i guess we could 
just blame the whole thing on them and leave samba alone as well.

Here's the output of the patched client against various servers:

Windows XP
                 (a) 41732 blocks of size 8388608. 21025 blocks available
                 (b) 170935616 units of size 4*512. 86121115 units available
                 (c) 170935616 units of size 4*512. 86121115 units available
Windows 2008
                 (a) 40967 blocks of size 524288. 27782 blocks available
                 (b) 5243815 units of size 8*512. 3556188 units available
                 (c) 5243815 units of size 8*512. 3556188 units available
NetApp
                 (a) 65535 blocks of size 16777216. 19747 blocks available
Error in get_fs_full_size_info: ERRDOS - ERRunknownlevel (Unknown info 
level)
                 (c) 411566080 units of size 8*512. 80886795 units available
Samba
                 (a) 61440 blocks of size 2097152. 56583 blocks available
                 (b) 125829120 units of size 2*512. 115882688 units 
available
                 (c) 125829120 units of size 2*512. 115882688 units 
available

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clifsinfo.diff
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110605/caf2add1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: client.diff
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110605/caf2add1/attachment-0001.ksh>