Re: [PATCH] btrfs-progs: let mkfs return nozero value on thin provision device

On 2018年04月03日 16:39, Su Yue wrote: > when mkfs.btrfs on a thin provision device which has very small > backing size and big virtual size, all code works well in > mkfs.btrfs until close_ctree() is called. > close_ctree() fails to sync device due to small backing size > while closing devices. >

Re: [PATCH v2 10/10] btrfs: qgroup: Use independent and accurate per inode qgroup rsv

Hi David, I didn't see this patch merged in your misc-next branch but only the remaining patches. However without this patch, btrfs qgroup reserved space will get obviously increased as prealloc metadata reserved space is never freed until inode reserved space is freed. This would cause a lot

Re: [PATCH 1/2] btrfs-progs: check: Skip data csum verification for metadata dump

On 3.04.2018 08:55, Qu Wenruo wrote: > > > On 2018年04月03日 13:51, Nikolay Borisov wrote: >> >> >> On 3.04.2018 08:39, Qu Wenruo wrote: >>> For metadata dump (fs restored by btrfs-image), since no data is >>> restored check sum verification will definitely report error. >>> >>> Add such check

[GIT PULL] Btrfs updates for 4.17

Hi, please pull the following btrfs changes. There are a several user visible changes, the rest is mostly invisible and continues to clean up the whole code base. There are no merge conflicts with current master. Please pull, thanks. User visible changes: - new mount option nossd_spread

Re: Status of RAID5/6

On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: >> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: >>> On 2018-04-02 11:18, Goffredo Baroncelli wrote: I thought that a possible solution is to create BG with

[PATCH 1/3] btrfs: replace GPL boilerplate by SPDX -- headers

Remove GPL boilerplate text (long, short, one-line) and keep the rest, ie. personal, company or original source copyright statements. Add the SPDX header. Unify the include protection macros to match the file names. Signed-off-by: David Sterba --- fs/btrfs/async-thread.h

[PATCH 3/3] btrfs: add SPDX header to Kconfig

Signed-off-by: David Sterba --- fs/btrfs/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index 167e5dc7eadd..23537bc8c827 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 +

[PATCH 07/16] btrfs: add proper safety check before resuming dev-replace

The device replace is paused by unmount or read only remount, and resumed on next mount or write remount. The exclusive status should be checked properly as it's a global invariant and we must not allow 2 operations run. In this case, the balance can be also paused and resumed under same

[PATCH 08/16] btrfs: add sanity check when resuming balance after mount

Replace a WARN_ON with a proper check and message in case something goes really wrong and resumed balance cannot set up its exclusive status. The check is a user friendly assertion, I don't expect to ever happen under normal circumstances. Also document that the paused balance starts here and

[PATCH 01/16] btrfs: squeeze btrfs_dev_replace_continue_on_mount to its caller

The function is called once and is fairly small, we can merge it with the caller. Signed-off-by: David Sterba --- fs/btrfs/dev-replace.c | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c index

[PATCH 00/16 v1] Kill fs_info::volume_mutex

This series gets rid of the volume mutex. The fstests do not pass cleanly, 2 or more tests fail so this needs to be fixed, but otherwise majority of the work ready for review. The merge target is 4.18 and I'll probably not get back to this pathset during merge window (nor add it to next), so

[PATCH 05/16] btrfs: move volume_mutex to callers of btrfs_rm_device

Move locking and unlocking next to the BTRFS_FS_EXCL_OP bit manipulation so it's obvious that the two happen at the same time. Signed-off-by: David Sterba --- fs/btrfs/ioctl.c | 4 fs/btrfs/volumes.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 03/16] btrfs: export and rename free_device

The function will be used outside of volumes.c, the allocation btrfs_alloc_device is also exported. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 24 fs/btrfs/volumes.h | 1 + 2 files changed, 13 insertions(+), 12 deletions(-) diff --git

Re: Please add 21035965f60b ("bitmap: fix memset optimization on big-endian systems") to the stable tree

On Tue, Apr 3, 2018 at 11:14 AM, Omar Sandoval wrote: > Just wanted to make sure this doesn't get missed because I misspelled > the stable email address in the patch. It applies to v4.13+. The "sta...@kernel.org" address for a stable cc is actually better than stable@vger"

[PATCH 2/3] btrfs: replace GPL boilerplate by SPDX -- sources

Remove GPL boilerplate text (long, short, one-line) and keep the rest, ie. personal, company or original source copyright statements. Add the SPDX header. Signed-off-by: David Sterba --- fs/btrfs/acl.c | 15 +-- fs/btrfs/async-thread.c

Please add 21035965f60b ("bitmap: fix memset optimization on big-endian systems") to the stable tree

Just wanted to make sure this doesn't get missed because I misspelled the stable email address in the patch. It applies to v4.13+. -- 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

[PATCH 0/3] SPDX to btrfs

Switch fs/btrfs/*.[ch] and fs/btrfs/tests/*.[ch] to SPDX. I've briefly verified that there are no exceptions to GPL-2.0 (ie. no 'or later'). The changes match what I've seen in other patches and I don't think ther's more needed to be done. If there are no objections I'm going to add the patches to

[PATCH 04/16] btrfs: move btrfs_init_dev_replace_tgtdev to dev-replace.c and make static

The function logically belongs there and there's only a single caller, no need to export it. No code changes. Signed-off-by: David Sterba --- fs/btrfs/dev-replace.c | 99 ++ fs/btrfs/volumes.c | 99

[PATCH 10/16] btrfs: remove wrong use of volume_mutex from btrfs_dev_replace_start

The volume mutex does not protect against anything in this case, the comment about scrub is right but not related to locking and looks confusing. The comment in btrfs_find_device_missing_or_by_path is wrong and confusing too. The device_list_mutex is not held here to protect device lookup, but in

[PATCH 02/16] btrfs: make success path out of btrfs_init_dev_replace_tgtdev more clear

This is a preparatory cleanup that will make clear that the only successful way out of btrfs_init_dev_replace_tgtdev will also set the device_out to a valid pointer. With this guarantee, the callers can be simplified. Signed-off-by: David Sterba --- fs/btrfs/dev-replace.c | 1

[PATCH 06/16] btrfs: move clearing of EXCL_OP out of __cancel_balance

Make the clearning visible in the callers so we can pair it with the test_and_set part. Signed-off-by: David Sterba --- fs/btrfs/ioctl.c | 2 +- fs/btrfs/volumes.c | 15 --- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/ioctl.c

[PATCH 13/16] btrfs: remove redundant read-only check from btrfs_cancel_balance

Balance cannot be started on a read-only filesystem and will have to finish/exit before eg. going to read-only via remount. Cancelling does not need to check for that. In case the filesystem is forcibly set to read-only after an error, balance will finish anyway and if the cancel call is too fast

[PATCH 12/16] btrfs: track running balance in a simpler way

Currently fs_info::balance_running is 0 or 1 and does not use the semantics of atomics. The pause and cancel check for 0, that can happen only after __btrfs_balance exits for whatever reason. Parallel calls to balance ioctl may enter btrfs_ioctl_balance multiple times but will block on the

[PATCH 16/16] btrfs: open code set_balance_control

The helper is quite simple and I'd like to see the locking in the caller. Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index

[PATCH 11/16] btrfs: kill btrfs_fs_info::volume_mutex

Mutual exclusion of device add/rm and balance was done by the volume mutex up to version 3.7. The commit 5ac00addc7ac091109 ("Btrfs: disallow mutually exclusive admin operations from user mode") added a bit that essentially tracked the same information. The status bit has an advantage over a

[PATCH 15/16] btrfs: use mutex in btrfs_resume_balance_async

While the spinlock does not cause problems, using the mutex is more correct and consistent with others. The global status of balance is eg. checked from btrfs_pause_balance or btrfs_cancel_balance with mutex. Resuming balance happens during mount or ro->rw remount. In the former case, no other

[PATCH 14/16] btrfs: drop lock parameter from update_ioctl_balance_args and rename

The parameter controls locking of the stats part but we can lock it unconditionally, as this only happens once when balance starts. This is not performance critical. Add the prefix for an exported function. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 2 +-

[PATCH 09/16] btrfs: cleanup helpers that reset balance state

The function __cancel_balance name is confusing with the cancel operation of balance and it really resets the state of balance back to zero. The unset_balance_control helper is called only from one place and simple enough to be inlined. Signed-off-by: David Sterba ---

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

On Mon, Apr 02, 2018 at 04:49:39PM -0700, Linus Torvalds wrote: > On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds > wrote: > > > > We should probably have at least switched it to "unsigned long int" > > I meant just "unsigned int", of course. > > Right now we

Re: Status of RAID5/6

On Tue, Apr 03, 2018 at 07:03:06PM +0200, Goffredo Baroncelli wrote: > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: > > On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: > >> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: > >>> On 2018-04-02 11:18, Goffredo

System freezes a lot - btrfs trace in dmesg - symptom or cause?

Hi there, I'm currently having some issues with my system freezing a lot, from a few seconds up to a few minutes. I haven't figured out yet what might be causing this, however, coincidentally some btrfs notices appeared in my dmesg after I had a freeze for about 5 minutes. I'm wondering whether

[PATCH] btrfs-progs: let mkfs return nozero value on thin provision device

when mkfs.btrfs on a thin provision device which has very small backing size and big virtual size, all code works well in mkfs.btrfs until close_ctree() is called. close_ctree() fails to sync device due to small backing size while closing devices. However, mkfs returns 0 in such situation which

Re: System freezes a lot - btrfs trace in dmesg - symptom or cause?

FWIW, gmail considers the original post a phishing attempt, and put it into spam. Also the sending mail server marked the header with a request that subsequent mail servers fail to forward the email, which effectively makes it incompatible with mail servers which modify the email body, making dkim

Re: System freezes a lot - btrfs trace in dmesg - symptom or cause?

On 2018年04月04日 05:35, Richard Schwab wrote: > Hi there, > > I'm currently having some issues with my system freezing a lot, from a > few seconds up to a few minutes. I haven't figured out yet what might be > causing this, however, coincidentally some btrfs notices appeared in my > dmesg after I

Re: [PATCH typo-fixed] fstests: btrfs: 159 superblock corruption test case

On Thu, Mar 29, 2018 at 06:28:48PM +0800, Anand Jain wrote: > Verify if the superblock corruption is handled correctly. > > Signed-off-by: Anand Jain > --- > tests/btrfs/159 | 142 > > tests/btrfs/159.out | 35

Re: Status of RAID5/6

On Tue, Apr 3, 2018 at 11:03 AM, Goffredo Baroncelli wrote: > On 04/03/2018 02:31 AM, Zygo Blaxell wrote: >> On Mon, Apr 02, 2018 at 06:23:34PM -0400, Zygo Blaxell wrote: >>> On Mon, Apr 02, 2018 at 11:49:42AM -0400, Austin S. Hemmelgarn wrote: On 2018-04-02 11:18,

Re: Status of RAID5/6

On 04/04/2018 12:57 AM, Zygo Blaxell wrote: >> I have to point out that in any case the extent is physically >> interrupted at the disk-stripe size. Assuming disk-stripe=64KB, if >> you want to write 128KB, the first half is written in the first disk, >> the other in the 2nd disk. If you want to