On Tue, Apr 03, 2018 at 09:08:01PM -0600, Chris Murphy wrote:
> 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
Function btrfs_trim_fs() doesn't handle errors in a consistent way, if
error happens when trimming existing block groups, it will skip the
remaining blocks and continue to trim unallocated space for each device.
And the return value will only reflect the final error from device
trimming.
This pat
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super
On Tue, Apr 03, 2018 at 11:57:26AM -0700, Linus Torvalds wrote:
>
> Greg - if your automation has changed, and you actually really want
> the "vger", let me know. Because I tend to just use
> "sta...@kernel.org"
Either is fine, my scripts pick up both variants.
thanks,
greg k-h
--
To unsubscrib
On Wed, Apr 04, 2018 at 07:15:54AM +0200, Goffredo Baroncelli wrote:
> 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
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 w
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, Goffredo Baroncelli wrote:
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 +
> tests/btrf
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
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
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 Baronce
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
th
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" imho, because afaik it
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 +-
fs/btrfs/ioctl.c | 14
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
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 balance
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 e93c7ba44d06..db9f72c6af85 100644
-
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 mutex
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 use
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
---
fs/btrfs/ioctl.c | 8 +++
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
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 condition
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 owns
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 -
fs/btrfs/volumes
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 a/fs/btrfs/ioctl.c b
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 a/fs/btrfs/volumes.c b/f
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 0d203633bb96..c0397
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 --
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 b/fs/btrfs/ioctl.c
index b9
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 there
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
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 | 21 +
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
+
config BTRFS_FS
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| 15 +---
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 http://vger.kern
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 occasionally have a silly 64-bit fiel
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 diffe
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 (pair
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.
> H
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 cau
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 of
41 matches
Mail list logo
