[PATCH, needs new owner] xfs_repair memory optimization

[PATCH, needs new owner] xfs_repair memory optimization

[Mark Goodwin]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]


A known limitation of xfs_repair is the large amount of memory it
requires, depending on filesystem size and number of inodes, etc.

The attached patch series, originally by Barry Bnaujok, is close to
being finished but requires a new owner to do some final testing and
polishing. It applies cleanly against top-of-tree xfsprogs-3.0.0

Thanks
-- Mark

[-- Attachment #2: repair_memory_optimization.tgz --]
[-- Type: application/octet-stream, Size: 39334 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH, needs new owner] xfs_repair memory optimization

[Christoph Hellwig]

On Fri, Jan 23, 2009 at 01:09:32PM +1100, Mark Goodwin wrote:
>
> A known limitation of xfs_repair is the large amount of memory it
> requires, depending on filesystem size and number of inodes, etc.
>
> The attached patch series, originally by Barry Bnaujok, is close to
> being finished but requires a new owner to do some final testing and
> polishing. It applies cleanly against top-of-tree xfsprogs-3.0.0

I did a quick look over it on the plane today and it looks quite nice
to me.

I guess there are no patch descriptions left anywhere?

Otherwise some of the patch might need some minor polishing, e.g.
the patch moving over from the radix tree to the btree leaves the
radix-tree implementation in, which gets removed in the next patch
which has otherwise unrelated changes.

The btree implementation btw worries me a little, I wonder if we need
a test harness to make sure it's correct for all corner cases.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH, needs new owner] xfs_repair memory optimization

[Mark Goodwin]

Christoph Hellwig wrote:
> On Fri, Jan 23, 2009 at 01:09:32PM +1100, Mark Goodwin wrote:
>> A known limitation of xfs_repair is the large amount of memory it
>> requires, depending on filesystem size and number of inodes, etc.
>>
>> The attached patch series, originally by Barry Bnaujok, is close to
>> being finished but requires a new owner to do some final testing and
>> polishing. It applies cleanly against top-of-tree xfsprogs-3.0.0
>
> I did a quick look over it on the plane today and it looks quite nice
> to me.

that sounds promising, maybe we have a new owner for this code ;-)

> I guess there are no patch descriptions left anywhere?

The patch series as posted is straight out of Barry's workarea.
The only descriptions are the patch filenames themselves and what's
still in Barry head - you could email him and he may or may not
respond. I do know that he spent quite a lot of time benchmarking
and stressing this code - it should be fairly robust and close to
release quality.

> Otherwise some of the patch might need some minor polishing, e.g.
> the patch moving over from the radix tree to the btree leaves the
> radix-tree implementation in, which gets removed in the next patch
> which has otherwise unrelated changes.

well you could split the radix removal from the unrelated changes,
but the end result is the same, right?

> The btree implementation btw worries me a little, 

all XFS btree implementations continue to be bit of a worry :)

> I wonder if we need
> a test harness to make sure it's correct for all corner cases.

Would the test harness for the factored kernel btrees be adaptable to this
one in userspace? (or could the kernel btree code also be adapted/shared
for use in userspace too?)

BTW, I think Barry also had some changes underway to xfs_repair phase-1,
e.g. to detect missing volume manager pieces (and thus abort the repair
rather than make a dogs breakfast), better backup superblock searching,
etc. He also had plans for utilizing parent pointers, e.g. to practically
eliminate lost+found.

Cheers
-- Mark

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs