delayed inodes implementation questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,


I've been studying the implementation of the delayed inodes feature and
have a couple of questions.

1. Why are there 2 lists when each and every node is on both lists at
the same time? So if we happen to be running the async worker we are
processing nodes based on the prepared_list, at the same time if there
is a concurent transaction commit happening then the exact some nodes
are going to be processed from the node_list - it's not a functional
problem but the presence of 2 lists and each node being on the same list
at the same time just seems a bit redundant.

2. in btrfs_next_delayed_node can this code really trigger:

 if (!test_bit(BTRFS_DELAYED_NODE_IN_LIST, &node->flags)) {
                /* not in the list */

                if (list_empty(&delayed_root->node_list))

                        goto out;

                p = delayed_root->node_list.next;

In order for !test_bit(BTRFS_DELAYED_NODE_IN_LIST, &node->flags) to be
true this means this node should have been btrfs_dequeue_delayed_node
underneath us? Can this really happen e.g. have multiple concurrent
__btrfs_run_delayed_items executions?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux