Re: Btrfs Raid5 issue.

On Mon, Aug 21, 2017 at 11:19 PM, Robert LeBlanc wrote: > Chris and Qu thanks for your help. I was able to restore the data off > the volume. I only could not read one file that I tried to rsync (a > MySQl bin log), but it wasn't critical as I had an off-site snapshot > from

[PATCH] btrfs-progs: Make in-place exit to a common exit block

As comment pointed out by David, make in-place exit to a common exit block of mkfs. v1: Add some close(fd) when error occures in mkfs. And add close(fd) when end use it. Signed-off-by: Gu Jinxiang --- mkfs/main.c | 74

Re: Btrfs Raid5 issue.

Chris and Qu thanks for your help. I was able to restore the data off the volume. I only could not read one file that I tried to rsync (a MySQl bin log), but it wasn't critical as I had an off-site snapshot from that morning and ownclould could resync the files that were changed anyway. This

Re: btrfs corrupt message when mounting (but still mounts and no scrub errors.)

On Mon, Aug 21, 2017 at 10:55 PM, Rich Rauenzahn wrote: > I'm getting messages like this when mounting: > > [4.034300] BTRFS info (device sdg3): bdev /dev/sdg3 errs: wr 0, rd > 0, flush 0, corrupt 4, gen 0 > [4.034828] BTRFS info (device sdg3): bdev /dev/sdf3 errs: wr

btrfs corrupt message when mounting (but still mounts and no scrub errors.)

I'm getting messages like this when mounting: [4.034300] BTRFS info (device sdg3): bdev /dev/sdg3 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 [4.034828] BTRFS info (device sdg3): bdev /dev/sdf3 errs: wr 0, rd 0, flush 0, corrupt 68, gen 0 But it mounts fine, and scrub says it is fine: $

Re: BTRFS error (device sda4): failed to read chunk tree: -5

On 2017年08月18日 11:49, Qu Wenruo wrote: On 2017年08月18日 11:13, Zirconium Hacker wrote: I hope "Reply All" is the right option here. Again, first time interacting with a mailing list. Google said that was what to do. You're doing quite well, and yes, Reply All is the right option. I

[PATCH 1/2 RESEND] Btrfs: make plug in writing meta blocks really work

We have started plug in btrfs_write_and_wait_marked_extents() but the generated IOs actually go to device's schedule IO list where the work is doing in another task, thus the started plug doesn't make any sense. And since we wait for IOs immediately after writing meta blocks, it's the same case

[PATCH 2/2] Btrfs: remove bio_flags which indicates a meta block of log-tree

Since both committing transaction and writing log-tree are doing plugging on metadata IO, we can unify to use %sync_writers to benefit both cases, instead of checking bio_flags while writing meta blocks of log-tree. This removes the bio_flags related stuff for writing log-tree. Signed-off-by:

Re: [PATCH] Btrfs: make plug in writing meta blocks really work

On Mon, Aug 21, 2017 at 03:23:30PM -0400, Josef Bacik wrote: > On Mon, Aug 21, 2017 at 12:14:16PM -0700, Liu Bo wrote: > > On Mon, Aug 21, 2017 at 01:48:01PM -0400, Josef Bacik wrote: > > > On Fri, Aug 18, 2017 at 11:42:07AM -0600, Liu Bo wrote: > > > > We have started plug in

Re: [PATCH] Btrfs: make plug in writing meta blocks really work

On Mon, Aug 21, 2017 at 12:14:16PM -0700, Liu Bo wrote: > On Mon, Aug 21, 2017 at 01:48:01PM -0400, Josef Bacik wrote: > > On Fri, Aug 18, 2017 at 11:42:07AM -0600, Liu Bo wrote: > > > We have started plug in btrfs_write_and_wait_marked_extents() but the > > > generated IOs actually go to device's

Re: [PATCH] Btrfs: make plug in writing meta blocks really work

On Mon, Aug 21, 2017 at 01:48:01PM -0400, Josef Bacik wrote: > On Fri, Aug 18, 2017 at 11:42:07AM -0600, Liu Bo wrote: > > We have started plug in btrfs_write_and_wait_marked_extents() but the > > generated IOs actually go to device's schedule IO list where the work > > is doing in another task,

Re: [PATCH v2] btrfs: submit superblock io with REQ_META and REQ_PRIO

On Mon, Aug 21, 2017 at 05:42:27PM +0200, David Sterba wrote: > The superblock is also metadata of the filesystem so the relevant IO > should be tagged as such. We also tag it as high priority, as it's the > last block committed for metadata from a given transaction. Any delays > would effectively

Re: BTRFS warning (device dm-0): unhandled fiemap cache detected

On Mon, Aug 21, 2017 at 11:31:34AM +0800, Qu Wenruo wrote: > > > On 2017年08月21日 11:27, Christoph Anton Mitterer wrote: > > On Mon, 2017-08-21 at 10:43 +0800, Qu Wenruo wrote: > > > Harmless, it is only designed to merge fiemap output. > > Thanks for the info :) > > > > > > On Mon, 2017-08-21

Re: [PATCH] Btrfs: make plug in writing meta blocks really work

On Fri, Aug 18, 2017 at 11:42:07AM -0600, Liu Bo wrote: > We have started plug in btrfs_write_and_wait_marked_extents() but the > generated IOs actually go to device's schedule IO list where the work > is doing in another task, thus the started plug doesn't make any > sense. > > And since we wait

Re: [PATCH] btrfs-progs: mkfs: Replace number with enum

On Wed, Jun 28, 2017 at 05:59:24PM +0800, Gu Jinxiang wrote: > For code maintainability and scalability, > replace hardcoded constant with a meaningful enum. > > Signed-off-by: Gu Jinxiang Sorry for late reply. Patch applied with some tweaks, the added enum names are too

Re: [PATCH] Btrfs: do not async submit for nodatacsum inodes

On Fri, Aug 18, 2017 at 11:54:02AM -0600, Liu Bo wrote: > While we submit direct writes, if the inode is flagged with nodatasum, > there's no benefit to submit asynchronously, because > > a) we don't have to calculate checksum across processors, > > b) and direct IO has started a plug, but async

Re: [PATCH 00/10] Unused parameter cleanup

On Mon, Aug 21, 2017 at 12:43:40PM +0300, Nikolay Borisov wrote: > Hello, > > Here is a series that I've been sitting on for a while. It removes unused > parameter in various functions, no functional changes. Patch 09/10 reworks > some error handling to eliminate an if branch in

Re: [PATCH v2] btrfs: submit superblock io with REQ_META and REQ_PRIO

On Mon, Aug 21, 2017 at 05:42:27PM +0200, David Sterba wrote: > The superblock is also metadata of the filesystem so the relevant IO > should be tagged as such. We also tag it as high priority, as it's the > last block committed for metadata from a given transaction. Any delays > would effectively

Re: [PATCH 2/2] btrfs-progs: delete not-used parameter fd

On Fri, Aug 18, 2017 at 01:32:46AM -0700, Gu Jinxiang wrote: > Parameter fd is not used in function make_image and > traverse_directory of mkfs. > Delete it. > > Signed-off-by: Gu Jinxiang Apparently the parameter has never been used. Applied, thanks. -- To unsubscribe from

Re: [PATCH 1/2] btrfs-progs: add necessary close(fd) in mkfs

On Fri, Aug 18, 2017 at 01:32:45AM -0700, Gu Jinxiang wrote: > Add some close(fd) when error occures in mkfs. > And add close(fd) when end use it. Can you please rework it so all the in-place exists are gotos to a common exit block that does the close(fd) cleanup? Thanks. -- To unsubscribe from

Re: [PATCH] btrfs-progs: Allow inspect dump-tree to show specified tree block even some tree roots are corrupted

On Fri, Aug 18, 2017 at 06:36:30PM +0900, Qu Wenruo wrote: > For btrfs inspect-internal dump-tree, if we use "-b" parameter to show > specified tree block, then we don't really need extra tree roots. > > Only chunk root is needed to build up the whole chunk mapping so we can > read tree blocks. >

Re: [PATCH] btrfs-progs: Doc: Fix asciidoc grammar of btrfs-rescue

On Mon, Aug 21, 2017 at 03:57:04PM +0900, Qu Wenruo wrote: > Code block of kernel backtrace lacks leading change line, causing the > following man page result: > -- >One can determine whether zero-log is needed according to the >kernel backtrace: > >?

Re: [PATCH] btrfs: remove broken memory barrier

On Tue, Aug 01, 2017 at 06:25:56PM +0300, Nikolay Borisov wrote: > Commit 38851cc19adb ("Btrfs: implement unlocked dio write") implemented > unlocked dio write, allowing multiple dio writers to write to non-overlapping, > and non-eof-extending regions. In doing so it also introduced a broken

Re: Btrfs Raid5 issue.

On Mon, Aug 21, 2017 at 10:31 AM, Robert LeBlanc wrote: > Qu, > > Sorry, I'm not on the list (I was for a few years about three years ago). > > I looked at the backup roots like you mentioned. > > # ./btrfs inspect dump-super -f /dev/bcache0 > superblock: bytenr=65536,

Re: Btrfs Raid5 issue.

Qu, Sorry, I'm not on the list (I was for a few years about three years ago). I looked at the backup roots like you mentioned. # ./btrfs inspect dump-super -f /dev/bcache0 superblock: bytenr=65536, device=/dev/bcache0 - csum_type

Re: [PATCH 1/2] btrfs: Remove chunk_objectid parameter of btrfs_alloc_dev_extent

On Fri, Aug 18, 2017 at 05:58:22PM +0300, Nikolay Borisov wrote: > THe function is always called with chunk_objectid set to > BTRFS_FIRST_CHUNK_TREE_OBJECTID. Let's collapse the parameter in the function > itself. No functional changes > > Signed-off-by: Nikolay Borisov

Re: [PATCH 2/2] btrfs: remove superfluous chunk_tree argument from btrfs_alloc_dev_extent

On Fri, Aug 18, 2017 at 05:58:23PM +0300, Nikolay Borisov wrote: > Currently this function is always called with the object id of the root key of > the chunk_tree, which is always BTRFS_CHUNK_TREE_OBJECTID. So let's subsume it > straight into the function itself. No functional change. > >

Re: [PATCH] Btrfs: remove unnecessary skip_sum

On Fri, Aug 18, 2017 at 11:58:04AM -0600, Liu Bo wrote: > Now that we can get inode from dip->inode, it's not necessary to pass > skip_sum from callers. Already there, https://patchwork.kernel.org/patch/9879029/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body

Re: [PATCH v2] btrfs: pass fs_info to btrfs_del_root instead of tree_root

On Thu, Aug 17, 2017 at 10:25:11AM -0400, Jeff Mahoney wrote: > btrfs_del_roots always uses the tree_root. Let's pass fs_info instead. > > Signed-off-by: Jeff Mahoney Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe

[PATCH v2] btrfs: submit superblock io with REQ_META and REQ_PRIO

The superblock is also metadata of the filesystem so the relevant IO should be tagged as such. We also tag it as high priority, as it's the last block committed for metadata from a given transaction. Any delays would effectively block the whole transaction, also blocking any other operation

Re: [PATCH v3 0/7] add sanity check for extent inline ref type

On Fri, Aug 18, 2017 at 03:15:17PM -0600, Liu Bo wrote: > An invalid extent inline ref type could be read from a btrfs image and > it ends up with a panic[1], this set is to deal with the insane value > gracefully in patch 1-2 and clean up BUG() in the code in patch 3-6. > > Patch 7 adds one more

Re: [PATCH v3 7/7] Btrfs: add one more sanity check for shared ref type

On Fri, Aug 18, 2017 at 03:15:24PM -0600, Liu Bo wrote: > Every shared ref has a parent tree block, which can be get from > btrfs_extent_inline_ref_offset(). And the tree block must be aligned > to the nodesize, so we'd know this inline ref is not valid if this > block's bytenr is not aligned to

Re: [PATCH v3 6/7] Btrfs: remove BUG_ON in __add_tree_block

On Fri, Aug 18, 2017 at 03:15:23PM -0600, Liu Bo wrote: > The BUG_ON() can be triggered when the caller is processing an invalid > extent inline ref, e.g. > > a shared data ref is offered instead of a extent data ref, such that > it tries to find a non-exist tree block and then btrfs_search_slot

Re: [PATCH v3 5/7] Btrfs: remove BUG() in add_data_reference

On Fri, Aug 18, 2017 at 03:15:22PM -0600, Liu Bo wrote: > Now that we have a helper to report invalid value of extent inline ref > type, we need to quit gracefully instead of throwing out a kernel panic. > > Signed-off-by: Liu Bo Reviewed-by: David Sterba

Re: [PATCH v3 4/7] Btrfs: remove BUG() in print_extent_item

On Fri, Aug 18, 2017 at 03:15:21PM -0600, Liu Bo wrote: > btrfs_print_leaf() is used in btrfs_get_extent_inline_ref_type, so > here we really want to print the invalid value of ref type instead of > causing a kernel panic. > > Signed-off-by: Liu Bo > --- >

Re: [PATCH v3 3/7] Btrfs: remove BUG() in btrfs_extent_inline_ref_size

On Fri, Aug 18, 2017 at 03:15:20PM -0600, Liu Bo wrote: > Now that btrfs_get_extent_inline_ref_type() can report if type is a > valid one and all callers can gracefully deal with that, we don't need > to crash here. > > Signed-off-by: Liu Bo Reviewed-by: David Sterba

Re: [PATCH v3 2/7] Btrfs: convert to use btrfs_get_extent_inline_ref_type

On Fri, Aug 18, 2017 at 03:15:19PM -0600, Liu Bo wrote: > Since we have a helper which can do sanity check, this converts all > btrfs_extent_inline_ref_type to it. > > Signed-off-by: Liu Bo Reviewed-by: David Sterba -- To unsubscribe from this list: send

Re: [PATCH v3 1/7] Btrfs: add a helper to retrive extent inline ref type

On Fri, Aug 18, 2017 at 03:15:18PM -0600, Liu Bo wrote: > An invalid value of extent inline ref type may be read from a > malicious image which may force btrfs to crash. > > This adds a helper which does sanity check for the ref type, so we can > know if it's sane, return type if so, otherwise

Re: btrfs: Adjust 32 checks for null pointers

Sorry Markus, but main problem with your patches described at that page: https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#How_not_to_start I.e. it's cool that you try to help as you can, but not that way, thanks. 2017-08-21 16:27 GMT+03:00 SF Markus Elfring

[PATCH][v2] btrfs: make the delalloc block rsv per inode

From: Josef Bacik The way we handle delalloc metadata reservations has gotten progressively more complicated over the years. There is so much cruft and weirdness around keeping the reserved count and outstanding counters consistent and handling the error cases that it's

Re: [PATCH][v2] Btrfs: rework outstanding_extents

Ignore this, I git format-patch'ed the wrong patch. 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

[PATCH v2] btrfs: Use common error handling code in update_ref_path()

From: Markus Elfring Date: Mon, 21 Aug 2017 15:45:23 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH][v2] Btrfs: rework outstanding_extents

From: Josef Bacik Right now we do a lot of weird hoops around outstanding_extents in order to keep the extent count consistent. This is because we logically transfer the outstanding_extent count from the initial reservation through the set_delalloc_bits. This makes it pretty

Re: [PATCH 4/5] btrfs: Use common error handling code in update_ref_path()

On Mon, Aug 21, 2017 at 09:08:04AM -0400, Jeff Mahoney wrote: > On 8/21/17 8:41 AM, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Mon, 21 Aug 2017 13:34:29 +0200 > > > > Add a jump target so that a bit of exception handling can be better reused > > in

Re: btrfs: Delete an unnecessary variable initialisation in tree_mod_log_eb_copy()

> Don't needed, and you did miss several similar places (L573 & L895) in > that file with explicit initialisation. Would you like to adjust any remaining places in such source files? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [PATCH] btrfs: make the delalloc block rsv per inode

On Mon, Aug 21, 2017 at 03:48:51PM +0300, Nikolay Borisov wrote: > > > On 18.08.2017 00:23, jo...@toxicpanda.com wrote: > > From: Josef Bacik > > > > The way we handle delalloc metadata reservations has gotten > > progressively more complicated over the years. There is so much

Re: btrfs: Adjust 32 checks for null pointers

> That's will work, Thanks for your acknowledgement. > but that's don't improve anything. Do you like a small source code reduction here? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 0/5] BTRFS: Fine-tuning for five function implementations

On Mon, Aug 21, 2017 at 02:35:56PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Aug 2017 14:30:12 +0200 > > A few update suggestions were taken into account > from static source code analysis. All patches make a nice gallery of

Re: [PATCH 2/5] btrfs: Use common error handling code in __btrfs_free_extent()

On Mon, Aug 21, 2017 at 09:07:47AM -0400, Jeff Mahoney wrote: > On 8/21/17 8:38 AM, SF Markus Elfring wrote: > > From: Markus Elfring > > Date: Mon, 21 Aug 2017 10:03:00 +0200 > > > > Add a jump target so that a bit of exception handling can be better reused > > at

Re: [PATCH 3/5] btrfs: Use common error handling code in btrfs_update_root()

On 8/21/17 8:40 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Aug 2017 13:10:15 +0200 > > Add a jump target so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the

Re: [PATCH 4/5] btrfs: Use common error handling code in update_ref_path()

On 8/21/17 8:41 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Aug 2017 13:34:29 +0200 > > Add a jump target so that a bit of exception handling can be better reused > in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH 2/5] btrfs: Use common error handling code in __btrfs_free_extent()

On 8/21/17 8:38 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Aug 2017 10:03:00 +0200 > > Add a jump target so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the

Re: [PATCH 5/5] btrfs: Use common error handling code in btrfs_mark_extent_written()

On 8/21/17 8:42 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 21 Aug 2017 14:15:23 +0200 > > Add jump targets so that a bit of exception handling can be better reused > at the end of this function. > > This issue was detected by using the

Re: [PATCH 03/10] btrfs: Remove unused variable

Reviewed-by: Timofey Titovets 2017-08-21 12:43 GMT+03:00 Nikolay Borisov : > Src was initially part of 31ff1cd25d37 ("Btrfs: Copy into the log tree in > big batches"), however 16e7549f045d ("Btrfs: incompatible format change to > remove hole extents")

Re: [PATCH 01/10] btrfs: Remove chunk_objectid parameter of btrfs_alloc_dev_extent

Reviewed-by: Timofey Titovets 2017-08-21 12:43 GMT+03:00 Nikolay Borisov : > THe function is always called with chunk_objectid set to > BTRFS_FIRST_CHUNK_TREE_OBJECTID. Let's collapse the parameter in the function > itself. No functional changes > >

Re: [PATCH] btrfs: make the delalloc block rsv per inode

On 18.08.2017 00:23, jo...@toxicpanda.com wrote: > From: Josef Bacik > > The way we handle delalloc metadata reservations has gotten > progressively more complicated over the years. There is so much cruft > and weirdness around keeping the reserved count and outstanding

[PATCH 5/5] btrfs: Use common error handling code in btrfs_mark_extent_written()

From: Markus Elfring Date: Mon, 21 Aug 2017 14:15:23 +0200 Add jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 4/5] btrfs: Use common error handling code in update_ref_path()

From: Markus Elfring Date: Mon, 21 Aug 2017 13:34:29 +0200 Add a jump target so that a bit of exception handling can be better reused in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 3/5] btrfs: Use common error handling code in btrfs_update_root()

From: Markus Elfring Date: Mon, 21 Aug 2017 13:10:15 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 2/5] btrfs: Use common error handling code in __btrfs_free_extent()

From: Markus Elfring Date: Mon, 21 Aug 2017 10:03:00 +0200 Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 1/5] btrfs: Use common error handling code in tree_mod_log_eb_copy()

From: Markus Elfring Date: Mon, 21 Aug 2017 09:36:48 +0200 Add a jump target so that a bit of exception handling can be better reused in this function. Signed-off-by: Markus Elfring --- fs/btrfs/ctree.c | 14 ++ 1 file

[PATCH 0/5] BTRFS: Fine-tuning for five function implementations

From: Markus Elfring Date: Mon, 21 Aug 2017 14:30:12 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use common error handling code in tree_mod_log_eb_copy() Use common error handling code in

Re: [PATCH 06/10] btrfs: Remove unused parameter from check_direct_IO

Reviewed-by: Timofey Titovets 2017-08-21 12:43 GMT+03:00 Nikolay Borisov : > Introduced by 5a5f79b57069 ("Btrfs: allow unaligned DIO") and never used, > > Signed-off-by: Nikolay Borisov > --- > fs/btrfs/inode.c | 3 +-- > 1 file

Re: Btrfs Raid5 issue.

I lost enough Btrfs m=d=s=RAID5 filesystems in past experiments (I didn't try using RAID5 for metadata and system chunks in the last few years) to faulty SATA cables + hotplug enabled SATA controllers (where a disk could disappear and reappear "as the wind blew"). Since then, I made a habit of

Re: [PATCH 4/4] btrfs: Delete an unnecessary variable initialisation in tree_mod_log_eb_copy()

Don't needed, and you did miss several similar places (L573 & L895) in that file with explicit initialisation. Reviewed-by: Timofey Titovets 2017-08-20 23:20 GMT+03:00 SF Markus Elfring : > From: Markus Elfring

Re: [PATCH 2/4] btrfs: Adjust 32 checks for null pointers

That's will work, but that's don't improve anything. Reviewed-by: Timofey Titovets 2017-08-20 23:18 GMT+03:00 SF Markus Elfring : > From: Markus Elfring > Date: Sun, 20 Aug 2017 21:36:31 +0200 > MIME-Version:

[PATCH 03/10] btrfs: Remove unused variable

Src was initially part of 31ff1cd25d37 ("Btrfs: Copy into the log tree in big batches"), however 16e7549f045d ("Btrfs: incompatible format change to remove hole extents") changed parameters passed to copy_items which made the src variable redundant. Signed-off-by: Nikolay Borisov

[PATCH 02/10] btrfs: remove superfluous chunk_tree argument from btrfs_alloc_dev_extent

Currently this function is always called with the object id of the root key of the chunk_tree, which is always BTRFS_CHUNK_TREE_OBJECTID. So let's subsume it straight into the function itself. No functional change. Signed-off-by: Nikolay Borisov --- fs/btrfs/volumes.c | 12

[PATCH 01/10] btrfs: Remove chunk_objectid parameter of btrfs_alloc_dev_extent

THe function is always called with chunk_objectid set to BTRFS_FIRST_CHUNK_TREE_OBJECTID. Let's collapse the parameter in the function itself. No functional changes Signed-off-by: Nikolay Borisov --- fs/btrfs/volumes.c | 8 1 file changed, 4 insertions(+), 4

[PATCH 06/10] btrfs: Remove unused parameter from check_direct_IO

Introduced by 5a5f79b57069 ("Btrfs: allow unaligned DIO") and never used, Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 61f1ad89e97a..f1b3d6146924 100644 ---

[PATCH 10/10] btrfs: Remove redundant argument of __link_block_group

__link_block_group is called from only 2 places and at each call site the space_info being passed is the same as the space info assigned to the passed cache struct. Let's remove the redundant argument and make the function reference the space_info from the passed block_group_cache. No functional

[PATCH 09/10] btrfs: Rework error handling of add_extent_mapping in __btrfs_alloc_chunk

Currently the code executes add_extent_mapping and if it is successful it links the new mapping, it then proceeds to unlock the extent mapping tree and check for failure and handle them. Instead, rework the code to only perform a single check if add_extent_mapping has failed and handle it,

[PATCH 08/10] btrfs: remove unused parameter in cow_file_range

The delalloc_end parameter was only passed to extent_clear_unlock_delalloc, but since its usage was removed form that function let's also remove it from the caller's parameter list. Signed-off-by: Nikolay Borisov --- fs/btrfs/inode.c | 20 +--- 1 file changed,

[PATCH 05/10] btrfs: Remove unused arguments from btrfs_changed_cb_t

btrfs_changed_cb_t represents the signature of the callback being passed to btrfs_compare_trees. Currently there is only one such callback, namely changed_cb in send.c. This function doesn't really uses the first 2 parameters, i.e. the roots. Since there are not other functions implementing the

[PATCH 04/10] btrfs: Remove unused parameters from various functions

iterate_dir_item:found_key - introduced in 31db9f7c23fb ("Btrfs: introduce BTRFS_IOC_SEND for btrfs send/receive"), yet never used. record_ref:num - ditto This is a first pass with the low-hanging fruit. There are still quite a few unsued parameters in some function which have to abide by a

[PATCH 07/10] btrfs: Remove unused parameter from extent_clear_unlock_delalloc

This variable was added as part of ba8b04c1d4ad ("btrfs: extend btrfs_set_extent_delalloc and its friends to support in-band dedupe and subpage size patchset") however those patchsets haven't materialized yet. Let's remove the argument and when the time comes (e.g. whiever patchset lands first)

[PATCH 00/10] Unused parameter cleanup

Hello, Here is a series that I've been sitting on for a while. It removes unused parameter in various functions, no functional changes. Patch 09/10 reworks some error handling to eliminate an if branch in __btrfs_alloc_chunk, but it's still a minor refactoring. Nikolay Borisov (10): btrfs:

Re: [PATCH 3/4] btrfs: Improve eight size determinations

You use that doc [1], so it's okay, because that's style are more safe. But i don't think that at now such cleanups are really usefull at now. Because that's not improve anything. Reviewed-by: Timofey Titovets [1] -

[PATCH] Btrfs-progs: Check root before printing item

From: Zhang Yu [TEST/fuzz] case: 004-simple-dump-tree Since the wrong key(DATA_RELOC_TREE CHUNK_ITEM 0) in root tree, error calling print_chunk(), resulting in num_stripes == 0. ERROR: [TEST/fuzz] 004-simple-dump-tree ctree.h:317: btrfs_chunk_item_size:

Re: Btrfs Raid5 issue.

On 2017年08月21日 12:33, Robert LeBlanc wrote: I've been running btrfs in a raid5 for about a year now with bcache in front of it. Yesterday, one of my drives was acting really slow, so I was going to move it to a different port. I guess I get too comfortable hot plugging drives in at work and

[PATCH] btrfs-progs: Doc: Fix asciidoc grammar of btrfs-rescue

Code block of kernel backtrace lacks leading change line, causing the following man page result: -- One can determine whether zero-log is needed according to the kernel backtrace: ? replay_one_dir_item+0xb5/0xb5 [btrfs] ? walk_log_tree+0x9c/0x19d