* Re: changed rbd cp behavior in 0.53
[not found] ` <CAEP-4J8KFzUydCPs-neZaWn09GkrcMsJp1=8YO0+rQROVUOJhg@mail.gmail.com>
@ 2012-11-15 23:53 ` Dan Mick
2012-11-16 0:00 ` Andrey Korolyov
1 sibling, 0 replies; 6+ messages in thread
From: Dan Mick @ 2012-11-15 23:53 UTC (permalink / raw)
To: Deb Barba; +Cc: Andrey Korolyov, Josh Durgin, ceph-devel
It's a bit different with rbd, as there's no "current dir", but I do
tend to agree that "like every other place pool defaults, which means
'rbd' literally" is more correct. See my RFC from today:
"RFC: incompatible change to rbd tool behavior on copy"
On 11/15/2012 08:43 AM, Deb Barba wrote:
> This is not common UNIX/posix behavior.
>
> if you just give the source a file name, it should assume "." (current
> directory) as it's location, not whatever path you started from.
>
> I would expect most UNIX users would be losing a lot of files if they
> try to copy from path x/y/z, and just provide a new name. that would
> indicate they wanted it stashed in ".". Not cloned in path x/y/z .
>
> I am concerned this would confuse most users out in the field.
>
> Thanks,
> Deborah Barba
>
> On Wed, Nov 14, 2012 at 10:43 PM, Andrey Korolyov <andrey@xdel.ru
> <mailto:andrey@xdel.ru>> wrote:
>
> On Thu, Nov 15, 2012 at 4:56 AM, Dan Mick <dan.mick@inktank.com
> <mailto:dan.mick@inktank.com>> wrote:
> >
> >
> > On 11/12/2012 02:47 PM, Josh Durgin wrote:
> >>
> >> On 11/12/2012 08:30 AM, Andrey Korolyov wrote:
> >>>
> >>> Hi,
> >>>
> >>> For this version, rbd cp assumes that destination pool is the
> same as
> >>> source, not 'rbd', if pool in the destination path is omitted.
> >>>
> >>> rbd cp install/img testimg
> >>> rbd ls install
> >>> img testimg
> >>>
> >>>
> >>> Is this change permanent?
> >>>
> >>> Thanks!
> >>
> >>
> >> This is a regression. The previous behavior will be restored for
> 0.54.
> >> I added http://tracker.newdream.net/issues/3478 to track it.
> >
> >
> > Actually, on detailed examination, it looks like this has been
> the behavior
> > for a long time; I think the wiser course would be not to change this
> > defaulting. One could argue the value of such defaulting, but
> it's also
> > true that you can specify the source and destination pools
> explicitly.
> >
> > Andrey, any strong objection to leaving this the way it is?
>
> I`m not complaining - this behavior seems more logical in the first
> place and of course I use full path even doing something by hand.
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> <mailto:majordomo@vger.kernel.org>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: changed rbd cp behavior in 0.53
[not found] ` <CAEP-4J8KFzUydCPs-neZaWn09GkrcMsJp1=8YO0+rQROVUOJhg@mail.gmail.com>
2012-11-15 23:53 ` Dan Mick
@ 2012-11-16 0:00 ` Andrey Korolyov
1 sibling, 0 replies; 6+ messages in thread
From: Andrey Korolyov @ 2012-11-16 0:00 UTC (permalink / raw)
To: Deb Barba; +Cc: Dan Mick, Josh Durgin, ceph-devel
On Thu, Nov 15, 2012 at 8:43 PM, Deb Barba <deb.barba@inktank.com> wrote:
> This is not common UNIX/posix behavior.
>
> if you just give the source a file name, it should assume "." (current
> directory) as it's location, not whatever path you started from.
>
> I would expect most UNIX users would be losing a lot of files if they try to
> copy from path x/y/z, and just provide a new name. that would indicate they
> wanted it stashed in ".". Not cloned in path x/y/z .
>
> I am concerned this would confuse most users out in the field.
>
> Thanks,
> Deborah Barba
Speaking of standards, rbd layout is more closely to /dev layout, or,
at least iSCSI targets, when not specifying full path or use some
predefined default prefix make no sense at all.
>
> On Wed, Nov 14, 2012 at 10:43 PM, Andrey Korolyov <andrey@xdel.ru> wrote:
>>
>> On Thu, Nov 15, 2012 at 4:56 AM, Dan Mick <dan.mick@inktank.com> wrote:
>> >
>> >
>> > On 11/12/2012 02:47 PM, Josh Durgin wrote:
>> >>
>> >> On 11/12/2012 08:30 AM, Andrey Korolyov wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> For this version, rbd cp assumes that destination pool is the same as
>> >>> source, not 'rbd', if pool in the destination path is omitted.
>> >>>
>> >>> rbd cp install/img testimg
>> >>> rbd ls install
>> >>> img testimg
>> >>>
>> >>>
>> >>> Is this change permanent?
>> >>>
>> >>> Thanks!
>> >>
>> >>
>> >> This is a regression. The previous behavior will be restored for 0.54.
>> >> I added http://tracker.newdream.net/issues/3478 to track it.
>> >
>> >
>> > Actually, on detailed examination, it looks like this has been the
>> > behavior
>> > for a long time; I think the wiser course would be not to change this
>> > defaulting. One could argue the value of such defaulting, but it's also
>> > true that you can specify the source and destination pools explicitly.
>> >
>> > Andrey, any strong objection to leaving this the way it is?
>>
>> I`m not complaining - this behavior seems more logical in the first
>> place and of course I use full path even doing something by hand.
>> --
>> 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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread