Skip to content

Commit 7558c8b

Browse files
fdmananamasoncl
authored andcommitted
Btrfs: don't attach unnecessary extents to transaction on fsync
We don't need to attach ordered extents that have completed to the current transaction. Doing so only makes us hold memory for longer than necessary and delaying the iput of the inode until the transaction is committed (for each created ordered extent we do an igrab and then schedule an asynchronous iput when the ordered extent's reference count drops to 0), preventing the inode from being evictable until the transaction commits. Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: Chris Mason <[email protected]>
1 parent b659ef0 commit 7558c8b

File tree

1 file changed

+15
-1
lines changed

1 file changed

+15
-1
lines changed

fs/btrfs/ordered-data.c

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -502,7 +502,21 @@ void btrfs_wait_logged_extents(struct btrfs_trans_handle *trans,
502502
wait_event(ordered->wait, test_bit(BTRFS_ORDERED_IO_DONE,
503503
&ordered->flags));
504504

505-
list_add_tail(&ordered->trans_list, &trans->ordered);
505+
/*
506+
* If our ordered extent completed it means it updated the
507+
* fs/subvol and csum trees already, so no need to make the
508+
* current transaction's commit wait for it, as we end up
509+
* holding memory unnecessarily and delaying the inode's iput
510+
* until the transaction commit (we schedule an iput for the
511+
* inode when the ordered extent's refcount drops to 0), which
512+
* prevents it from being evictable until the transaction
513+
* commits.
514+
*/
515+
if (test_bit(BTRFS_ORDERED_COMPLETE, &ordered->flags))
516+
btrfs_put_ordered_extent(ordered);
517+
else
518+
list_add_tail(&ordered->trans_list, &trans->ordered);
519+
506520
spin_lock_irq(&log->log_extents_lock[index]);
507521
}
508522
spin_unlock_irq(&log->log_extents_lock[index]);

0 commit comments

Comments
 (0)