Re: changed rbd cp behavior in 0.53

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx
<mailto:andrey@xxxxxxx>> wrote:

    On Thu, Nov 15, 2012 at 4:56 AM, Dan Mick <dan.mick@xxxxxxxxxxx
    <mailto:dan.mick@xxxxxxxxxxx>> 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@xxxxxxxxxxxxxxx
    <mailto: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


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux