Re: [2.6] smbfs & "du" illness

[Jeremy Allison <jra@samba.org>]

On Sat, Sep 25, 2004 at 02:59:08PM -0700, Linus Torvalds wrote:
> 
> So let's work out something that works well now, _and_ might have a chance 
> in hell of working in the future too.

Ok. BTW I've fixed this in the current SVN codebase
to do the right thing (return st_blocks expressed as
bytes).

> What kinds of values do different smb servers actually fill this field 
> with? And what's the value you expect future samba severs will use?

Ok, right now the only smb server that supports the UNIX
extensions is smbd (I'm working on getting NetApp to also
support them, but they don't as yet so we can get them to
do the right thing, bytes allocated, when they do), so we
know pretty much what will happen.

> Ie, will something like this DTRT in smb_decode_unix_basic():
> 
> 	u64 size = LVAL(p, 0);	/* file size */
> 	u64 blocks = LVAL(p, 8); /* pseudo-blocks */
> 	u32 real_blocks;
> 
>         fattr->f_size = size;
> 	real_blocks = (size + 511) >> 9;
> 
> 	/*
> 	 * old samba sends "bytes used on disk rounded up to 1MB",
> 	 * which is useless - ignore it. But if the low bits are
> 	 * set, maybe the value is valid..
> 	 */
> 	if (blocks & 0xfffff) {
> 		/*
> 		 * If the low 9 bits are non-zero, it can't
> 		 * be a byte count, but maybe it's a block
> 		 * count?
> 		 */
> 		if (blocks & 0x1ff) {
> 			.. use it how? ..
> 		} else {
> 			real_blocks = blocks >> 9;
> 		}
> 	}
>         fattr->f_blocks = real_blocks;
> 
> the above is ugly as hell, but what choice is there?

Not much, sorry. 

> It would be good to know what all different server implementations can 
> do, to know just _how_ defensive this code has to be. 

It has to deal with Samba sending bytes allocated on disk (from st_blocks),
rounded up to the nearest 1mb (or whatever the local admin compiled with,
but most people don't mess with that compile-time parameter) or starting
with Samba 3.0.8 it'll send the value from the server st_blocks expressed
as bytes. So it doesn't have to be too bad (I hope).

Jeremy.