xfs
[Top] [All Lists]

Re: problem with latest xfsprogs progress code

To: jamesb@xxxxxxxxxxxx
Subject: Re: problem with latest xfsprogs progress code
From: David Chatterton <chatz@xxxxxxxxxxxxxxxxx>
Date: Thu, 18 Jan 2007 09:51:26 +1100
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Klaus Strebel <klaus.strebel@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <45AE46C2.6090005@xxxxxxxxxxx>
Organization: SGI
References: <32920.193.203.83.22.1168965042.squirrel@xxxxxxxxxxxxxxxxx> <53858.193.203.83.22.1169031614.squirrel@xxxxxxxxxxxxxxxxx> <45AE2DDF.5000602@xxxxxxx> <45AE46C2.6090005@xxxxxxxxxxx>
Reply-to: chatz@xxxxxxxxxxxxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

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


<Prev in Thread] Current Thread [Next in Thread>