At Tue, 1 May 2012 14:55:18 -0400, Christoph Hellwig wrote: > > On Wed, May 02, 2012 at 03:18:01AM +0900, MORITA Kazutaka wrote: > > > The big question is if we want to limit it by sys->nr_copies too, my > > > patch did that because it makes little sense to create an object with > > > more redudancy if system objects like the inode don't have it. I think > > > > If nr_copies has a larger value than inode->nr_copies, it should be a > > bug. > > Right now they always should be the same, but in an environmen where we > allow setting a different level for VDI it could be lower. > > > Ideally, sys->nr_copies should be used only when setting > > inode->nr_copies in the case the user doesn't specify it. > > So I think allowing higher redundancy doesn't make much difference > > since sheep doesn't need to know the default redundancy level when > > processing I/Os, no? > > We'll need sys->nr_copies for reading the inode initially at least. I see your point. We cannot pass a larger nr_copies than the actual redundancy to read_object() because the function could try to read the object from a wrong node and return an error. If we allow any redundancy level, it is safe to read the inode from the first node of the consistent hash ring, so I think we should use 1 instead of sys->nr_copies for reading the vdi object initially. Or perhaps, it may be much simpler to use the same redundancy level (sys->nr_copies) for vdi objects even if users specify different levels. I'm not sure everyone can accept it, though. Thanks, Kazutaka |