gfs2: Ignore journal log writes for jdata holes
When flushing out its ail1 list, gfs2_write_jdata_page calls function __block_write_full_page passing in function gfs2_get_block_noalloc. But there was a problem when a process wrote to a jdata file, then truncated it or punched a hole, leaving references to the blocks within the new hole in its ail list, which are to be written to the journal log. In writing them to the journal, after calling gfs2_block_map, function gfs2_get_block_noalloc determined that the (hole-punched) block was not mapped, so it returned -EIO to generic_writepages, which passed it back to gfs2_ail1_start_one. This, in turn, performed a withdraw, assuming there was a real IO error writing to the journal. This might be a valid error when writing metadata to the journal, but for journaled data writes, it does not warrant a withdraw. This patch adds a check to function gfs2_block_map that makes an exception for journaled data writes that correspond to jdata holes: If the iomap get function returns a block type of IOMAP_HOLE, it instead returns -ENODATA which does not cause the withdraw. Other errors are returned as before. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
This commit is contained in:
parent
a6645745d4
commit
b2a846dbef
@ -1301,8 +1301,12 @@ int gfs2_block_map(struct inode *inode, sector_t lblock,
|
||||
trace_gfs2_bmap(ip, bh_map, lblock, create, 1);
|
||||
|
||||
ret = gfs2_iomap_get(inode, pos, length, flags, &iomap, &mp);
|
||||
if (create && !ret && iomap.type == IOMAP_HOLE)
|
||||
ret = gfs2_iomap_alloc(inode, &iomap, &mp);
|
||||
if (!ret && iomap.type == IOMAP_HOLE) {
|
||||
if (create)
|
||||
ret = gfs2_iomap_alloc(inode, &iomap, &mp);
|
||||
else
|
||||
ret = -ENODATA;
|
||||
}
|
||||
release_metapath(&mp);
|
||||
if (ret)
|
||||
goto out;
|
||||
|
Loading…
Reference in New Issue
Block a user