Nice! On Wed, Jun 14, 2017 at 3:59 AM, Yan, Zheng <zyan@xxxxxxxxxx> wrote: > >> On 14 Jun 2017, at 03:19, John Spray <jspray@xxxxxxxxxx> wrote: >> >> On Tue, Jun 13, 2017 at 9:05 AM, Wyllys Ingersoll >> <wyllys.ingersoll@xxxxxxxxxxxxxx> wrote: >>> That sounds similar but Im not sure if its the same issue. Our mounts >>> were done using kernel mounting, not fuse. >> >> The fix for userspace was to issue a stat on inodes before reading >> virtual xattrs: >> >> commit 532dc4b68e538c189ef828f67cecd0d647a62250 >> Author: John Spray <john.spray@xxxxxxxxxx> >> Date: Wed Mar 15 15:32:47 2017 +0000 >> >> client: getattr before read on ceph.* xattrs >> >> Previously we were returning values for quota, layout >> xattrs without any kind of update -- the user just got >> whatever happened to be in our cache. >> >> Clearly this extra round trip has a cost, but reads of >> these xattrs are fairly rare, happening on admin >> intervention rather than in normal operation. >> >> We didn't look at doing it in the kernel client at that point because >> the motivation was to fix quota handling, and the kernel client >> doesn't do quotas. >> >> It seems like we should probably update the kernel client to do the >> same thing -- Zheng, what do you think? >> > done, https://github.com/ceph/ceph-client/commit/d69a42d91de651d5981d1b5538132ff362a9ee > > Regards > Yan, Zheng > >> John >> >>> On Tue, Jun 13, 2017 at 6:02 AM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: >>>> Sounds like this issue? >>>> >>>> http://tracker.ceph.com/issues/17939 >>>> >>>> Cheers, Dan >>>> >>>> >>>> >>>> On Mon, Jun 12, 2017 at 9:45 PM, Wyllys Ingersoll >>>> <wyllys.ingersoll@xxxxxxxxxxxxxx> wrote: >>>>> Ceph 10.2.7 >>>>> Ubuntu 16.04.2 >>>>> >>>>> We have 2 hosts running identical versions of ceph with identical >>>>> ceph.conf configuration files. >>>>> Both mount /cephfs with the same options. >>>>> >>>>> We have a directory under /cephfs with a 4GB file in it. The >>>>> ceph.dir.rbytes xattr reported by ceph is different on the 2 hosts. >>>>> One is correct, one is not. >>>>> >>>>> One host reports the 'ceph.dir.rbytes' correctly as 4129644548, the >>>>> other reports it incorrectly as 2389190660 >>>>> Any ideas why this would be happening ? >>>>> >>>>> - Wyllys Ingersoll >>>>> Keeper Technology, LLC >>>>> >>>>> >>>>> HOST A (correct values): >>>>> $ ls -alF /cephfs/exports/smbtest >>>>> total 4032857 >>>>> drwxrwxrwx 1 root root 4129644548 May 31 11:28 ./ >>>>> drwxr-xr-x 1 root root 4129644548 May 31 11:25 ../ >>>>> -rw-r--r-- 1 2000501 2000514 4096 May 31 11:26 ._.DS_Store >>>>> -rw-r--r-- 1 2000501 2000514 6148 Jun 1 14:37 .DS_Store >>>>> -rw-r--r-- 1 2000501 2000514 4129634304 Jun 12 15:25 test-2017-05-30-m1.iso >>>>> >>>>> $ getfattr -d -m ceph.dir /cephfs/exports/smbtest >>>>> getfattr: Removing leading '/' from absolute path names >>>>> # file: cephfs/exports/smbtest >>>>> ceph.dir.rbytes="4129644548" >>>>> >>>>> HOST B (incorrect values) >>>>> $ ls -alF /cephfs/exports/smbtest >>>>> total 4032857 >>>>> drwxrwxrwx 1 root root 2389190660 May 31 11:28 ./ >>>>> drwxr-xr-x 1 root root 4129644548 May 31 11:25 ../ >>>>> -rw-r--r-- 1 2000501 2000514 4096 May 31 11:26 ._.DS_Store >>>>> -rw-r--r-- 1 2000501 2000514 6148 Jun 1 14:37 .DS_Store >>>>> -rw-r--r-- 1 2000501 2000514 4129634304 Jun 12 15:25 test-2017-05-30-m1.iso >>>>> >>>>> $ getfattr -d -m ceph.dir.rbytes /cephfs/exports/smbtest >>>>> getfattr: Removing leading '/' from absolute path names >>>>> # file: cephfs/exports/smbtest >>>>> ceph.dir.rbytes="2389190660" >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> -- >>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
