[Sheepdog] [PATCH] sheep: fix nr_copies calculation in delete_one

[MORITA Kazutaka]

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