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 |