[linux-cifs-client] Re: endianness of uniqueid value in FILE_UNIX_BASIC_INFO

[Jeff Layton]

On Mon, 30 Mar 2009 12:10:03 -0500
"Steve French (smfltc)" <smfltc at us.ibm.com> wrote:

> Jeff Layton wrote:
> > On Sun, 29 Mar 2009 22:37:59 -0500
> > "Steve French (smfltc)" <smfltc at us.ibm.com> wrote:
> >
> >   
> >>>> Is the UniqueID field in FILE_UNIX_BASIC_INFO supposed to little endian
> >>>> when it goes over the wire?
> >>>>         
> >>> yes, the unix extensions use the same wire encoding as the rest of the protocol
> >>>       
> >> We intentionally treat the file of the UniqueId field as "opaque to the client" as we do with various other values in cifs structures.   We don't want to do unnecessary endian conversion of values that have no meaning to the client (and of course u8 fields do not get converted).  Obviously various fields that contain flags, lengths, sizes, times etc. do have to get converted on the client but there seems no point to convert server generated values that are "random" from the client's perspective and are not parsed by the client.
> >>
> >>     
> >
> > The case I was thinking of was 2 clients with different endianness and
> > you want to compare st_ino values on them. I'm hard pressed to consider
> > an example of an app where this would be important, but I think there's
> > value in being consistent here.
> >
> > On a similar note...
> >
> > Is it reliable to treat the uniqueid as unique over an entire share?
> > The SNIA spec says that it's supposed to be. I gave this a quick look
> > in the samba code as well and it appears to be generated using st_dev
> > and st_ino, but it would be good to confirm.
> >
> > The reason I'm asking is that I'm looking at cleaning up the way CIFS
> > handles hardlinks...
> >   
> OK - your example (comparing inode numbers between different client, 
> perhaps in backup/archive tools) makes sense, and is sufficient 
> justification to make the change (the performance impact of this is not 
> bad, but for the alternate case, for non-serverino your other suggestion 
> of changing to iunique perhaps would be too big a performance hit - 
> don't know ... need more data on the iunique impact).

This is another one of those places where it's very much dependent on
the situation. In almost all cases, this will not be noticable. iunique
is pretty fast when there aren't collisions. There may be corner cases
where someone has a bazillion inodes and it takes a lot of retries
until they get one.

The catch here is that you won't get collisions until after the global
counter in iunique wraps. So you need a long uptime + a lot of inodes
to really make iunique's performance suck.

> We should also 
> add code to cifs to recognize changes in st_dev on directory lookup (and 
> do implicit mounts) because inode number is not necessarily unique as we 
> cross devices traversing a long path.
> 

I don't think we need to do this if the main worry is st_ino collisions.
UniqueId is supposed to be unique within the scope of a share. There's
also a problem. We don't get st_dev info explicitly. I may be wrong
here but it looks like samba hashes the st_ino and st_dev together
to create a single uniqueid. I don't think we can count on being able to
tell when we cross a mountpoint on the server.

> With the change to inode number endianness in this path, I would also 
> like to switch the default to "serverino" for Windows

Makes sense. Let's hold off on this for now though.

I'd like to clean this up and get it right for the posix case first and
then go back and see what we can do for the non-posix case.

-- 
Jeff Layton <jlayton at redhat.com>