Bug 223783 - GFS2: Deallocate blocks in directory hash chains when empty
GFS2: Deallocate blocks in directory hash chains when empty
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: GFS-kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Robert Peterson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-22 09:10 EST by Steve Whitehouse
Modified: 2016-10-07 08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Early prototype patch (5.91 KB, patch)
2016-10-03 16:03 EDT, Robert Peterson
no flags Details | Diff
Second prototype patch - bug fixed (5.95 KB, patch)
2016-10-05 11:38 EDT, Robert Peterson
no flags Details | Diff
Ben's tool for creating 10000 files with the same hash value (157.68 KB, text/plain)
2016-10-07 08:20 EDT, Robert Peterson
no flags Details
Third prototype patch (5.95 KB, patch)
2016-10-07 08:21 EDT, Robert Peterson
no flags Details | Diff

  None (edit)
Description Steve Whitehouse 2007-01-22 09:10:46 EST
When an exhash directory has entries removed from it, leaving an otherwise empty
hash chain block, the block should be deallocated unless its the first block in
that particular hash chain.

Actually I suppose that it would be possible to remove that too, but the other
code paths would need to be updated to know what a zero pointer meant in the
hash table. Since there can be potentially several pointers to the same hashed
block, that would also need to be taken into account. So it might be simpler
(and we'd still get most of the benefit) to simply leave the first block in the
chain and only remove blocks which are empty and further down the chain.
Comment 1 Robert Peterson 2016-10-03 15:13:21 EDT
Reassigning to myself. I whipped up an untested prototype in
about an hour. I did this for the sake of speeding up deletes:
If we can ensure that all leaf chain blocks are deallocated at
the time a directory is removed, in theory, we can save ourselves
a lot of work reading in leaf blocks to deallocate them. Instead,
we can just create a matrix of leaf blocks to free, and free them,
making the process a lot quicker. If we do that, it would no
longer set leaf block pointers to 0 as it frees them. Some might
look at that as a file system integrity feature we'd be removing.
However, maybe someday we could leverage it to create an undelete
tool for gfs2.
Comment 2 Robert Peterson 2016-10-03 16:03 EDT
Created attachment 1206978 [details]
Early prototype patch

This is the early prototype patch I whipped up. It seems to work.
I ran a quick test where I restored the metadata set called
lots2.5million.meta.gz, which Ben was using for his nfs cookie
issue, so I'm reasonably sure it has leaf chain blocks.
An fsck.gfs2 afterward came up clean, and rmmod showed nothing
leftover for gfs2 in slab.
Comment 3 Robert Peterson 2016-10-05 11:38 EDT
Created attachment 1207635 [details]
Second prototype patch - bug fixed

This version fixes a bug, and it's been tested with lf_next
file systems.
Comment 4 Robert Peterson 2016-10-07 08:20 EDT
Created attachment 1208142 [details]
Ben's tool for creating 10000 files with the same hash value

This is Ben Marzinski's script for creating ten thousand files
all of which have the same gfs2 hash value. This forces GFS2
to use several "lf_next" chain leaf blocks.
Comment 5 Robert Peterson 2016-10-07 08:21 EDT
Created attachment 1208143 [details]
Third prototype patch

Almost the same as the previous patch, but the trans_add_meta
should technically be done before the buffer is modified.

Note You need to log in before you can comment on or make changes to this bug.