xfs
[Top] [All Lists]

Re: Superblock restore takes too long

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Superblock restore takes too long
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 20 Jul 2012 10:21:43 +1000
Cc: "Zak, Semion" <SZak@xxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
In-reply-to: <50082F28.8090905@xxxxxxxxxxx>
References: <5C7FE4A5ADF52D46989166B4083DFF8F21ECE1C6@xxxxxxxxxxxxxxxxxx> <50082F28.8090905@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Jul 19, 2012 at 11:00:40AM -0500, Eric Sandeen wrote:
> On 7/19/12 4:30 AM, Zak, Semion wrote:
> > Hi,
> > 
> > Corrupted Superblock restore takes too long because xfs_restore searches 
> > the disc for reserved Superblock.
> > 
> > Is it possible accelerate the search, for example by giving to xfs_restore 
> > some hint (reserved Superblock LBA)?
> > 
> 
> Often when I've seen this it's because the block device wasn't really even an 
> xfs filesystem, and the search went on forever.

Right, it has to read the entire disk to find it. it's slow to do
this. It could be sped up by using readahead rather than the current
"read 1MB, process buffer 512 bytes at a time, read 1MB, ...." so
that it runs at disk speed rather than processing latency speed, but
that's still pretty slow. i.e. it is slow because it is stupid.

Ideally, searching for a secondary superblock should check a
few places before resorting to a full disk search. e.g.:

        - at 1TB offset for large filesystems
        - for small devices at (size / 4) and (size / 16) to catch
          the two common default mkfs settings

and then if that fails search at the places where the first AG would
be located for a filesystem with 2, 3, 5, 6, 7..... AGs. That woul
dcut down on the search time immensely, and only if that fails would
it be necessary to do a full disk search.

Any takers?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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