On 01/08/2014 09:33 AM, David Sterba wrote:
On Wed, Dec 18, 2013 at 04:07:28PM -0500, Josef Bacik wrote:
/*
- * btrfs_qgroup_record_ref is called when the ref is added or deleted. it puts
- * the modification into a list that's later used by btrfs_end_transaction to
- * pass the recorded modifications on to btrfs_qgroup_account_ref.
+ * Record a quota operation for processing later on.
+ * @trans: the transaction we are adding the delayed op to.
+ * @fs_info: the fs_info for this fs.
+ * @ref_root: the root of the reference we are acting on,
+ * @num_bytes: the number of bytes in the reference.
+ * @parent: if we are removing a shared ref then this will be set.
+ * @type: the type of operation this is.
+ *
+ * We just add it to our trans qgroup_ref_list and carry on and process these
+ * operations in order at some later point. If the reference root isn't a fs
+ * root then we don't bother with doing anything.
+ *
+ * MUST BE HOLDING THE REF LOCK.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*/
int btrfs_qgroup_record_ref(struct btrfs_trans_handle *trans,
- struct btrfs_delayed_ref_node *node,
- struct btrfs_delayed_extent_op *extent_op)
+ struct btrfs_fs_info *fs_info, u64 ref_root,
+ u64 bytenr, u64 num_bytes, u64 parent,
+ enum btrfs_qgroup_operation_type type)
{
- struct qgroup_update *u;
+ struct btrfs_qgroup_operation *oper;
+ int ret;
- BUG_ON(!trans->delayed_ref_elem.seq);
- u = kmalloc(sizeof(*u), GFP_NOFS);
- if (!u)
+ if (!is_fstree(ref_root) || !fs_info->quota_enabled)
+ return 0;
+
+ oper = kmalloc(sizeof(*oper), GFP_NOFS);
Must use GFP_ATOMIC then, ohterwise spits some warnings:
This is because I'm still holding the tree lock, the ref_lock is just a
range lock so you can allocate under it. I'll fix this up, thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
