Observed in Linux Fedora 13.
The cp command will reject copying files because the lstat call returns incorrect inode numbers. strace on the src server on smb displays a correct lstat inode number, but it gets replaced during transit to the destination server.
The problem is intermittent. A repeated command may work.
coreutils-8.5/src/cp: skipping file `/mnt/vl/boot/vmlinuz-18.104.22.168-115.fc12.x86_64', as it was replaced while being copied (dev/ino, lstat 23/5512 fstat 23/21)
The number 5512 is incorrect and from a series of numbers incremented by 1 for each file.
Please, see bug 604089
This message was found in dmesg
CIFS VFS: Autodisabling the use of server inode numbers on \\192.168.1.2\rootdir. This server doesn't seem to support them properly. Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
which is nonsense, as it is working many times eg. just by repeating the cp command.
Does the share you're copying from span multiple filesystems on the server?
Just simple ext4 setup on both servers
Can you clarify what you mean by "simple ext4" setup. Are there nested ext4 filesystems under the single share you're mounting?
Definitely not. I am not running complicated file system setups. It is all plain vanilla one level.
Ok, I've proposed a set of patches that may help this. Steve French has taken all but one for 2.6.36:
I expect that he'll take the last one eventually, but he hasn't put it in as of yet.
Steve has taken most of the patches at this point. There's one more that helps prevent inode aliasing by using the CreateTime as an i_generation field that is not yet in.
Jørgen would you be able to test a recent mainline kernel build? What may be simplest is to pull down the latest Fedora rawhide kernel out of koji and test that.
Sorry, no. I neither have the test facilities nor the time to spend on beta kernels and have no idea what koji is.
Fair enough then. Closing this bug as FIXED in kernel 2.6.36. Please reopen if you find that it isn't.