Re: problem with latest xfsprogs progress code

[David Chatterton <chatz@melbourne.sgi.com>]

Eric Sandeen wrote:
> Klaus Strebel wrote:
> 
>>>> Running 2.8.18 xfs_repair on a largeish (65TB, ~70M inodes) filesystem on
>>>> an x86_64 machine gives the following "progress" output:
>>>>
>>>> 12:15:36: process known inodes and inode discovery - 1461632 of 0 inod
>>>> es done
>>>> 12:15:36: Phase 3: elapsed time 14 minutes, 32 seconds - processed 100
>>>> 571 inodes per minute
>>>> 12:15:36: Phase 3: 0% done - estimated remaining time 3364 weeks, 3 da
>>>> ys, 7 hours, 30 minutes, 45 seconds
>>>>
>>>> Is this a known bug?
>> Hi James,
>>
>> why do you think that this is a bug? You have an almost infinitely large
>> filesystem, so the file-system check will also run for an almost
>> infinitely long time ;-).
>>
>> You see, not all that's possible is really desirable.
> 
> Well, while 65TB is impressive*, and repairing it quickly is indeed a
> challenge, it probably still should not take 64+ years.  ;-)
> 
> Sounds like something is in fact going wrong.
> 
> -Eric
> 
> *it amuses me to see xfs users refer to nearly 100T as largeISH; clearly
>  you all do not suffer from lowered expectations.  :)
> 

Barry is at linux.conf.au this week, he knows this code better than
anyone else.

Phase 3 is scanning the inodes in each allocation group, building up a
map of filesystem blocks that are marked as used.

See http://oss.sgi.com/projects/xfs/training/xfs_slides_11_repair.pdf

Scanning an AG and its inodes should not be taking this long.
Are you under memory pressure and the machine is just swapping to death?
Are you seeing I/O errors on the storage?
Is the storage using AVT mode and the luns are flipping between controllers?


Thanks,

David

-- 
David Chatterton
XFS Engineering Manager
SGI Australia