Project

General

Profile

Actions
Copy link

Bug #1878

closed

ceph.ko doesn't setattr (lchown, utimes) on symlinks

Added by Alexandre Oliva over 12 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
High
Assignee:
Greg Farnum
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

rsync -a /my/symlink/pool/ /mnt/ceph.ko/pool/ silently fails to set times and ownership of symlinks, whereas the same operation onto /mnt/cfuse/pool/ succeeds, and from then on lstat() within the ceph.ko mountpoint displays the correct information.

Files

0001-ceph-fix-symlink-inode-operations.patch (925 Bytes) 0001-ceph-fix-symlink-inode-operations.patch Zheng Yan, 04/07/2013 01:46 AM
Actions
Copy link
 #1

Updated by Sage Weil about 12 years ago

  • Project changed from Ceph to Linux kernel client
Actions
Copy link
 #2

Updated by Alexandre Oliva about 11 years ago

This is still present in 3.6.11 (I'll know about 3.7.* soon). I suspect this may have to do with failing to mark metadata as dirty after a change, and that this is the same bug that causes zero-sized files to disappear or get the wrong timestamp (not sure which, I just know rsync often tries to copy them again on retries) if they don't find other reasons to make ther way to the mds

Actions
Copy link
 #3

Updated by Alexandre Oliva about 11 years ago

I've just verified that the problem is still present in 3.7.3, and I have a much simpler reproducer too.

mount -t ceph ceph:/ /media/ceph
ln -s foo /media/ceph/bar
ls -l /media/ceph/bar
  1. check timestamp of bar is current
    umount /media/ceph
    mount -t ceph ceph:/ /media/ceph
    ls -l /media/ceph/bar
  2. check timestamp of bar is the same
    touch -h -d 2010-01-02 /media/ceph/bar
    ls -l /media/ceph/bar
  3. check timestamp of bar seems to have changed
    umount /media/ceph
    mount -t ceph ceph:/ /media/ceph
    ls -l /media/ceph/bar
  4. oops, timestamp is back to what it was before
Actions
Copy link
 #4

Updated by Alexandre Oliva about 11 years ago

Heh. Funny markup. The numbered list came out of #s used for comments.

Anyway, I've just verified that the issue with zero-sized regular files doesn't appear to be the same. At least touching them does make it to the server and survives a umount;mount cycle. I'll try to gathe more details on why I often see such files being re-updated by rsync.

Actions
Copy link
 #5

Updated by Ian Colle about 11 years ago

  • Project changed from Linux kernel client to CephFS
Actions
Copy link
 #6

Updated by Sage Weil about 11 years ago

  • Priority changed from Normal to High
Actions
Copy link
 #7

Updated by Zheng Yan about 11 years ago

ceph_symlink_iops does not have getattr/setattr and xattrs related mothods

Actions
Copy link
 #8

Updated by Greg Farnum about 11 years ago

I'm actually not sure how the symlink stuff is represented in our kernel client or the VFS — do these functions handle symlinks instead of real files appropriately?

Actions
Copy link
 #9

Updated by Zheng Yan about 11 years ago

For xattrs, there is no difference between symbol links and regular file. For setattr, I think the only difference is that we can't truncate symbol link. VFS has check for the truncate case.

Actions
Copy link
 #10

Updated by Greg Farnum about 11 years ago

  • Status changed from Fix Under Review to Resolved

I've pushed this to our testing branch. It's presently commit:baf0169b77f6a0c384a15fb425e5700fb0239e89, although that will probably rebase since we've still got your VFS patch buried in there and need to extract it (speaking of which, Alex, should we pull that out and keep it on HEAD so that we can get stable hashes for the other commits going forward?).

Actions
Copy link

Also available in: Atom PDF