Project

General

Profile

Bug #1878

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

Added by Alexandre Oliva almost 12 years ago. Updated over 10 years ago.

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

0%

Source:
Tags:
Backport:
Regression:
No
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.

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

History

#1 Updated by Sage Weil over 11 years ago

  • Project changed from Ceph to Linux kernel client

#2 Updated by Alexandre Oliva almost 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

#3 Updated by Alexandre Oliva almost 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

#4 Updated by Alexandre Oliva almost 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.

#5 Updated by Ian Colle almost 11 years ago

  • Project changed from Linux kernel client to CephFS

#6 Updated by Sage Weil almost 11 years ago

  • Priority changed from Normal to High

#7 Updated by Zheng Yan over 10 years ago

ceph_symlink_iops does not have getattr/setattr and xattrs related mothods

#8 Updated by Greg Farnum over 10 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?

#9 Updated by Zheng Yan over 10 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.

#10 Updated by Greg Farnum over 10 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?).

Also available in: Atom PDF