xfs resize: primary superblock is not updated immediately

Eric Sandeen sandeen at sandeen.net
Sun Mar 6 09:46:30 CST 2016


> On Mar 6, 2016, at 3:46 AM, Alex Lyakas <alex at zadarastorage.com> wrote:
> 
> Hello Dave,
> 
>> On Thu, Mar 3, 2016 at 11:31 PM, Dave Chinner <david at fromorbit.com> wrote:
>>> On Thu, Mar 03, 2016 at 11:18:43AM +0200, Alex Lyakas wrote:
>>> Hello Dave,
>>> Thanks for the patch! I confirm that it fixes the scenario.
>>> 
>>> At [1] please find all the blknos that are being used during the log
>>> recovery (if that's of any interest).
>> ....
>>> Mar  3 11:17:41 vc-00-00-350-dev kernel: [   68.129739]
>>> _xfs_buf_find: blkno=200705 eofs=204800 >m_sb.sb_dblocks=25600
>>> Mar  3 11:17:41 vc-00-00-350-dev kernel: [   68.129746]
>>> _xfs_buf_find: blkno=200705 eofs=204800 >m_sb.sb_dblocks=25600
>> 
>> Where is the warning that this block is out of range?
> Perhaps you are being confused by the ">" mark that appears in the
> prints? This was definitely added by mistake, it appears on every
> print. I apologize for that.
> If not, then my understanding is that 200705 is still less than
> 204800, so this block number is not out of range. And since we have
> added the new pag structure, the issue is now fixed.

Block units in printks are never clear; 204800 sectors is 25600 4K blocks, and yes, the buffer at sector 200705 looks to be in range of the filesystem.

Eric

> Otherwise, I can provide an XFS metadump for you to analyze.
> 
> Thanks,
> Alex.
> 
>> 
>> And why didn't recovery fail at this point because the block
>> requested is out of range and so the buffer lookup should have
>> failed?
>> 
>> Cheers,
>> 
>> Dave.
>> --
>> Dave Chinner
>> david at fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 



More information about the xfs mailing list