- 29 Apr, 2019 40 commits
-
-
David Sterba authored
We can read fs_info from extent buffer and can drop it from the parameters. Signed-off-by:David Sterba <dsterba@suse.com>
-
Nikolay Borisov authored
None of the implementers of the submit_bio_hook use the bio_offset parameter, simply remove it. No functional changes. Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
-
Nikolay Borisov authored
The btree submit hook queues the async csum and forwards the bio_offset parameter passed to btree_submit_bio_hook. This is redundant since btree_submit_bio_start calls btree_csum_one_bio which doesn't use the offset at all. No functional changes. Reviewed-by:
-
Nikolay Borisov authored
Buffered writeback always calls btrfs_csum_one_bio with the last 2 arguments being 0 irrespective of what the bio_offset has been passed to btrfs_submit_bio_start. Make this apparent by explicitly passing 0 for bio_offset when calling btrfs_wq_submit_bio from btrfs_submit_bio_hook. This will allow for further simplifications down the line. No functional changes. Reviewed-by:
-
Nikolay Borisov authored
This function always uses the btree inode's io_tree. Stop taking the tree as a function argument and instead access it internally from read_extent_buffer_pages. No functional changes. Reviewed-by:
-
Nikolay Borisov authored
The only possible 'private_data' that is passed to this function is actually an inode. Make that explicit by changing the signature of the call back. No functional changes. Reviewed-by:
-
Nikolay Borisov authored
There is no need to use a typedef to define the type of the function and then use that to define the respective member in extent_io_ops. Define struct's member directly. No functional changes. Reviewed-by:
-
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Though the transaction is also availabe, it's not guaranteed to be non-NULL. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the block group cache structure and can drop it from the parameters. Signed-off-by: -
Filipe Manana authored
It used to be called from only two places (truncate path and releasing a transaction handle), but commits 28bad212 ("btrfs: fix truncate throttling") and db2462a6 ("btrfs: don't run delayed refs in the end transaction logic") removed their calls to this function, so it's not used anymore. Just remove it and all its helpers. Reviewed-by:
Qu Wenruo <wqu@suse.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Anand Jain authored
Previous patch made sure that btrfs_setxattr_trans() is called only when transaction NULL. Clean up btrfs_setxattr_trans() and drop the parameter. Signed-off-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
-
Anand Jain authored
When the caller has already created the transaction handle, btrfs_setxattr() will use it. Also adds assert in btrfs_setxattr(). Signed-off-by:
-
Anand Jain authored
btrfs_setxattr_trans() is called by 5 functions as below and all of them do updates. None of them would be roun on a read-only root. So its ok to remove the readonly root check here as it's a high-level conditon. 1. __btrfs_set_acl() btrfs_init_acl() btrfs_init_inode_security() 2. __btrfs_set_acl() btrfs_set_acl() 3. btrfs_set_prop() btrfs_set_prop_trans() / \ btrfs_ioctl_setflags() btrfs_xattr_handler_set_prop() 4. btrfs_xattr_handler_set() 5. btrfs_initxattrs() btrfs_xattr_security_init() btrfs_init_inode_security() Signed-off-by: -
Anand Jain authored
Preparatory patch, as we are going split the calls with and without transaction to use the respective btrfs_setxattr() and btrfs_setxattr_trans() functions. Export btrfs_setxattr() for calls outside of xattr.c. Signed-off-by:
-
Anand Jain authored
When trans is not NULL btrfs_setxattr() calls do_setxattr() directly with a check for readonly root. Rename do_setxattr() btrfs_setxattr() in preparation to call do_setxattr() directly instead. Preparatory patch, no functional changes. Signed-off-by:
-
Anand Jain authored
Rename btrfs_setxattr() to btrfs_setxattr_trans(), so that do_setxattr() can be renamed to btrfs_setxattr(). Preparatory patch, no functional changes. Signed-off-by:
-
Qu Wenruo authored
Unlike btrfs_tree_lock() and btrfs_tree_read_lock(), the remaining functions in locking.c will not sleep, thus doesn't make much sense to record their execution time. Those events are introduced mainly for user space tool to audit and detect lock leakage or dead lock. Signed-off-by:
-
Qu Wenruo authored
There are two tree lock events which can sleep: - btrfs_tree_read_lock() - btrfs_tree_lock() Sometimes we may need to look into the concurrency picture of the fs. For that case, we need the execution time of above two functions and the owner of @eb. Here we introduce a trace events for user space tools like bcc, to get the execution time of above two functions, and get detailed owner info where eBPF code can't. All the overhead is hidden behind the trace events, so if events are not enabled, there is no overhead. These trace events also output bytenr and generation, allow them to be pared with unlock events to pin down deadlock. Signed-off-by:
-
Filipe Manana authored
The member num_dirty_bgs of struct btrfs_transaction is not used anymore, it is set and incremented but nothing reads its value anymore. Its last read use was removed by commit 64403612 ("btrfs: rework btrfs_check_space_for_delayed_refs"). So just remove that member. Signed-off-by:
-
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by: -
David Sterba authored
We can read fs_info from the transaction and can drop it from the parameters. Signed-off-by:
-
