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.
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
- Project changed from Ceph to Linux kernel client
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
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
- check timestamp of bar is current
umount /media/ceph
mount -t ceph ceph:/ /media/ceph
ls -l /media/ceph/bar
- check timestamp of bar is the same
touch -h -d 2010-01-02 /media/ceph/bar
ls -l /media/ceph/bar
- check timestamp of bar seems to have changed
umount /media/ceph
mount -t ceph ceph:/ /media/ceph
ls -l /media/ceph/bar
- oops, timestamp is back to what it was before
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.
- Project changed from Linux kernel client to CephFS
- Priority changed from Normal to High
ceph_symlink_iops does not have getattr/setattr and xattrs related mothods
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?
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.
- 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