[PATCH] btrfs: handle failures of set_extent_bits in add_excluded_extent

set_extent_bits may return 0/-EEXIST, so return the result in add_excluded_extent. And handle the failures in upper callers. Caller of add_excluded_extent and failure process currently: exclude_super_stripes <- btrfs_make_block_group //handles the failure <-

Re: [PATCH] [RFC] bcachefs: SIX locks (shared/intent/exclusive)

On Mon, May 21, 2018 at 08:04:16PM -0700, Matthew Wilcox wrote: > On Mon, May 21, 2018 at 10:19:51PM -0400, Kent Overstreet wrote: > > New lock for bcachefs, like read/write locks but with a third state, > > intent. > > > > Intent locks conflict with each other, but not with read locks; taking a

Re: [PATCH] [RFC] bcachefs: SIX locks (shared/intent/exclusive)

On Mon, May 21, 2018 at 10:19:51PM -0400, Kent Overstreet wrote: > New lock for bcachefs, like read/write locks but with a third state, > intent. > > Intent locks conflict with each other, but not with read locks; taking a > write lock requires first holding an intent lock. Can you put something

[PATCH] [RFC] bcachefs: SIX locks (shared/intent/exclusive)

New lock for bcachefs, like read/write locks but with a third state, intent. Intent locks conflict with each other, but not with read locks; taking a write lock requires first holding an intent lock. The purpose is for multi node data structures (i.e. btrees), where if we were using read/write

Re: [PATCH] Btrfs: allow empty subvol= again

On Mon, May 21, 2018 at 05:07:19PM -0700, Omar Sandoval wrote: > From: Omar Sandoval > > I got a report that after upgrading to 4.16, someone's filesystems > weren't mounting: > > [ 23.845852] BTRFS info (device loop0): unrecognized mount option 'subvol=' > > Before 4.16,

[PATCH] Btrfs: allow empty subvol= again

From: Omar Sandoval I got a report that after upgrading to 4.16, someone's filesystems weren't mounting: [ 23.845852] BTRFS info (device loop0): unrecognized mount option 'subvol=' Before 4.16, this mounted the default subvolume. It turns out that this empty "subvol=" is

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21, 2018 at 02:24:32PM -0400, Mike Snitzer wrote: > Every single data structure change in this series should be reviewed for > unforeseen alignment consequences. Jens seemed to say that is > worthwhile. Not sure if he'll do it or we divide it up. If we divide > it up a temp topic

Re: Any chance to get snapshot-aware defragmentation?

On 2018-05-21 13:43, David Sterba wrote: On Fri, May 18, 2018 at 01:10:02PM -0400, Austin S. Hemmelgarn wrote: On 2018-05-18 12:36, Niccolò Belli wrote: On venerdì 18 maggio 2018 18:20:51 CEST, David Sterba wrote: Josef started working on that in 2014 and did not finish it. The patches can be

Re: [PATCH 11/12] xfs: convert to bioset_init()/mempool_init()

On Sun, May 20, 2018 at 06:25:57PM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet Looks ok, I guess... Acked-by: Darrick J. Wong --D > --- > fs/xfs/xfs_aops.c | 2 +- > fs/xfs/xfs_aops.h | 2 +- > fs/xfs/xfs_super.c | 11

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 1:37pm -0400, Kent Overstreet wrote: > > Uh, you came across as upset and paranoid to me too. Chalk it up to email? :) Awesome. See how easy it is to make someone with purely constructive questions and feedback come off as upset and paranoid?

[RFC PATCH v2 09/12] mm/vmpressure: update usage of address zone modifiers

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE

[RFC PATCH v2 08/12] drivers/block/zram/zram_drv: update usage of address zone modifiers

Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE and __GFP_MOVABLE

[RFC PATCH v2 07/12] fs/btrfs/extent_io: update usage of address zone modifiers

Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM). In function alloc_extent_state, it is obvious that __GFP_DMA is not the expecting zone type. ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing

[RFC PATCH v2 06/12] drivers/xen/swiotlb-xen: update usage of address zone modifiers

Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM). In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32 is not the expecting zone type. ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for

Re: Any chance to get snapshot-aware defragmentation?

On Fri, May 18, 2018 at 01:10:02PM -0400, Austin S. Hemmelgarn wrote: > On 2018-05-18 12:36, Niccolò Belli wrote: > > On venerdì 18 maggio 2018 18:20:51 CEST, David Sterba wrote: > >> Josef started working on that in 2014 and did not finish it. The patches > >> can be still found in his tree. The

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21, 2018 at 12:09:14PM -0400, Mike Snitzer wrote: > On Mon, May 21 2018 at 11:36am -0400, > Jens Axboe wrote: > > > On 5/21/18 9:18 AM, Mike Snitzer wrote: > > > On Mon, May 21 2018 at 11:09am -0400, > > > Jens Axboe wrote: > > > > > >> On 5/21/18

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 10:09 AM, Mike Snitzer wrote: > On Mon, May 21 2018 at 11:36am -0400, > Jens Axboe wrote: > >> On 5/21/18 9:18 AM, Mike Snitzer wrote: >>> On Mon, May 21 2018 at 11:09am -0400, >>> Jens Axboe wrote: >>> On 5/21/18 9:04 AM, Mike Snitzer wrote:

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 11:36am -0400, Jens Axboe wrote: > On 5/21/18 9:18 AM, Mike Snitzer wrote: > > On Mon, May 21 2018 at 11:09am -0400, > > Jens Axboe wrote: > > > >> On 5/21/18 9:04 AM, Mike Snitzer wrote: > >>> On Mon, May 21 2018 at 10:52am -0400, > >>>

Next btrfs development cycle open - 4.19

From: David Sterba Hi, a friendly reminder of the timetable and what's expected at this phase. 4.16 - current 4.17 - upcoming, urgent regression fixes only 4.18 - development closed, pull request in prep, fixes or regressions only 4.19 - development open, until 4.18-rc5 (at

Re: Any chance to get snapshot-aware defragmentation?

On 2018-05-21 09:42, Timofey Titovets wrote: пн, 21 мая 2018 г. в 16:16, Austin S. Hemmelgarn : On 2018-05-19 04:54, Niccolò Belli wrote: On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote: With a bit of work, it's possible to handle things sanely. You

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 9:18 AM, Mike Snitzer wrote: > On Mon, May 21 2018 at 11:09am -0400, > Jens Axboe wrote: > >> On 5/21/18 9:04 AM, Mike Snitzer wrote: >>> On Mon, May 21 2018 at 10:52am -0400, >>> Jens Axboe wrote: >>> On 5/21/18 8:47 AM, Mike Snitzer wrote:

Re: [RFC PATCH v2 05/12] include/linux/dma-mapping: update usage of address zone modifiers

On Mon, May 21, 2018 at 11:20:26PM +0800, Huaisheng Ye wrote: > From: Huaisheng Ye > > Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). > > ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP > bitmasks, the bottom three bits of GFP

[RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone

[RFC PATCH v2 01/12] include/linux/gfp.h: get rid of GFP_ZONE_TABLE/BAD

From: Huaisheng Ye Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number. Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. The encoding method is XOR. Get zone

[RFC PATCH v2 04/12] drivers/iommu/amd_iommu: update usage of address zone modifiers

From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 02/12] arch/x86/kernel/amd_gart_64: update usage of address zone modifiers

From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 11/12] include/linux/highmem: update usage of movableflags

From: Huaisheng Ye GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE, modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD. Signed-off-by: Huaisheng Ye Cc: Kate Stewart Cc: Greg Kroah-Hartman

[RFC PATCH v2 10/12] mm/zsmalloc: update usage of address zone modifiers

From: Huaisheng Ye Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_ZONE_MOVABLE contains

[RFC PATCH v2 12/12] arch/x86/include/asm/page.h: update usage of movableflags

From: Huaisheng Ye GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE, modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD. Signed-off-by: Huaisheng Ye Cc: Thomas Gleixner Cc: Ingo Molnar Cc:

[RFC PATCH v2 05/12] include/linux/dma-mapping: update usage of address zone modifiers

From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

[RFC PATCH v2 03/12] arch/x86/kernel/pci-calgary_64: update usage of address zone modifiers

From: Huaisheng Ye Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32). ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP bitmasks, the bottom three bits of GFP mask is reserved for storing encoded zone number. __GFP_DMA, __GFP_HIGHMEM

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 9:12 AM, David Sterba wrote: > On Mon, May 21, 2018 at 08:19:58AM -0600, Jens Axboe wrote: >> On 5/21/18 8:03 AM, Mike Snitzer wrote: >>> On Sun, May 20 2018 at 6:25pm -0400, >>> Kent Overstreet wrote: >>> Jens - this series does the rest of the

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 11:09am -0400, Jens Axboe wrote: > On 5/21/18 9:04 AM, Mike Snitzer wrote: > > On Mon, May 21 2018 at 10:52am -0400, > > Jens Axboe wrote: > > > >> On 5/21/18 8:47 AM, Mike Snitzer wrote: > >>> On Mon, May 21 2018 at 10:36am -0400, > >>>

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21, 2018 at 08:19:58AM -0600, Jens Axboe wrote: > On 5/21/18 8:03 AM, Mike Snitzer wrote: > > On Sun, May 20 2018 at 6:25pm -0400, > > Kent Overstreet wrote: > > > >> Jens - this series does the rest of the conversions that Christoph wanted, > >> and > >>

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 9:04 AM, Mike Snitzer wrote: > On Mon, May 21 2018 at 10:52am -0400, > Jens Axboe wrote: > >> On 5/21/18 8:47 AM, Mike Snitzer wrote: >>> On Mon, May 21 2018 at 10:36am -0400, >>> Jens Axboe wrote: >>> On 5/21/18 8:31 AM, Mike Snitzer wrote:

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 10:52am -0400, Jens Axboe wrote: > On 5/21/18 8:47 AM, Mike Snitzer wrote: > > On Mon, May 21 2018 at 10:36am -0400, > > Jens Axboe wrote: > > > >> On 5/21/18 8:31 AM, Mike Snitzer wrote: > >>> On Mon, May 21 2018 at 10:19am -0400, > >>>

[PATCH] defrag: open files RO

NOT FOR MERGING -- requires kernel versioning Fixes EXTXBSY races. Signed-off-by: Adam Borowski --- cmds-filesystem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmds-filesystem.c b/cmds-filesystem.c index 30a50bf5..7eb6b7bb 100644 ---

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 8:47 AM, Mike Snitzer wrote: > On Mon, May 21 2018 at 10:36am -0400, > Jens Axboe wrote: > >> On 5/21/18 8:31 AM, Mike Snitzer wrote: >>> On Mon, May 21 2018 at 10:19am -0400, >>> Jens Axboe wrote: >>> On 5/21/18 8:03 AM, Mike Snitzer wrote:

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 10:36am -0400, Jens Axboe wrote: > On 5/21/18 8:31 AM, Mike Snitzer wrote: > > On Mon, May 21 2018 at 10:19am -0400, > > Jens Axboe wrote: > > > >> On 5/21/18 8:03 AM, Mike Snitzer wrote: > >>> On Sun, May 20 2018 at 6:25pm -0400, > >>>

[PATCH 2/2] btrfs: defrag: return EPERM not EINVAL when only permissions fail

We give EINVAL when the request is invalid; here it's ok but merely the user has insufficient privileges. Thus, this return value reflects the error better -- as discussed in the identical case for dedupe. According to codesearch.debian.net, no userspace program distinguishes these values beyond

[PATCH 1/2] btrfs: allow defrag on a file opened ro that has rw permissions

Requiring a rw descriptor conflicts both ways with exec, returning ETXTBSY whenever you try to defrag a program that's currently being run, or causing intermittent exec failures on a live system being defragged. As defrag doesn't change the file's contents in any way, there's no reason to

[PATCH 0/2] btrfs: fix races between exec and defrag

Hi! Here's a patch to fix ETXTBSY races between defrag and exec -- similar to what was just submitted for dedupe, even to the point of being followed by a second patch that replaces EINVAL with EPERM. As defrag is not something you're going to do on files you don't write, I skipped complex rules

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 8:31 AM, Mike Snitzer wrote: > On Mon, May 21 2018 at 10:19am -0400, > Jens Axboe wrote: > >> On 5/21/18 8:03 AM, Mike Snitzer wrote: >>> On Sun, May 20 2018 at 6:25pm -0400, >>> Kent Overstreet wrote: >>> Jens - this series does the

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Mon, May 21 2018 at 10:19am -0400, Jens Axboe wrote: > On 5/21/18 8:03 AM, Mike Snitzer wrote: > > On Sun, May 20 2018 at 6:25pm -0400, > > Kent Overstreet wrote: > > > >> Jens - this series does the rest of the conversions that Christoph wanted,

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/20/18 4:25 PM, Kent Overstreet wrote: > Jens - this series does the rest of the conversions that Christoph wanted, and > drops bioset_create(). > > Only lightly tested, but the changes are pretty mechanical. Based on your > for-next tree. Looks good to me. I'll let it simmer for a bit to

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On 5/21/18 8:03 AM, Mike Snitzer wrote: > On Sun, May 20 2018 at 6:25pm -0400, > Kent Overstreet wrote: > >> Jens - this series does the rest of the conversions that Christoph wanted, >> and >> drops bioset_create(). >> >> Only lightly tested, but the changes are

Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Sun, May 20 2018 at 6:25pm -0400, Kent Overstreet wrote: > Jens - this series does the rest of the conversions that Christoph wanted, and > drops bioset_create(). > > Only lightly tested, but the changes are pretty mechanical. Based on your > for-next tree. By

Re: Any chance to get snapshot-aware defragmentation?

On domenica 20 maggio 2018 12:59:28 CEST, Tomasz Pala wrote: On Sat, May 19, 2018 at 10:56:32 +0200, Niccol? Belli wrote: snapper users with hourly snapshots will not have any use for it. Anyone with hourly snapshots anyone is doomed anyway. I do not agree: having hourly snapshots doesn't

Re: Any chance to get snapshot-aware defragmentation?

пн, 21 мая 2018 г. в 16:16, Austin S. Hemmelgarn : > On 2018-05-19 04:54, Niccolò Belli wrote: > > On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote: > >> With a bit of work, it's possible to handle things sanely. You can > >> deduplicate data from

Re: Any chance to get snapshot-aware defragmentation?

On 2018-05-19 04:54, Niccolò Belli wrote: On venerdì 18 maggio 2018 20:33:53 CEST, Austin S. Hemmelgarn wrote: With a bit of work, it's possible to handle things sanely.  You can deduplicate data from snapshots, even if they are read-only (you need to pass the `-A` option to duperemove and run

Re: [PATCH v2 2/2] vfs: dedupe should return EPERM if permission is not granted

On Fri, May 18, 2018 at 02:57:27PM -0700, Mark Fasheh wrote: > Right now we return EINVAL if a process does not have permission to dedupe a > file. This was an oversight on my part. EPERM gives a true description of > the nature of our error, and EINVAL is already used for the case that the >

Re: [PATCH] btrfs: remove unnecessary if judge

On 21.05.2018 12:32, Gu Jinxiang wrote: > Since add_excluded_extent always returns 0, > no need to judge ret. This patch is conceptually wrong because: a). Currently exclude_super_stripes is in fact buggy since it calls set_extent_bits which *may* fail, yet the return value is completely

[PATCH] btrfs: remove unnecessary if judge

Since add_excluded_extent always returns 0, no need to judge ret. Signed-off-by: Gu Jinxiang --- fs/btrfs/extent-tree.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 75cfb80d2551..4d876b32e136 100644 ---

[PATCH 1/4] btrfs: Remove fs_info argument from alloc_reserved_tree_block

This function already takes a transaction handle which contains a reference to the fs_info. So use this and remove the extra argument. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 4/4] btrfs: Streamline shared ref check in alloc_reserved_tree_block

Instead of setting "parent" to ref->parent only when dealing with a shared ref and subsequently performing another check to see if (parent > 0), check the "node->type" directly and act accordingly. This makes the code more streamline. No functional changes. Signed-off-by: Nikolay Borisov

[PATCH 2/4] btrfs: Simplify alloc_reserved_tree_block interface

This function currently takes 7 parameters, most of which are proxies for values from btrfs_delayed_ref_node struct which is not passed. This patch simplifies the interface of the function by simply passing said delayed ref node struct to the function. This enables us to: 1. Move locals variables

[PATCH 3/4] btrfs: Pass btrfs_delayed_extent_op to alloc_reserved_tree_block

Instead of taking only specific member of this structure, which results in 2 extra arguments, just take the delayed_extent_op struct and reference the arguments inside the functions. No functional changes. Signed-off-by: Nikolay Borisov --- fs/btrfs/extent-tree.c | 11

[PATCH 0/4] Cleanup alloc_reserved_tree_block signature

At the moment alloc_reserved_tree_block takes 8 friggin arguments. The irony is that all of those are really derived from 3 structures. This series ends up reducing the arguments to 3. As a result some code, private to alloc_reserved_tree_block is moved from run_delayed_tree_ref. Patch 1

Re: [PATCH] Btrfs: fix error handling in btrfs_truncate()

On 19.05.2018 00:43, Omar Sandoval wrote: > From: Omar Sandoval > > Jun Wu at Facebook reported that an internal service was seeing a return > value of 1 from ftruncate() on Btrfs when compression is enabled. This > is coming from the NEED_TRUNCATE_BLOCK return value from >

[PATCH v3 3/3] btrfs: balance: add kernel log for end or paused

Add a kernel log when the balance ends, either for cancel or completed or if it is paused. Signed-off-by: Anand Jain --- v2->v3: nothing. v1->v2: Moved from 2/3 to 3/3 fs/btrfs/volumes.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fs/btrfs/volumes.c

[PATCH v3 0/3] btrfs: balance: improve kernel logs

Based on misc-next. v2->v3: Inspried by describe_relocation(), improves it, makes it a helper function and use it to log the balance operations. Kernel logs are very important for the forensic investigations of the issues, these patchs make balance logs easy to review. Anand Jain (3):

[PATCH v3 2/3] btrfs: balance: add args info during start and resume

Balance arg info is an important information to be reviewed for the system audit. So this patch adds them to the kernel log. Example: -> btrfs bal start -dprofiles='raid1|single',convert=raid5 -mprofiles='raid1|single',convert=raid5 /btrfs kernel: BTRFS info (device sdb): balance: start

Re: [PATCH v2 3/3] btrfs: balance: add kernel log for end or paused

On 05/17/2018 08:06 PM, David Sterba wrote: On Wed, May 16, 2018 at 10:51:28AM +0800, Anand Jain wrote: Add a kernel log when the balance ends, either for cancel or completed or if it is paused. Missing S-O-B. oops. Fixed in v3. --- v1->v2: Moved from 2/3 to 3/3 fs/btrfs/volumes.c |

[PATCH v3 1/3] btrfs: add helper function describe_block_group()

Improve on describe_relocation() add a common helper function to describe the block groups. Signed-off-by: Anand Jain --- v3: Born. fs/btrfs/relocation.c | 30 +++--- fs/btrfs/volumes.c| 44

Re: [PATCH v2 2/3] btrfs: balance: add args info during start and resume

On 05/17/2018 07:59 PM, David Sterba wrote: On Wed, May 16, 2018 at 10:51:27AM +0800, Anand Jain wrote: Balance args info is an important information to be reviewed for the system audit. So this patch adds it to the kernel log. Example: -> btrfs bal start