On Thu, Dec 11, 2014 at 11:54:03AM -0600, Eric Sandeen wrote: > Eryu pointed out that in fstest xfs/071, we find corruption > reported at the end. This test attempts to do IO at the > maximum possible offsets, and repair yields: > > inode 1027 - extent offset too large - start 70, count 1, offset 2251799813685247 > correcting nextents for inode 1027 > bad data fork in inode 1027 > would have cleared inode 1027 > > Repair is complaining that an extent *starts* at the maximum > block, but AFAICT, starting there is just fine, as long as > we also end there. i.e. a one-block extent at the limit > is just fine. > > So change the xfs_repair test to allow this situation. > > Reported-by: Eryu Guan <eguan@xxxxxxxxxx> > Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > --- Thought this looked familiar: http://oss.sgi.com/archives/xfs/2014-09/msg00524.html Either one is fine with me. If we use the fix below, I think we should update the error message since it technically refers to the extent offset and we slightly tweak the meaning of the failure. Brian > > diff --git a/repair/dinode.c b/repair/dinode.c > index 38a6562..ca57a61 100644 > --- a/repair/dinode.c > +++ b/repair/dinode.c > @@ -667,7 +667,9 @@ _("inode %" PRIu64 " - bad extent overflows - start %" PRIu64 ", " > irec.br_startoff); > goto done; > } > - if (irec.br_startoff >= fs_max_file_offset) { > + /* Ensure this extent does not extend beyond the max offset */ > + if (irec.br_startoff + irec.br_blockcount - 1 > > + fs_max_file_offset) { > do_warn( > _("inode %" PRIu64 " - extent offset too large - start %" PRIu64 ", " > "count %" PRIu64 ", offset %" PRIu64 "\n"), > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
