Bug 604089 - cifs: lstat syscall provides invalid inode numbers
cifs: lstat syscall provides invalid inode numbers
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Jeff Layton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-15 07:57 EDT by Joergen Thomsen
Modified: 2016-04-25 06:04 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-12 09:09:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Samba Project 7520 None None None Never

  None (edit)
Description Joergen Thomsen 2010-06-15 07:57:22 EDT
Description of problem:
Files not copied from samba share on another Linux server

Very old problem which never seems to have been solved or has reappeared.
Similar operation between Fedora 12 and Fedora 6 servers did not exhibit the problem.

Version-Release number of selected component (if applicable):
8.4

How reproducible:
always
Fresh Fedora 13 installation. Copying files from Fedora 12 server

Steps to Reproduce:
1.mount -t cifs //192.168.1.2/rootdir /mnt/vl --verbose -o password=xxx
2.cp -a /mnt/vl/root/* .
3.
  
Actual results:
A lot of these error messages, but not for all files

cp: skipping file `/mnt/vl/root/rpmbuild/BUILD/kernel-2.6.32/linux-2.6.32.x86_64/sound/pcmcia/pdaudiocf/.snd-pdaudiocf.mod.o.cmd', as it was replaced while being copied

cp: skipping file `/mnt/vl/root/rpmbuild/BUILD/kernel-2.6.32/linux-2.6.32.x86_64/sound/pcmcia/pdaudiocf/pdaudiocf_pcm.c', as it was replaced while being copied


Expected results:

All files copied, no error messages

Additional info:
F13: samba 3.5.3-61.fc13
F12: samba 3.4.7-58.fc12
Comment 1 Joergen Thomsen 2010-06-15 08:43:37 EDT
The error messages are from this test in cp (src/copy.c)

  /* Compare the source dev/ino from the open file to the incoming,
     saved ones obtained via a previous call to stat.  */
  if (! SAME_INODE (*src_sb, src_open_sb))
    {
      error (0, 0,
             _("skipping file %s, as it was replaced while being copied %d/%d %d/%d"),
             quote (src_name),(*src_sb).st_dev, (*src_sb).st_ino, src_open_sb.st_dev, src_open_sb.st_ino);
      return_val = false;
      goto close_src_desc;
    }

I added a printout of the values and got this:

skipping file x, as it was replaced while being copied 20/30681 20/1574355
skipping file y, as it was replaced while being copied 20/30682 20/12983805
skipping file z, as it was replaced while being copied 20/30683 20/13002682

The 20/1574355 etc numbers are verified to be the correct ones with ls -i
Comment 2 Kamil Dudka 2010-06-15 09:07:02 EDT
Did you try to mount it read-only?

If the read-only mount does not help, it looks like cifs variant of bug 501848
Comment 3 Joergen Thomsen 2010-06-16 15:06:54 EDT
read-only makes no difference

cp is comparing dev/ino from a lstat with the values from a fstat (cp -a ...). 

The file system is ext4 on both servers. 
It appears that the problem occurs, when the file/file metadata is not in the Linux file system cache.

It is interesting to observe, that the device numbers are identical, but the inode number from lstat is just a counter being incremented by 1.

The problem seems to be located in the system somewhere below cp.
Comment 4 Kamil Dudka 2010-06-16 15:20:58 EDT
Does 'cp -L' make any difference?

Note you need to specify '-L' after '-a', it won't work well in the opposite order.
Comment 5 Joergen Thomsen 2010-06-16 15:43:44 EDT
stat  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
23      4853    /mnt/vl/boot/vmlinuz
stat -L  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
23      21      /mnt/vl/boot/vmlinuz

stat  --printf "%d\t%i\t%n\n" /boot/vmlinuz
2049    12      /boot/vmlinuz
stat -L  --printf "%d\t%i\t%n\n" /boot/vmlinuz
2049    21      /boot/vmlinuz

The interesting thing here is, that the symbolic link inode is displayed as 4853 (a number closely related to the wrong numbers displayed in my test a  few moments before) when it should be 12 as displayed on the source server. This occurs for all the symlinks in /boot and is reproducible with the same inode numbers.

The cp -a -L will get the proper inode number.

I restarted smb/nmb on the source server: no change.
I unmounted/mounted and then the proper inode number was displayed for /mnt/vl/boot/vmlinuz. However not for /mnt/vl/boot/System.map, which had changed to a higher number in the skipped file sequence which again appeared on
/usr/src/other/co*5/src/cp -a  /mnt/vl/boot/ . after the mount.
Repeating this command got rid of the skipped files, but kept the wrong inode number for symlinks (except /mnt/vl/boot/vmlinuz which is now correct !).
Comment 6 Kamil Dudka 2010-06-16 16:07:24 EDT
(In reply to comment #5)
> stat  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
> 23      4853    /mnt/vl/boot/vmlinuz
> stat -L  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
> 23      21      /mnt/vl/boot/vmlinuz
> 
> stat  --printf "%d\t%i\t%n\n" /boot/vmlinuz
> 2049    12      /boot/vmlinuz
> stat -L  --printf "%d\t%i\t%n\n" /boot/vmlinuz
> 2049    21      /boot/vmlinuz

Did you try the same in different order?

> The cp -a -L will get the proper inode number.

That's probably the difference among stat/lstat syscalls.

> Repeating this command got rid of the skipped files, but kept the wrong inode
> number for symlinks (except /mnt/vl/boot/vmlinuz which is now correct !).    

I don't think I understand here.  The inode number can't be the same for src and dst.  On successful copy the new file gets assigned a new inode nubmer by the target filesystem.

Anyway this doesn't look like a coreutils problem as you can easily check by strace.  It must be a filesystem bug (or feature).
Comment 7 Joergen Thomsen 2010-06-16 16:18:23 EDT
I am referring to the inode numbers as seen from the destination server and displayed by debugging statements I inserted into cp.

I agree, it is not a coreutils bug, but a BUG somewhere else. Is is definitely not at feature not being able to connct to a share and copy a file.
Comment 8 Ondrej Vasik 2010-06-16 16:25:45 EDT
So ... should be reassigned to kernel?
Comment 9 Kamil Dudka 2010-06-16 16:36:40 EDT
(In reply to comment #8)
> So ... should be reassigned to kernel?    

+1, reassigning to kernel...
Comment 10 Joergen Thomsen 2010-06-16 17:16:27 EDT
I have also reported it here:

https://bugzilla.samba.org/show_bug.cgi?id=7520
Comment 11 Chuck Ebbert 2010-08-04 09:21:23 EDT
What kernel version does that happen on?
Does the cifs mount option "noserverino" make any difference?
Comment 12 Joergen Thomsen 2010-08-05 12:27:03 EDT
Please, see the samba bugzilla, where a fix is being worked upon
Comment 13 Jeff Layton 2010-10-12 09:09:44 EDT
Upstream bug closed as fixed. Closing this one with resolution of RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.