On 11/09/2012 01:44 PM, Yehuda Sadeh wrote: > 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: . . . >>>> >>>> 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. I do think this lightning-fast, no-data-loss upgrade is a feature, and I don't think it would be hard at all to implement. -Alex -- 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
