summaryrefslogtreecommitdiffstats
path: root/fs/gfs2/recovery.c
diff options
context:
space:
mode:
authorAndreas Gruenbacher <agruenba@redhat.com>2018-03-29 06:50:32 -0700
committerBob Peterson <rpeterso@redhat.com>2018-03-29 06:50:32 -0700
commitfffb64127adc3eea6a19ceefdc88d171f68b9d34 (patch)
tree0e0f6d63493ff268d7472322af53f24fc0ac4a34 /fs/gfs2/recovery.c
parentbb491ce67aa7c1635e5ae4f2f304a7d13d3dbe71 (diff)
downloadlinux-stable-fffb64127adc3eea6a19ceefdc88d171f68b9d34.tar.gz
linux-stable-fffb64127adc3eea6a19ceefdc88d171f68b9d34.tar.bz2
linux-stable-fffb64127adc3eea6a19ceefdc88d171f68b9d34.zip
gfs2: Zero out fallocated blocks in fallocate_chunk
Instead of zeroing out fallocated blocks in gfs2_iomap_alloc, zero them out in fallocate_chunk, much higher up the call stack. This gets rid of gfs2's abuse of the IOMAP_ZERO flag as well as the gfs2 specific zeronew buffer flag. I can't think of a reason why zeroing out the blocks in gfs2_iomap_alloc would have any benefits: there is no additional locking at that level that would add protection to the newly allocated blocks. While at it, change fallocate over from gs2_block_map to gfs2_iomap_begin. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Bob Peterson <rpeterso@redhat.com> Acked-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/gfs2/recovery.c')
0 files changed, 0 insertions, 0 deletions