[Cluster-devel] [fsck.gfs2 v2 PATCH 00/40] fsck.gfs2: memory reduction patches

[Abhijith Das <adas@redhat.com>]

Hi,

Looks good to me. ACK.

Cheers!
--Abhi

----- Original Message -----
> From: "Bob Peterson" <rpeterso@redhat.com>
> To: "cluster-devel" <cluster-devel@redhat.com>
> Sent: Friday, May 6, 2016 12:38:53 PM
> Subject: [Cluster-devel] [fsck.gfs2 v2 PATCH 00/40] fsck.gfs2: memory	reduction patches
> 
> On 15 April, I posted a set of 30 patches for fsck.gfs2 to reduce its
> memory requirements. Since that time, I've been testing and fixing
> problems. Here is version 2.
> ---
> Right now, fsck.gfs2 is a memory hog with regard to very large file
> systems. A file system of 250TB would require an absurd about of memory.
> That's because it uses memory for (1) rgrp bitmaps, (2) its own internal
> blockmap, (3) a directory tree, and (4) a tree of ALL inodes in the
> file system, for reconciling link counts.
> 
> This series of 40 patches is designed to reduce the memory footprint
> of fsck.gfs2. It does so by almost entirely eliminating the inode
> tree in favor of two much smaller bitmaps. In order to do that, I
> rearranged the order in which things are done.
> 
> In order to save on memory, some things will be slower, so this will
> cause a performance hit to fsck.gfs2. However, I'm confident that
> we can fix them and make it fast again. The slowness is caused because
> most bitmap manipulation is now done on the bitmaps in the resource
> groups, which means the code needs to search out the rgrp for these
> operations. This can be optimized to pass in the rgrp, since it will
> be known in most cases (for example, pass1 operates on one rgrp at a
> time, and chances are quite good that the rgrp needed will be that one.)
> These further optimizations will be done in later patches.
> 
> I'm still testing these changes against my collection of gfs2 and gfs1
> metadata, but the results are good so far. So there may be changes.
> 
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>