Re: Crazy idea of cleanup the inode_record btrfsck things with SQL?

[Martin Steigerwald <Martin@lichtvoll.de>]

Hi Qu,

Am Dienstag, 2. Dezember 2014, 08:37:44 schrieb Qu Wenruo:
> -------- Original Message --------
> Subject: Re: Crazy idea of cleanup the inode_record btrfsck things with SQL?
> From: Austin S Hemmelgarn <ahferroin7@gmail.com>
> To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs
> <linux-btrfs@vger.kernel.org>
> Date: 2014年12月01日 20:53
> 
> > On 2014-11-30 20:58, Qu Wenruo wrote:
> >> [snipped]
> > 
> > So, I think this does a good job of highlighting one of the bigger
> > issues with btrfsck when it is compared to ext* and/or xfs. Despite
> > this being a problem, I really don't think using a rdbms is the way to
> > fix it, both for reasons outlined in other responses, and because fsck
> > should be as fast as possible when nothing is wrong with the fs.
> 
> Although I am not stick to the crazy idea, I think it is still needed to
> point out that,
> even btrfsck is ran on a clean btrfs, it still needs to iterate all the
> extents, metadata.
> So it may not be as fast as you thought even with the current implement.
> 
> Anyway thanks for the feedback.

As to my knowledge at some time xfs_repair struggled with memory issues as 
well. And the developers of it made an attempt at reducing memory usage. I 
think with e2fsck this has been an issue as well. So maybe might be an idea at 
the approaches the devs of these two filesystem checking tools used to reduce 
memory usage.

On the other hand it may be that XFS and Ext4 is just too different to BTRFS to 
adapt those approaches. But in the end they are all filesystems, so there may 
be enough similarities to port over some ideas.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7