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.
> *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
Phase 3 is scanning the inodes in each allocation group, building up a
map of filesystem blocks that are marked as used.
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?
XFS Engineering Manager