Bug 604089 - cifs: lstat syscall provides invalid inode numbers
Summary: cifs: lstat syscall provides invalid inode numbers
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-15 11:57 UTC by Joergen Thomsen
Modified: 2016-04-25 10:04 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-12 13:09:44 UTC
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

Description Joergen Thomsen 2010-06-15 11:57:22 UTC
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 12:43:37 UTC
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 13:07:02 UTC
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 19:06:54 UTC
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 19:20:58 UTC
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 19:43:44 UTC
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 20:07:24 UTC
(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 20:18:23 UTC
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 20:25:45 UTC
So ... should be reassigned to kernel?

Comment 9 Kamil Dudka 2010-06-16 20:36:40 UTC
(In reply to comment #8)
> So ... should be reassigned to kernel?    

+1, reassigning to kernel...

Comment 10 Joergen Thomsen 2010-06-16 21:16:27 UTC
I have also reported it here:

https://bugzilla.samba.org/show_bug.cgi?id=7520

Comment 11 Chuck Ebbert 2010-08-04 13:21:23 UTC
What kernel version does that happen on?
Does the cifs mount option "noserverino" make any difference?

Comment 12 Joergen Thomsen 2010-08-05 16:27:03 UTC
Please, see the samba bugzilla, where a fix is being worked upon

Comment 13 Jeff Layton 2010-10-12 13:09:44 UTC
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.