Searched full:punching (Results 1 – 17 of 17) sorted by relevance
155 * punching a hole in private memory is destructive, i.e. in guest_test_explicit_conversion()226 * Test that PUNCH_HOLE actually frees memory by punching holes without doing a237 * punching holes in guest_memfd, i.e. shared mappings aren't needed. in guest_test_punch_hole()
35 * Punching out an extent from the middle of an existing extent can cause the
682 * since you need to be punching out the middle of an extent. in xfs_dir2_shrink_inode()
797 * set_blocksize changing i_blkbits/folio order and punching in blkdev_write_iter()852 * changing i_blkbits/folio order and punching out the pagecache. in blkdev_read_iter()
176 * punching a hole in the stripe extent: in btrfs_delete_raid_extent()
119 filesystems that support punching out folios below EOF.
1705 * Helper to calculate the punching pos and length in one run, we handle the1710 * - no record needs to be removed (hole-punching completed)1760 * both two cases mean the completion of hole punching. in ocfs2_calc_trunc_pos()
82 * calculated by creating the properly aligned inobt record and punching out
1351 * extent allocation racing at the edge of the range we are currently punching.1381 * resulting in always punching out the range from the EOF to the end of the
509 File truncation or hole punching forcibly unmaps the deleted pages from
359 /* Test punching a hole into a single RAID stripe-extent. */
999 * This is effectively punching a hole into the middle of a file.
2625 * synchronize with hole punching. But there are code paths in filemap_create_folio()
2767 /* Are we punching a hole beyond EOF? */ in ceph_fallocate()
2756 * For hole punching, we need to scoot all the in ext4_ext_rm_leaf()2932 * If we're punching, there's an extent to the right. in ext4_ext_remove_space()
4304 * page cache due to hole punching or zero range. Otherwise i_disksize update
4298 * hole punching doesn't need new metadata... This is needed especially in ext4_set_resv_clusters()