Re: changed rbd cp behavior in 0.53

[Dan Mick <dan.mick@inktank.com>]

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
>
>