[Sheepdog] [PATCH v4 3/6] fix a bug of copies calculation in delete_one()

[MORITA Kazutaka]

At Fri, 4 May 2012 13:31:48 -0400,
Christoph Hellwig wrote:
> 
> On Thu, May 03, 2012 at 06:25:46PM +0800, levin li wrote:
> > It tries to compare the nr_copies with inode->nr_copies,
> > but the inode has just been allocated, the nr_copies may
> > be zero or something random
> 
> I just saw this one went in.  As per the thread in reply to my version
> of that patch I still think we need to do the inode->nr_copies limiting
> after the first read.  Did anyone disagree with that rationale?
> 
> (Not that it matter in practice as long as inode->nr_copies is
> guaranteed to be the same as sys->nr_copies)

If we allow a different level of copies, I think we should limit the
nr_copies number in get_nr_copies(); get_nr_copies() should be
min(nr_zones, inode->nr_copies) instead of min(nr_zones, sys->nr_copies).
So, limiting the nr_copies outside of get_nr_copies() doesn't look
good to me.

When we don't know the number of inode->nr_copies (e.g. reading inode
for the first time), get_nr_copies() should return 1 because calling
read_object() with larger nr_copies than the actual reduncancy level
is not safe.

Thanks,

Kazutaka