2

I have an application that requires inodes be persistent across mounts, reboots etc.
With mount -t cifs -o serverino, it is supposed to do this (with server support). But, when I mount, some random set of files and directories will have client generated sequential IDs < 2^32.

I've tried multiple combinations of things including -o nounix -o serverino -o mfsymlinks -o noacls, and many others, but none seem to change the randomness of things.

Whenever it returns the > 2^32 inode, it seems to be consistent for a given file/directory, as far as I've seen over many mount attempts (not confirmed exhaustively), but a high proportion yet random set of files has small inode numbers that increment monotonically in the list output.

The server is Windows2012R2. Clients are CentOS and Ubuntu Linux with recent kernels. One has 3.10.0 and the other has 4.4.0

Is there anything that can be set client side or server side to give the UniqueId or the FileID back to the client as the inode when mounted like this?

(tried in vers 1, 2.1, and 3.0 protocols)

  • Windows services are not known for playing nice ; or even going out of their out to create incompatibilities with the competition. But I digress. Do you have an idea why the requirement of keeping the inodes exists? What does the app do? Backups? – Rui F Ribeiro Feb 3 '18 at 19:12
  • 1
    indexing where it is desirable to be able to detect that an item or folder has moved to a new location. Inode changes make that somewhat futile. – DougH Feb 4 '18 at 19:54
2

According to the mount.cifs(8) documentation, passing the serverino option should enable server-side inode numbers, but only if you have "CIFS UNIX Extensions" available on the server (see the "INODE NUMBERS" section):

When Unix Extensions are enabled, we use the actual inode number provided by the server in response to the POSIX calls as an inode number.

When Unix Extensions are disabled and "serverino" mount option is enabled there is no way to get the server inode number. The client typically maps the server-assigned "UniqueID" onto an inode number.

Note that the UniqueID is a different value from the server inode number. The UniqueID value is unique over the scope of the entire server and is often greater than 2 power 32. This value often makes programs that are not compiled with LFS (Large File Support), to trigger a glibc EOVERFLOW error as this won't fit in the target structure field. It is strongly recommended to compile your programs with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this problem. You can also use "noserverino" mount option to generate inode numbers smaller than 2 power 32 on the client. But you may not be able to detect hardlinks properly.

It's not directly indicated in the documentation, but you probably need the "CIFS POSIX Extensions" (CONFIG_CIFS_POSIX kernel option) to be enabled in the kernel.

As Windows Server 2012 doesn't have these extensions, you may want to enable the NFS Server feature instead and use that.

BTW, cifs isn't the only filesystem where this is the case: the /sys, /dev and /proc filesystems may exhibit this behaviour too.

  • Agree with what you said, but am still left in a quandary. Why does serverino seem to work with some of the files but not others? I have confirmed by installing Cygwin on the same server that the > 2^32 numbers appear to correspond to the FileId or UniqueID (one of them, not sure which), and that they are stable. So, why does it work for some falls but others get a random number assigned? That's the part that is totally baffling.One would think that if it works at all, that it would work consistently or fail consistently, not some hodge-podge. Enabling NFS feature isn't really an option. – DougH Feb 4 '18 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.