xfs_repair memory optimization
PATCH 1/1 xfs_repair memory optimization
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
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Mark Goodwin
A known limitation of
xfs_repairis 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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Christoph Hellwig
Quoted 6 lines · Mark Goodwin
A known limitation of
xfs_repairis 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 ;-)
Quoted 1 line
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.
Quoted 4 lines
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?
Quoted 1 line
The btree implementation btw worries me a little,
all XFS btree implementations continue to be bit of a worry :)
Quoted 2 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs