tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

xfs: document another racy GC case in xfs_zoned_map_extent

Besides blocks being invalidated, there is another case when the original
mapping could have changed between querying the rmap for GC and calling
xfs_zoned_map_extent. Document it there as it took us quite some time
to figure out what is going on while developing the multiple-GC
protection fix.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

authored by

Christoph Hellwig and committed by
Carlos Maiolino 0db22d7e 83bac569

+8
+8
fs/xfs/xfs_zone_alloc.c
··· 246 246 * If a data write raced with this GC write, keep the existing data in 247 247 * the data fork, mark our newly written GC extent as reclaimable, then 248 248 * move on to the next extent. 249 + * 250 + * Note that this can also happen when racing with operations that do 251 + * not actually invalidate the data, but just move it to a different 252 + * inode (XFS_IOC_EXCHANGE_RANGE), or to a different offset inside the 253 + * inode (FALLOC_FL_COLLAPSE_RANGE / FALLOC_FL_INSERT_RANGE). If the 254 + * data was just moved around, GC fails to free the zone, but the zone 255 + * becomes a GC candidate again as soon as all previous GC I/O has 256 + * finished and these blocks will be moved out eventually. 249 257 */ 250 258 if (old_startblock != NULLFSBLOCK && 251 259 old_startblock != data.br_startblock)