On Fri, Nov 9, 2012 at 11:30 AM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > On 11/09/2012 11:08 AM, Yehuda Sadeh wrote: >> >> On Fri, Nov 9, 2012 at 11:04 AM, Josh Durgin <josh.durgin@xxxxxxxxxxx> >> wrote: >>> >>> On 11/09/2012 11:01 AM, Gregory Farnum wrote: >>>> >>>> >>>> I was asked today if there's a way to upgrade RBD volumes from v1 to >>>> v2. I didn't think so, but wanted >>>> 1) to make sure I'm right, >>>> 2) to ask how hard it would be, >>>> 3) to ask if we haven't done it because it didn't occur to us or >>>> because it's too hard. >>>> -Greg >>>> >>> >>> This was addressed in the original discussions about format 2. >>> >>> You need to export and then import the volume as format 2. Format 2 uses >>> different names for objects, so providing an 'upgrade' path would still >>> require copying all the data around. >>> >> Couldn't we just set a flag in the header specifying the object naming >> version, which would then only require updating the header? >> >> Yehuda > > > The header was separated from the id object to allow renames to work > while the image was in use or with cloning. The whole header format > changed and moved to a different object as a result. It would be > messy to implement this kind of upgrade, and doesn't provide much > benefit when there's an easy way to convert already. If someone really > wanted it, it could be implemented, but otherwise I don't think it's > worth adding. It would have to be added to the upcoming kernel > layering support too. > The assumption is that when you upgrade you don't go back, so the fact that the header was separated from the id object doesn't change much. An upgrade process would be the same as creating a new v2 image, having object names (prefix?) that set as the original object names, and with a version field that specifies that these are a v1 names. The problem that I see with converting v1 to v2 through copy is that (besides the cumbersome and potentially very long process) we will end up turning sparse data objects into fully written data objects, which will affect the data consumption. Yehuda -- 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
