/usr/bin/cephfs tool

/usr/bin/cephfs tool

[Sage Weil]

Should we drop this entirely in hammer?  If I remember correctly all of 
the layout stuff is fully supported using virtual xattrs and standard 
tools.  The only thing left is the tool that shows you how file blocks map 
to objects map to OSDs (or something like that), which I've never used and 
have never seen anyone use...

sage

Re: /usr/bin/cephfs tool

[Wido den Hollander]

On 01/09/2015 04:20 PM, Sage Weil wrote:
> Should we drop this entirely in hammer?  If I remember correctly all of 
> the layout stuff is fully supported using virtual xattrs and standard 
> tools.  The only thing left is the tool that shows you how file blocks map 
> to objects map to OSDs (or something like that), which I've never used and 
> have never seen anyone use...
> 

I'm in favor of dropping it! It confused me a couple of weeks ago since
I thought for a second that it was still the right way to go.

With CephFS becoming more mature in Hammer we should not encourage users
to use this deprecated tool.

They should use vxattrs from the beginning.

I'm +1 in dropping this tool entirely in Hammer.

> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Wido den Hollander
42on B.V.
Ceph trainer and consultant

Phone: +31 (0)20 700 9902
Skype: contact42on

Re: /usr/bin/cephfs tool

[Gregory Farnum]

On Fri, Jan 9, 2015 at 7:20 AM, Sage Weil <sweil@redhat.com> wrote:
> Should we drop this entirely in hammer?

Yes!

>  If I remember correctly all of
> the layout stuff is fully supported using virtual xattrs and standard
> tools.  The only thing left is the tool that shows you how file blocks map
> to objects map to OSDs (or something like that), which I've never used and
> have never seen anyone use...

...oh, hmmm. Actually there have been people using that tool
occasionally over the years, and I don't think we provide any other
way to learn that information (besides calculating it yourself,
obviously).
Perhaps we could extend the vxattr interface to include that
information as well?
-Greg

Re: /usr/bin/cephfs tool

[Sage Weil]

On Fri, 9 Jan 2015, Gregory Farnum wrote:
> On Fri, Jan 9, 2015 at 7:20 AM, Sage Weil <sweil@redhat.com> wrote:
> > Should we drop this entirely in hammer?
> 
> Yes!
> 
> >  If I remember correctly all of
> > the layout stuff is fully supported using virtual xattrs and standard
> > tools.  The only thing left is the tool that shows you how file blocks map
> > to objects map to OSDs (or something like that), which I've never used and
> > have never seen anyone use...
> 
> ...oh, hmmm. Actually there have been people using that tool
> occasionally over the years, and I don't think we provide any other
> way to learn that information (besides calculating it yourself,
> obviously).
> Perhaps we could extend the vxattr interface to include that
> information as well?

Actually, I think Andreas's librados stuff he's working on may be the 
right path... it'll expose general information about object -> pg -> 
osd mappings.  Then a simple script could take the ino + file size, turn 
it into object names, and use that.

In any case, I don't mind nuking this and waiting for a complaint before 
investing in replacing that bit of functionality since it's such a small 
thing...

sage

Re: /usr/bin/cephfs tool

[Gregory Farnum]

On Fri, Jan 9, 2015 at 10:00 AM, Sage Weil <sweil@redhat.com> wrote:
> On Fri, 9 Jan 2015, Gregory Farnum wrote:
>> On Fri, Jan 9, 2015 at 7:20 AM, Sage Weil <sweil@redhat.com> wrote:
>> > Should we drop this entirely in hammer?
>>
>> Yes!
>>
>> >  If I remember correctly all of
>> > the layout stuff is fully supported using virtual xattrs and standard
>> > tools.  The only thing left is the tool that shows you how file blocks map
>> > to objects map to OSDs (or something like that), which I've never used and
>> > have never seen anyone use...
>>
>> ...oh, hmmm. Actually there have been people using that tool
>> occasionally over the years, and I don't think we provide any other
>> way to learn that information (besides calculating it yourself,
>> obviously).
>> Perhaps we could extend the vxattr interface to include that
>> information as well?
>
> Actually, I think Andreas's librados stuff he's working on may be the
> right path... it'll expose general information about object -> pg ->
> osd mappings.  Then a simple script could take the ino + file size, turn
> it into object names, and use that.
>
> In any case, I don't mind nuking this and waiting for a complaint before
> investing in replacing that bit of functionality since it's such a small
> thing...

Yeah, that's fine with me, but I'd like some idea of how we'd suggest
any users who complain do the implementation so we can point them at a
ticket if they do complain. ;)
-Greg

Re: /usr/bin/cephfs tool

[Sage Weil]

On Fri, 9 Jan 2015, Gregory Farnum wrote:
> On Fri, Jan 9, 2015 at 10:00 AM, Sage Weil <sweil@redhat.com> wrote:
> > On Fri, 9 Jan 2015, Gregory Farnum wrote:
> >> On Fri, Jan 9, 2015 at 7:20 AM, Sage Weil <sweil@redhat.com> wrote:
> >> > Should we drop this entirely in hammer?
> >>
> >> Yes!
> >>
> >> >  If I remember correctly all of
> >> > the layout stuff is fully supported using virtual xattrs and standard
> >> > tools.  The only thing left is the tool that shows you how file blocks map
> >> > to objects map to OSDs (or something like that), which I've never used and
> >> > have never seen anyone use...
> >>
> >> ...oh, hmmm. Actually there have been people using that tool
> >> occasionally over the years, and I don't think we provide any other
> >> way to learn that information (besides calculating it yourself,
> >> obviously).
> >> Perhaps we could extend the vxattr interface to include that
> >> information as well?
> >
> > Actually, I think Andreas's librados stuff he's working on may be the
> > right path... it'll expose general information about object -> pg ->
> > osd mappings.  Then a simple script could take the ino + file size, turn
> > it into object names, and use that.
> >
> > In any case, I don't mind nuking this and waiting for a complaint before
> > investing in replacing that bit of functionality since it's such a small
> > thing...
> 
> Yeah, that's fine with me, but I'd like some idea of how we'd suggest
> any users who complain do the implementation so we can point them at a
> ticket if they do complain. ;)

Email thread subject:

RFC: new rados whereis command

Earlier pull requests:

https://github.com/ceph/ceph/pull/2729
https://github.com/ceph/ceph/pull/2730

There isn't a redmine ticket since it originated as a PR.

sage

Re: /usr/bin/cephfs tool

[Gregory Farnum]

On Fri, Jan 9, 2015 at 10:08 AM, Sage Weil <sweil@redhat.com> wrote:
> On Fri, 9 Jan 2015, Gregory Farnum wrote:
>> On Fri, Jan 9, 2015 at 10:00 AM, Sage Weil <sweil@redhat.com> wrote:
>> > On Fri, 9 Jan 2015, Gregory Farnum wrote:
>> >> On Fri, Jan 9, 2015 at 7:20 AM, Sage Weil <sweil@redhat.com> wrote:
>> >> > Should we drop this entirely in hammer?
>> >>
>> >> Yes!
>> >>
>> >> >  If I remember correctly all of
>> >> > the layout stuff is fully supported using virtual xattrs and standard
>> >> > tools.  The only thing left is the tool that shows you how file blocks map
>> >> > to objects map to OSDs (or something like that), which I've never used and
>> >> > have never seen anyone use...
>> >>
>> >> ...oh, hmmm. Actually there have been people using that tool
>> >> occasionally over the years, and I don't think we provide any other
>> >> way to learn that information (besides calculating it yourself,
>> >> obviously).
>> >> Perhaps we could extend the vxattr interface to include that
>> >> information as well?
>> >
>> > Actually, I think Andreas's librados stuff he's working on may be the
>> > right path... it'll expose general information about object -> pg ->
>> > osd mappings.  Then a simple script could take the ino + file size, turn
>> > it into object names, and use that.
>> >
>> > In any case, I don't mind nuking this and waiting for a complaint before
>> > investing in replacing that bit of functionality since it's such a small
>> > thing...
>>
>> Yeah, that's fine with me, but I'd like some idea of how we'd suggest
>> any users who complain do the implementation so we can point them at a
>> ticket if they do complain. ;)
>
> Email thread subject:
>
> RFC: new rados whereis command
>
> Earlier pull requests:
>
> https://github.com/ceph/ceph/pull/2729
> https://github.com/ceph/ceph/pull/2730
>
> There isn't a redmine ticket since it originated as a PR.

Sorry, I meant the actual FS location bit, which isn't part of that
PR. ;) The "fancy" bit is integrating transparently with the FS
striping strategy, which is a little finicky to get right in a script
right now (though possible) but could definitely change in the future.

Anyway, I'm on board with ripping the cephfs tool out of the system.