On Tue, Feb 24, 2015 at 08:36:52AM -0500, Brian Foster wrote: > On Tue, Feb 24, 2015 at 06:12:24PM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > In secondary_sb_wack() we zero the unused portion of both the > > on-disk superblock and the in-memory copy that we have. When > > the device sector size is 4k, this causes xfs_repair to crash like > > so: > > > > # xfs_repair /dev/ram1 > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - zero log... > > - scan filesystem freespace and inode maps... > > bad magic number > > bad on-disk superblock 3 - bad magic number > > primary/secondary superblock 3 conflict - AG superblock geometry info conflicts with filesystem geometry > > zeroing unused portion of secondary superblock (AG #3) > > # > > > > The stack trace is indicative: > > > > #0 memset () > > #1 0x000000000040404b in secondary_sb_wack > > #2 verify_set_agheader > > #3 0x0000000000427b4b in scan_ag > > #4 0x000000000042a2ca in worker_thread > > #5 0x00007ffff77ba0a4 in start_thread > > #6 0x00007ffff74efc2d in clone > > > > Which points at memset overrunning the in memory buffer, as it is > > only 512 bytes in length. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > --- > > The patch subject line should probably say 'xfsprogs:' or 'repair:,' > otherwise this looks good to me: Right, my mistake. > Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx> Thanks, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
