smbclient disk space on volumes larger than 1 TB

[Volker Lendecke]

On Sun, Jun 05, 2011 at 08:35:39PM +0200, Guntram Blohm wrote:
> 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.

Another one where NetApp does not implement certain
infolevels or ways to do things that both Windows and Samba
servers do. My experience with NetApp has been that anything
not in their support matrix is really not supported. "Not
supported" as in "yes, it is indeed broken and we won't fix
it". Unfortunately to me it seems that any Linux client, be
it smbclient, be it cifsfs, is not in their client matrix.
So installations who have non-Windows clients should be very
cautious to install NetApp.

One hickup I've seen at a customer site was Tunderbird
running over cifsfs destroyed mailboxes because NetApp does
not support the way cifsfs uses to truncate files. Windows
does it, Samba does it, but NetApp does not.

Another one was where Linux cifsfs tried to enumerate EAs
and NetApp sent 39 bytes of garbage. 39 bytes is a typical
length for an error SMB packet, so we have triggered
*something* on the NetApp side, but the output seemed to be
random, uninitialized memory. cifsfs just dropped that
packet and eventually ran into a timeout for "ls", but
waiting 30 seconds for every file to show up is a less than
exciting experience.

These two ones are a while ago, so they might be fixed in
the meantime. But I would not count on NetApp to work
flawlessly with non-Windows clients.

> 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 would go with (c) always and do a fallback to (a) only
if we get an error message.

A comment on your patch: cli_send_trans is gone in 3.6 code.
Can you re-code it using cli_trans()?

Thanks,

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen