* [GIT PULL] Ceph fixes for -rc7
@ 2016-03-06 1:48 Sage Weil
2016-03-25 4:02 ` NeilBrown
0 siblings, 1 reply; 14+ messages in thread
From: Sage Weil @ 2016-03-06 1:48 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, ceph-devel
Hi Linus,
Please pull the following Ceph patch from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
This is a final commit we missed to align the protocol compatibility with
the feature bits. It decodes a few extra fields in two different messages
and reports EIO when they are used (not yet supported).
Thanks!
sage
----------------------------------------------------------------
Yan, Zheng (1):
ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support
fs/ceph/addr.c | 4 ++++
fs/ceph/caps.c | 27 ++++++++++++++++++++++++---
fs/ceph/inode.c | 2 ++
fs/ceph/mds_client.c | 16 ++++++++++++++++
fs/ceph/mds_client.h | 1 +
fs/ceph/super.h | 1 +
include/linux/ceph/ceph_features.h | 1 +
7 files changed, 49 insertions(+), 3 deletions(-)
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-06 1:48 [GIT PULL] Ceph fixes for -rc7 Sage Weil @ 2016-03-25 4:02 ` NeilBrown 2016-03-25 9:34 ` Ilya Dryomov 2016-03-28 2:12 ` Yan, Zheng 0 siblings, 2 replies; 14+ messages in thread From: NeilBrown @ 2016-03-25 4:02 UTC (permalink / raw) To: Sage Weil, torvalds; +Cc: linux-kernel, ceph-devel [-- Attachment #1: Type: text/plain, Size: 1437 bytes --] On Sun, Mar 06 2016, Sage Weil wrote: > Hi Linus, > > Please pull the following Ceph patch from > > git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus > > This is a final commit we missed to align the protocol compatibility with > the feature bits. It decodes a few extra fields in two different messages > and reports EIO when they are used (not yet supported). > > Thanks! > sage > > > ---------------------------------------------------------------- > Yan, Zheng (1): > ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and CEPH_FEATURE_CRUSH_TUNABLES5)?? Because when I backported this patch (and many others) to some ancient enterprise kernel, it caused mounts to fail. If it really is meant to be the same value, then I must have some other backported issue to find and fix. Thanks, NeilBrown > > fs/ceph/addr.c | 4 ++++ > fs/ceph/caps.c | 27 ++++++++++++++++++++++++--- > fs/ceph/inode.c | 2 ++ > fs/ceph/mds_client.c | 16 ++++++++++++++++ > fs/ceph/mds_client.h | 1 + > fs/ceph/super.h | 1 + > include/linux/ceph/ceph_features.h | 1 + > 7 files changed, 49 insertions(+), 3 deletions(-) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-25 4:02 ` NeilBrown @ 2016-03-25 9:34 ` Ilya Dryomov 2016-03-30 0:24 ` NeilBrown 2016-03-28 2:12 ` Yan, Zheng 1 sibling, 1 reply; 14+ messages in thread From: Ilya Dryomov @ 2016-03-25 9:34 UTC (permalink / raw) To: NeilBrown; +Cc: Sage Weil, torvalds, linux-kernel, Ceph Development On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: > On Sun, Mar 06 2016, Sage Weil wrote: > >> Hi Linus, >> >> Please pull the following Ceph patch from >> >> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >> >> This is a final commit we missed to align the protocol compatibility with >> the feature bits. It decodes a few extra fields in two different messages >> and reports EIO when they are used (not yet supported). >> >> Thanks! >> sage >> >> >> ---------------------------------------------------------------- >> Yan, Zheng (1): >> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support > > Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have > exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and > CEPH_FEATURE_CRUSH_TUNABLES5)?? Yes, that was the point of getting it merged into -rc7. > Because when I backported this patch (and many others) to some ancient > enterprise kernel, it caused mounts to fail. If it really is meant to > be the same value, then I must have some other backported issue to find > and fix. It has to be backported in concert with changes that add support for the other two bits. How did mount fail? Thanks, Ilya ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-25 9:34 ` Ilya Dryomov @ 2016-03-30 0:24 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-30 0:24 UTC (permalink / raw) To: Ilya Dryomov; +Cc: Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 2341 bytes --] On Fri, Mar 25 2016, Ilya Dryomov wrote: > On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >> On Sun, Mar 06 2016, Sage Weil wrote: >> >>> Hi Linus, >>> >>> Please pull the following Ceph patch from >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>> >>> This is a final commit we missed to align the protocol compatibility with >>> the feature bits. It decodes a few extra fields in two different messages >>> and reports EIO when they are used (not yet supported). >>> >>> Thanks! >>> sage >>> >>> >>> ---------------------------------------------------------------- >>> Yan, Zheng (1): >>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >> >> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >> CEPH_FEATURE_CRUSH_TUNABLES5)?? > > Yes, that was the point of getting it merged into -rc7. I did wonder if that might be the case. > >> Because when I backported this patch (and many others) to some ancient >> enterprise kernel, it caused mounts to fail. If it really is meant to >> be the same value, then I must have some other backported issue to find >> and fix. > > It has to be backported in concert with changes that add support for > the other two bits. I have everything from fs/ceph and net/ceph as of 4.5, with adjustments for different core code. > How did mount fail? "can't read superblock". dmesg contains [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba [ 50.823746] libceph: mon0 192.168.1.122:6789 session established [ 51.635312] ceph: problem parsing mds trace -5 [ 51.635317] ceph: mds parse_reply err -5 [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) then a hex dump of header:, front: footer: Maybe my MDS is causing the problem? It is based on v10.0.5 which contains #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ in ceph_features.h i.e. two features using bit 58, but not FS_FILE_LAYOUT_V2 Should I expect Linux 4.5 to work with ceph 10.0.5 ?? Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 @ 2016-03-30 0:24 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-30 0:24 UTC (permalink / raw) To: Ilya Dryomov; +Cc: Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 2341 bytes --] On Fri, Mar 25 2016, Ilya Dryomov wrote: > On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >> On Sun, Mar 06 2016, Sage Weil wrote: >> >>> Hi Linus, >>> >>> Please pull the following Ceph patch from >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>> >>> This is a final commit we missed to align the protocol compatibility with >>> the feature bits. It decodes a few extra fields in two different messages >>> and reports EIO when they are used (not yet supported). >>> >>> Thanks! >>> sage >>> >>> >>> ---------------------------------------------------------------- >>> Yan, Zheng (1): >>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >> >> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >> CEPH_FEATURE_CRUSH_TUNABLES5)?? > > Yes, that was the point of getting it merged into -rc7. I did wonder if that might be the case. > >> Because when I backported this patch (and many others) to some ancient >> enterprise kernel, it caused mounts to fail. If it really is meant to >> be the same value, then I must have some other backported issue to find >> and fix. > > It has to be backported in concert with changes that add support for > the other two bits. I have everything from fs/ceph and net/ceph as of 4.5, with adjustments for different core code. > How did mount fail? "can't read superblock". dmesg contains [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba [ 50.823746] libceph: mon0 192.168.1.122:6789 session established [ 51.635312] ceph: problem parsing mds trace -5 [ 51.635317] ceph: mds parse_reply err -5 [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) then a hex dump of header:, front: footer: Maybe my MDS is causing the problem? It is based on v10.0.5 which contains #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ in ceph_features.h i.e. two features using bit 58, but not FS_FILE_LAYOUT_V2 Should I expect Linux 4.5 to work with ceph 10.0.5 ?? Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-30 0:24 ` NeilBrown (?) @ 2016-03-30 2:30 ` Yan, Zheng 2016-03-30 2:40 ` NeilBrown -1 siblings, 1 reply; 14+ messages in thread From: Yan, Zheng @ 2016-03-30 2:30 UTC (permalink / raw) To: NeilBrown; +Cc: Ilya Dryomov, Sage Weil, linux-kernel, Ceph Development On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: > On Fri, Mar 25 2016, Ilya Dryomov wrote: > >> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>> On Sun, Mar 06 2016, Sage Weil wrote: >>> >>>> Hi Linus, >>>> >>>> Please pull the following Ceph patch from >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>> >>>> This is a final commit we missed to align the protocol compatibility with >>>> the feature bits. It decodes a few extra fields in two different messages >>>> and reports EIO when they are used (not yet supported). >>>> >>>> Thanks! >>>> sage >>>> >>>> >>>> ---------------------------------------------------------------- >>>> Yan, Zheng (1): >>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>> >>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >> >> Yes, that was the point of getting it merged into -rc7. > > I did wonder if that might be the case. > >> >>> Because when I backported this patch (and many others) to some ancient >>> enterprise kernel, it caused mounts to fail. If it really is meant to >>> be the same value, then I must have some other backported issue to find >>> and fix. >> >> It has to be backported in concert with changes that add support for >> the other two bits. > > I have everything from fs/ceph and net/ceph as of 4.5, with adjustments > for different core code. > >> How did mount fail? > > "can't read superblock". > dmesg contains > > [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba > [ 50.823746] libceph: mon0 192.168.1.122:6789 session established > [ 51.635312] ceph: problem parsing mds trace -5 > [ 51.635317] ceph: mds parse_reply err -5 > [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) > > then a hex dump of header:, front: footer: > > Maybe my MDS is causing the problem? It is based on v10.0.5 which > contains > > #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ > // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN > #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ > > in ceph_features.h i.e. two features using bit 58, but not > FS_FILE_LAYOUT_V2 > > Should I expect Linux 4.5 to work with ceph 10.0.5 ?? Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade to ceph 10.1.0 Regards Yan, Zheng > > Thanks, > NeilBrown ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-30 2:30 ` Yan, Zheng @ 2016-03-30 2:40 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-30 2:40 UTC (permalink / raw) To: Yan, Zheng; +Cc: Ilya Dryomov, Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 2940 bytes --] On Wed, Mar 30 2016, Yan, Zheng wrote: > On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >> On Fri, Mar 25 2016, Ilya Dryomov wrote: >> >>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>> >>>>> Hi Linus, >>>>> >>>>> Please pull the following Ceph patch from >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>> >>>>> This is a final commit we missed to align the protocol compatibility with >>>>> the feature bits. It decodes a few extra fields in two different messages >>>>> and reports EIO when they are used (not yet supported). >>>>> >>>>> Thanks! >>>>> sage >>>>> >>>>> >>>>> ---------------------------------------------------------------- >>>>> Yan, Zheng (1): >>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>> >>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>> >>> Yes, that was the point of getting it merged into -rc7. >> >> I did wonder if that might be the case. >> >>> >>>> Because when I backported this patch (and many others) to some ancient >>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>> be the same value, then I must have some other backported issue to find >>>> and fix. >>> >>> It has to be backported in concert with changes that add support for >>> the other two bits. >> >> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >> for different core code. >> >>> How did mount fail? >> >> "can't read superblock". >> dmesg contains >> >> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >> [ 51.635312] ceph: problem parsing mds trace -5 >> [ 51.635317] ceph: mds parse_reply err -5 >> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >> >> then a hex dump of header:, front: footer: >> >> Maybe my MDS is causing the problem? It is based on v10.0.5 which >> contains >> >> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >> >> in ceph_features.h i.e. two features using bit 58, but not >> FS_FILE_LAYOUT_V2 >> >> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? > > Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade > to ceph 10.1.0 > Ahhh.. I do wonder at the point of feature flags if they don't let you run any client with any server... Is there a compatability matrix published somewhere? If I have to stay with 10.0.5 (I don't know yet), it is safe to use Linux-4.4 code? Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 @ 2016-03-30 2:40 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-30 2:40 UTC (permalink / raw) To: Yan, Zheng; +Cc: Ilya Dryomov, Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 2940 bytes --] On Wed, Mar 30 2016, Yan, Zheng wrote: > On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >> On Fri, Mar 25 2016, Ilya Dryomov wrote: >> >>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>> >>>>> Hi Linus, >>>>> >>>>> Please pull the following Ceph patch from >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>> >>>>> This is a final commit we missed to align the protocol compatibility with >>>>> the feature bits. It decodes a few extra fields in two different messages >>>>> and reports EIO when they are used (not yet supported). >>>>> >>>>> Thanks! >>>>> sage >>>>> >>>>> >>>>> ---------------------------------------------------------------- >>>>> Yan, Zheng (1): >>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>> >>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>> >>> Yes, that was the point of getting it merged into -rc7. >> >> I did wonder if that might be the case. >> >>> >>>> Because when I backported this patch (and many others) to some ancient >>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>> be the same value, then I must have some other backported issue to find >>>> and fix. >>> >>> It has to be backported in concert with changes that add support for >>> the other two bits. >> >> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >> for different core code. >> >>> How did mount fail? >> >> "can't read superblock". >> dmesg contains >> >> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >> [ 51.635312] ceph: problem parsing mds trace -5 >> [ 51.635317] ceph: mds parse_reply err -5 >> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >> >> then a hex dump of header:, front: footer: >> >> Maybe my MDS is causing the problem? It is based on v10.0.5 which >> contains >> >> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >> >> in ceph_features.h i.e. two features using bit 58, but not >> FS_FILE_LAYOUT_V2 >> >> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? > > Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade > to ceph 10.1.0 > Ahhh.. I do wonder at the point of feature flags if they don't let you run any client with any server... Is there a compatability matrix published somewhere? If I have to stay with 10.0.5 (I don't know yet), it is safe to use Linux-4.4 code? Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-30 2:40 ` NeilBrown (?) @ 2016-03-30 8:04 ` Ilya Dryomov 2016-03-30 18:09 ` Gregory Farnum -1 siblings, 1 reply; 14+ messages in thread From: Ilya Dryomov @ 2016-03-30 8:04 UTC (permalink / raw) To: NeilBrown; +Cc: Yan, Zheng, Sage Weil, linux-kernel, Ceph Development On Wed, Mar 30, 2016 at 4:40 AM, NeilBrown <neilb@suse.com> wrote: > On Wed, Mar 30 2016, Yan, Zheng wrote: > >> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >>> On Fri, Mar 25 2016, Ilya Dryomov wrote: >>> >>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>>> >>>>>> Hi Linus, >>>>>> >>>>>> Please pull the following Ceph patch from >>>>>> >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>>> >>>>>> This is a final commit we missed to align the protocol compatibility with >>>>>> the feature bits. It decodes a few extra fields in two different messages >>>>>> and reports EIO when they are used (not yet supported). >>>>>> >>>>>> Thanks! >>>>>> sage >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> Yan, Zheng (1): >>>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>>> >>>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>>> >>>> Yes, that was the point of getting it merged into -rc7. >>> >>> I did wonder if that might be the case. >>> >>>> >>>>> Because when I backported this patch (and many others) to some ancient >>>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>>> be the same value, then I must have some other backported issue to find >>>>> and fix. >>>> >>>> It has to be backported in concert with changes that add support for >>>> the other two bits. >>> >>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >>> for different core code. >>> >>>> How did mount fail? >>> >>> "can't read superblock". >>> dmesg contains >>> >>> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >>> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >>> [ 51.635312] ceph: problem parsing mds trace -5 >>> [ 51.635317] ceph: mds parse_reply err -5 >>> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >>> >>> then a hex dump of header:, front: footer: >>> >>> Maybe my MDS is causing the problem? It is based on v10.0.5 which >>> contains >>> >>> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >>> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >>> >>> in ceph_features.h i.e. two features using bit 58, but not >>> FS_FILE_LAYOUT_V2 >>> >>> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? >> >> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade >> to ceph 10.1.0 >> > > Ahhh.. I do wonder at the point of feature flags if they don't let you > run any client with any server... > Is there a compatability matrix published somewhere? > If I have to stay with 10.0.5 (I don't know yet), it is safe to use > Linux-4.4 code? 10.0.* are all development cuts, we didn't even built packages for some of them. 10.1.0 is the first release candidate. You can think of 10.0.5 as a random pre-rc1 kernel snapshot, aimed at brave testers, so you do want to upgrade. The reason it doesn't work is those three features are all defined to the same value, but two of them got added earlier in the 10.0.* cycle. CEPH_FEATURE_FS_FILE_LAYOUT_V2 came in last, after 10.0.5. Thanks, Ilya ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-30 8:04 ` Ilya Dryomov @ 2016-03-30 18:09 ` Gregory Farnum 2016-03-31 2:18 ` NeilBrown 0 siblings, 1 reply; 14+ messages in thread From: Gregory Farnum @ 2016-03-30 18:09 UTC (permalink / raw) To: Ilya Dryomov Cc: NeilBrown, Yan, Zheng, Sage Weil, linux-kernel, Ceph Development On Wed, Mar 30, 2016 at 1:04 AM, Ilya Dryomov <idryomov@gmail.com> wrote: > On Wed, Mar 30, 2016 at 4:40 AM, NeilBrown <neilb@suse.com> wrote: >> On Wed, Mar 30 2016, Yan, Zheng wrote: >> >>> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >>>> On Fri, Mar 25 2016, Ilya Dryomov wrote: >>>> >>>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>>>> >>>>>>> Hi Linus, >>>>>>> >>>>>>> Please pull the following Ceph patch from >>>>>>> >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>>>> >>>>>>> This is a final commit we missed to align the protocol compatibility with >>>>>>> the feature bits. It decodes a few extra fields in two different messages >>>>>>> and reports EIO when they are used (not yet supported). >>>>>>> >>>>>>> Thanks! >>>>>>> sage >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> Yan, Zheng (1): >>>>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>>>> >>>>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>>>> >>>>> Yes, that was the point of getting it merged into -rc7. >>>> >>>> I did wonder if that might be the case. >>>> >>>>> >>>>>> Because when I backported this patch (and many others) to some ancient >>>>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>>>> be the same value, then I must have some other backported issue to find >>>>>> and fix. >>>>> >>>>> It has to be backported in concert with changes that add support for >>>>> the other two bits. >>>> >>>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >>>> for different core code. >>>> >>>>> How did mount fail? >>>> >>>> "can't read superblock". >>>> dmesg contains >>>> >>>> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >>>> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >>>> [ 51.635312] ceph: problem parsing mds trace -5 >>>> [ 51.635317] ceph: mds parse_reply err -5 >>>> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >>>> >>>> then a hex dump of header:, front: footer: >>>> >>>> Maybe my MDS is causing the problem? It is based on v10.0.5 which >>>> contains >>>> >>>> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >>>> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >>>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >>>> >>>> in ceph_features.h i.e. two features using bit 58, but not >>>> FS_FILE_LAYOUT_V2 >>>> >>>> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? >>> >>> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade >>> to ceph 10.1.0 >>> >> >> Ahhh.. I do wonder at the point of feature flags if they don't let you >> run any client with any server... >> Is there a compatability matrix published somewhere? >> If I have to stay with 10.0.5 (I don't know yet), it is safe to use >> Linux-4.4 code? > > 10.0.* are all development cuts, we didn't even built packages for > some of them. 10.1.0 is the first release candidate. You can think of > 10.0.5 as a random pre-rc1 kernel snapshot, aimed at brave testers, so > you do want to upgrade. > > The reason it doesn't work is those three features are all defined to > the same value, but two of them got added earlier in the 10.0.* cycle. > CEPH_FEATURE_FS_FILE_LAYOUT_V2 came in last, after 10.0.5. A little more specifically: these feature bits do let you run any client with any "real release" of Ceph that we expect not-testers to be using. They *usually* work on our dev releases as well, but we've gotten stingier about it as we come close to running out of feature bits and are trying to pack more of them into the same actual bits (we're working on freeing them up as well, but got started a little later than is comfortable), while coordinating code merges between a few different places. You got unlucky here. -Greg ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-30 18:09 ` Gregory Farnum @ 2016-03-31 2:18 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-31 2:18 UTC (permalink / raw) To: Gregory Farnum, Ilya Dryomov Cc: Yan, Zheng, Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 4467 bytes --] On Thu, Mar 31 2016, Gregory Farnum wrote: > On Wed, Mar 30, 2016 at 1:04 AM, Ilya Dryomov <idryomov@gmail.com> wrote: >> On Wed, Mar 30, 2016 at 4:40 AM, NeilBrown <neilb@suse.com> wrote: >>> On Wed, Mar 30 2016, Yan, Zheng wrote: >>> >>>> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >>>>> On Fri, Mar 25 2016, Ilya Dryomov wrote: >>>>> >>>>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>>>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>>>>> >>>>>>>> Hi Linus, >>>>>>>> >>>>>>>> Please pull the following Ceph patch from >>>>>>>> >>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>>>>> >>>>>>>> This is a final commit we missed to align the protocol compatibility with >>>>>>>> the feature bits. It decodes a few extra fields in two different messages >>>>>>>> and reports EIO when they are used (not yet supported). >>>>>>>> >>>>>>>> Thanks! >>>>>>>> sage >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> Yan, Zheng (1): >>>>>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>>>>> >>>>>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>>>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>>>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>>>>> >>>>>> Yes, that was the point of getting it merged into -rc7. >>>>> >>>>> I did wonder if that might be the case. >>>>> >>>>>> >>>>>>> Because when I backported this patch (and many others) to some ancient >>>>>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>>>>> be the same value, then I must have some other backported issue to find >>>>>>> and fix. >>>>>> >>>>>> It has to be backported in concert with changes that add support for >>>>>> the other two bits. >>>>> >>>>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >>>>> for different core code. >>>>> >>>>>> How did mount fail? >>>>> >>>>> "can't read superblock". >>>>> dmesg contains >>>>> >>>>> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >>>>> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >>>>> [ 51.635312] ceph: problem parsing mds trace -5 >>>>> [ 51.635317] ceph: mds parse_reply err -5 >>>>> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >>>>> >>>>> then a hex dump of header:, front: footer: >>>>> >>>>> Maybe my MDS is causing the problem? It is based on v10.0.5 which >>>>> contains >>>>> >>>>> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >>>>> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >>>>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >>>>> >>>>> in ceph_features.h i.e. two features using bit 58, but not >>>>> FS_FILE_LAYOUT_V2 >>>>> >>>>> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? >>>> >>>> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade >>>> to ceph 10.1.0 >>>> >>> >>> Ahhh.. I do wonder at the point of feature flags if they don't let you >>> run any client with any server... >>> Is there a compatability matrix published somewhere? >>> If I have to stay with 10.0.5 (I don't know yet), it is safe to use >>> Linux-4.4 code? >> >> 10.0.* are all development cuts, we didn't even built packages for >> some of them. 10.1.0 is the first release candidate. You can think of >> 10.0.5 as a random pre-rc1 kernel snapshot, aimed at brave testers, so >> you do want to upgrade. >> >> The reason it doesn't work is those three features are all defined to >> the same value, but two of them got added earlier in the 10.0.* cycle. >> CEPH_FEATURE_FS_FILE_LAYOUT_V2 came in last, after 10.0.5. > > A little more specifically: these feature bits do let you run any > client with any "real release" of Ceph that we expect not-testers to > be using. They *usually* work on our dev releases as well, but we've > gotten stingier about it as we come close to running out of feature > bits and are trying to pack more of them into the same actual bits > (we're working on freeing them up as well, but got started a little > later than is comfortable), while coordinating code merges between a > few different places. You got unlucky here. > -Greg Thanks - you've been most helpful. I'll see if we can use 10.1.0 for the MDS etc. Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 @ 2016-03-31 2:18 ` NeilBrown 0 siblings, 0 replies; 14+ messages in thread From: NeilBrown @ 2016-03-31 2:18 UTC (permalink / raw) To: Gregory Farnum, Ilya Dryomov Cc: Yan, Zheng, Sage Weil, linux-kernel, Ceph Development [-- Attachment #1: Type: text/plain, Size: 4467 bytes --] On Thu, Mar 31 2016, Gregory Farnum wrote: > On Wed, Mar 30, 2016 at 1:04 AM, Ilya Dryomov <idryomov@gmail.com> wrote: >> On Wed, Mar 30, 2016 at 4:40 AM, NeilBrown <neilb@suse.com> wrote: >>> On Wed, Mar 30 2016, Yan, Zheng wrote: >>> >>>> On Wed, Mar 30, 2016 at 8:24 AM, NeilBrown <neilb@suse.com> wrote: >>>>> On Fri, Mar 25 2016, Ilya Dryomov wrote: >>>>> >>>>>> On Fri, Mar 25, 2016 at 5:02 AM, NeilBrown <neilb@suse.com> wrote: >>>>>>> On Sun, Mar 06 2016, Sage Weil wrote: >>>>>>> >>>>>>>> Hi Linus, >>>>>>>> >>>>>>>> Please pull the following Ceph patch from >>>>>>>> >>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >>>>>>>> >>>>>>>> This is a final commit we missed to align the protocol compatibility with >>>>>>>> the feature bits. It decodes a few extra fields in two different messages >>>>>>>> and reports EIO when they are used (not yet supported). >>>>>>>> >>>>>>>> Thanks! >>>>>>>> sage >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> Yan, Zheng (1): >>>>>>>> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support >>>>>>> >>>>>>> Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have >>>>>>> exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and >>>>>>> CEPH_FEATURE_CRUSH_TUNABLES5)?? >>>>>> >>>>>> Yes, that was the point of getting it merged into -rc7. >>>>> >>>>> I did wonder if that might be the case. >>>>> >>>>>> >>>>>>> Because when I backported this patch (and many others) to some ancient >>>>>>> enterprise kernel, it caused mounts to fail. If it really is meant to >>>>>>> be the same value, then I must have some other backported issue to find >>>>>>> and fix. >>>>>> >>>>>> It has to be backported in concert with changes that add support for >>>>>> the other two bits. >>>>> >>>>> I have everything from fs/ceph and net/ceph as of 4.5, with adjustments >>>>> for different core code. >>>>> >>>>>> How did mount fail? >>>>> >>>>> "can't read superblock". >>>>> dmesg contains >>>>> >>>>> [ 50.822479] libceph: client144098 fsid 2b73bc29-3e78-490a-8fc6-21da1bf901ba >>>>> [ 50.823746] libceph: mon0 192.168.1.122:6789 session established >>>>> [ 51.635312] ceph: problem parsing mds trace -5 >>>>> [ 51.635317] ceph: mds parse_reply err -5 >>>>> [ 51.635318] ceph: mdsc_handle_reply got corrupt reply mds0(tid:1) >>>>> >>>>> then a hex dump of header:, front: footer: >>>>> >>>>> Maybe my MDS is causing the problem? It is based on v10.0.5 which >>>>> contains >>>>> >>>>> #define CEPH_FEATURE_CRUSH_TUNABLES5 (1ULL<<58) /* chooseleaf stable mode */ >>>>> // duplicated since it was introduced at the same time as CEPH_FEATURE_CRUSH_TUN >>>>> #define CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (1ULL<<58) /* New, v7 encoding */ >>>>> >>>>> in ceph_features.h i.e. two features using bit 58, but not >>>>> FS_FILE_LAYOUT_V2 >>>>> >>>>> Should I expect Linux 4.5 to work with ceph 10.0.5 ?? >>>> >>>> Sorry, cephfs in linux 4.5 does not work with 10.0.5. Please upgrade >>>> to ceph 10.1.0 >>>> >>> >>> Ahhh.. I do wonder at the point of feature flags if they don't let you >>> run any client with any server... >>> Is there a compatability matrix published somewhere? >>> If I have to stay with 10.0.5 (I don't know yet), it is safe to use >>> Linux-4.4 code? >> >> 10.0.* are all development cuts, we didn't even built packages for >> some of them. 10.1.0 is the first release candidate. You can think of >> 10.0.5 as a random pre-rc1 kernel snapshot, aimed at brave testers, so >> you do want to upgrade. >> >> The reason it doesn't work is those three features are all defined to >> the same value, but two of them got added earlier in the 10.0.* cycle. >> CEPH_FEATURE_FS_FILE_LAYOUT_V2 came in last, after 10.0.5. > > A little more specifically: these feature bits do let you run any > client with any "real release" of Ceph that we expect not-testers to > be using. They *usually* work on our dev releases as well, but we've > gotten stingier about it as we come close to running out of feature > bits and are trying to pack more of them into the same actual bits > (we're working on freeing them up as well, but got started a little > later than is comfortable), while coordinating code merges between a > few different places. You got unlucky here. > -Greg Thanks - you've been most helpful. I'll see if we can use 10.1.0 for the MDS etc. Thanks, NeilBrown [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Ceph fixes for -rc7 2016-03-25 4:02 ` NeilBrown 2016-03-25 9:34 ` Ilya Dryomov @ 2016-03-28 2:12 ` Yan, Zheng 1 sibling, 0 replies; 14+ messages in thread From: Yan, Zheng @ 2016-03-28 2:12 UTC (permalink / raw) To: NeilBrown; +Cc: Sage Weil, Linus Torvalds, linux-kernel, ceph-devel On Fri, Mar 25, 2016 at 12:02 PM, NeilBrown <neilb@suse.com> wrote: > On Sun, Mar 06 2016, Sage Weil wrote: > >> Hi Linus, >> >> Please pull the following Ceph patch from >> >> git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus >> >> This is a final commit we missed to align the protocol compatibility with >> the feature bits. It decodes a few extra fields in two different messages >> and reports EIO when they are used (not yet supported). >> >> Thanks! >> sage >> >> >> ---------------------------------------------------------------- >> Yan, Zheng (1): >> ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support > > Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have > exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and > CEPH_FEATURE_CRUSH_TUNABLES5)?? > Because when I backported this patch (and many others) to some ancient > enterprise kernel, it caused mounts to fail. If it really is meant to > be the same value, then I must have some other backported issue to find > and fix. Yes, it's mean to be some value. For the mount failure, please make sure the MDS is compiled from the newest ceph code. Regards Yan, Zheng > > Thanks, > NeilBrown > > >> >> fs/ceph/addr.c | 4 ++++ >> fs/ceph/caps.c | 27 ++++++++++++++++++++++++--- >> fs/ceph/inode.c | 2 ++ >> fs/ceph/mds_client.c | 16 ++++++++++++++++ >> fs/ceph/mds_client.h | 1 + >> fs/ceph/super.h | 1 + >> include/linux/ceph/ceph_features.h | 1 + >> 7 files changed, 49 insertions(+), 3 deletions(-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [GIT PULL] Ceph fixes for -rc7
@ 2015-01-28 18:55 Sage Weil
0 siblings, 0 replies; 14+ messages in thread
From: Sage Weil @ 2015-01-28 18:55 UTC (permalink / raw)
To: torvalds; +Cc: ceph-devel, linux-kernel
Hi Linus,
Please pull the following two patches from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
These paches from Ilya finally squash a race condition with layered images
that he's been chasing for a while.
Thanks!
sage
----------------------------------------------------------------
Ilya Dryomov (2):
rbd: fix rbd_dev_parent_get() when parent_overlap == 0
rbd: drop parent_ref in rbd_dev_unprobe() unconditionally
drivers/block/rbd.c | 25 +++++++------------------
1 file changed, 7 insertions(+), 18 deletions(-)
^ permalink raw reply [flat|nested] 14+ messages in threadend of thread, other threads:[~2016-03-31 2:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-06 1:48 [GIT PULL] Ceph fixes for -rc7 Sage Weil 2016-03-25 4:02 ` NeilBrown 2016-03-25 9:34 ` Ilya Dryomov 2016-03-30 0:24 ` NeilBrown 2016-03-30 0:24 ` NeilBrown 2016-03-30 2:30 ` Yan, Zheng 2016-03-30 2:40 ` NeilBrown 2016-03-30 2:40 ` NeilBrown 2016-03-30 8:04 ` Ilya Dryomov 2016-03-30 18:09 ` Gregory Farnum 2016-03-31 2:18 ` NeilBrown 2016-03-31 2:18 ` NeilBrown 2016-03-28 2:12 ` Yan, Zheng -- strict thread matches above, loose matches on Subject: below -- 2015-01-28 18:55 Sage Weil
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.