- 06 Aug, 2018 40 commits
-
-
Nikolay Borisov authored
It can be referenced from the passed transaction handle, since it's always valid. Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Qu Wenruo <wqu@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com>
-
Nikolay Borisov authored
It can be referenced from the passed transaction handle, since it's always valid. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed block group. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from the passed block group. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from trans since the function is always called within a transaction. Signed-off-by:
-
Nikolay Borisov authored
It can be referenced from trans since the function is always called within a transaction. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
It can always be referneced from the passed transaction handle since it's always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
fs_info can be refenreced from the transaction handle, since it's always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
The argument is no longer used so remove it. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle so fs_info can be referenced from there. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function already takes a transaction which holds a reference to the fs_info struct. Use that reference and remove the extra arg. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
fs_info can be referenced from the transaction handle, which is always valid. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle so we can reference the fs_info from there. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where we can reference fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where we can reference the fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This argument is unused. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where the fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function always uses the leaf's extent_buffer which already contains a reference to the fs_info. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where the fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This argument is unused. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction from where the fs_info can be referenced. No functional change. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction handle from where fs_info can be referenced. So remove the redundant argument. No functional changes. Signed-off-by:
-
Nikolay Borisov authored
This function is always called with a valid transaction so there is no need to duplicate the fs_info, we can reference it directly from the trans handle. No functional changes. Signed-off-by:
-
Bart Van Assche authored
The C programming language does not allow to use preprocessor statements inside macro arguments (pr_info() is defined as a macro). Hence rework the pr_info() statement in btrfs_print_mod_info() such that it becomes compliant. This patch allows tools like sparse to analyze the BTRFS source code. Fixes: 62e85577 ("btrfs: convert printk(KERN_* to use pr_* calls") Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by:
-
Bart Van Assche authored
This patch avoids that the compiler complains that a fall-through annotation is missing when building with W=1. Signed-off-by:
-
Bart Van Assche authored
This patch avoids that building the BTRFS source code with smatch triggers complaints about inconsistent indenting. Signed-off-by:
-
Nikolay Borisov authored
Currently this function takes the root as an argument only to get the log_root from it. Simplify this by directly passing the log root from the caller. Also eliminate the fs_info local variable, since it's used only once, so directly reference it from the transaction handle. Signed-off-by:
-
David Sterba authored
The logic to check if the inode is already in the log can now be simplified since we always wait for the ordered extents to complete before deciding whether the inode needs to be logged. The big comment about it can go away too. CC: Filipe Manana <fdmanana@suse.com> Suggested-by:
Filipe Manana <fdmanana@suse.com> [ code and changelog copied from mail discussion ] Signed-off-by:
-
Josef Bacik authored
This is no longer used anywhere, remove all of it. Signed-off-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
-
Josef Bacik authored
We no longer use this list we've passed around so remove it everywhere. Also remove the extra checks for ordered/filemap errors as this is handled higher up now that we're waiting on ordered_extents before getting to the tree log code. Signed-off-by:
-
Josef Bacik authored
Since we are waiting on all ordered extents at the start of the fsync() path we don't need to wait on any logged ordered extents, and we don't need to look up the checksums on the ordered extents as they will already be on disk prior to getting here. Rework this so we're only looking up and copying the on-disk checksums for the extent range we care about. Signed-off-by:
-
Josef Bacik authored
There's a priority inversion that exists currently with btrfs fsync. In some cases we will collect outstanding ordered extents onto a list and only wait on them at the very last second. However this "very last second" falls inside of a transaction handle, so if we are in a lower priority cgroup we can end up holding the transaction open for longer than needed, so if a high priority cgroup is also trying to fsync() it'll see latency. Signed-off-by:
-
Nikolay Borisov authored
The comment wrongfully states that the owner parameter is the level of the parent block. In fact owner is the level of the current block and by adding 1 to it we can eventually get to the parent/root. Signed-off-by:
-
Nikolay Borisov authored
Here is a doc-only patch which tires to deobfuscate the terra-incognita that arguments for delayed refs are. Signed-off-by:
-
