On Thu, Apr 19, 2018 at 04:12:39PM -0700, Drew Bloechl wrote:
> On Thu, Apr 19, 2018 at 10:43:57PM +, Hugo Mills wrote:
> >Given that both data and metadata levels here require paired
> > chunks, try adding _two_ temporary devices so that it can allocate a
> > new block group.
>
> Thank
On Thu, Apr 19, 2018 at 10:43:57PM +, Hugo Mills wrote:
>Given that both data and metadata levels here require paired
> chunks, try adding _two_ temporary devices so that it can allocate a
> new block group.
Thank you very much, that seems to have done the trick:
# fallocate -l 4GiB
On Thu, Apr 19, 2018 at 03:08:48PM -0700, Drew Bloechl wrote:
> I've got a btrfs filesystem that I can't seem to get back to a useful
> state. The symptom I started with is that rename() operations started
> dying with ENOSPC, and it looks like the metadata allocation on the
> filesystem is full:
2018-04-20 1:08 GMT+03:00 Drew Bloechl :
> I've got a btrfs filesystem that I can't seem to get back to a useful
> state. The symptom I started with is that rename() operations started
> dying with ENOSPC, and it looks like the metadata allocation on the
> filesystem is full:
>
I've got a btrfs filesystem that I can't seem to get back to a useful
state. The symptom I started with is that rename() operations started
dying with ENOSPC, and it looks like the metadata allocation on the
filesystem is full:
# btrfs fi df /broken
Data, RAID0: total=3.63TiB, used=67.00GiB
On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan wrote:
> Hi,
>
> The following seems to be a crash consistency bug on btrfs, where in
> the link count is not persisted even after a fsync on the original
> file.
>
> Consider the following workload :
> creat foo
> link (foo, A/bar)
>
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
---
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
The helper is quite simple and I'd like to see the locking in the
caller.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git
Balance cannot be started on a read-only filesystem and will have to
finish/exit before eg. going to read-only via remount.
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 it will
just wait for that to happen.
The
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
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
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
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 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 +-
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
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 | 13 +++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ioctl.c
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.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
---
fs/btrfs/ioctl.c | 4
fs/btrfs/volumes.c | 2 --
2 files
The function is called once and is fairly small, we can merge it with
the caller.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
---
fs/btrfs/dev-replace.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git
The function logically belongs there and there's only a single caller,
no need to export it. No code changes.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
---
fs/btrfs/dev-replace.c | 99 ++
The function will be used outside of volumes.c, the allocation
btrfs_alloc_device is also exported.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 24
fs/btrfs/volumes.h | 1 +
2 files changed, 13
This series gets rid of the volume mutex because it's redundant. Updated
branch: git://github.com/kdave/btrfs-devel dev/remove-volume-mutex
Changes for v2:
- sanity check in balance resume is only a warning
- read-only check in balance cancel remains and is only moved
- typo fixes
The fstests
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.
Reviewed-by: Anand Jain
Signed-off-by: David Sterba
On 19.04.2018 18:31, David Sterba wrote:
> On Thu, Apr 19, 2018 at 07:10:30PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年04月19日 18:59, Nikolay Borisov wrote:
>>>
>>>
>>> On 19.04.2018 12:38, Qu Wenruo wrote:
Although we have already checked incompat flags manually before really
mounting
Hi to all,
as kernel 4.16 is out and 4.17 in in RC, would be possible to update
BTRFS status page
https://btrfs.wiki.kernel.org/index.php/Status to reflect 4.16 stability ?
That page is still based on kernel 4.15 (marked as EOL here:
https://www.kernel.org/)
Thank you
--
To unsubscribe from this
Use common helper functions where needed. By doing this it improves
code readability and debugging of it.
Signed-off-by: Anand Jain
---
tests/btrfs/011 | 197 ++--
1 file changed, 63 insertions(+), 134 deletions(-)
diff
On Wed, Apr 11, 2018 at 10:22:58AM +0300, Nikolay Borisov wrote:
> >> + free_extent_map(em);
> >> + goto unlock_err;
> >> + }
> >> + /*
> >> + * We need to unlock only the end area that we aren't using
> >> + * if there is any
On Thu, Apr 19, 2018 at 07:10:30PM +0800, Qu Wenruo wrote:
>
>
> On 2018年04月19日 18:59, Nikolay Borisov wrote:
> >
> >
> > On 19.04.2018 12:38, Qu Wenruo wrote:
> >> Although we have already checked incompat flags manually before really
> >> mounting it, we could still enhance
On Thu, Apr 12, 2018 at 10:29:23AM +0800, Anand Jain wrote:
> uuid_mutex lock is not a per-fs lock but a global lock. The main aim of
> this patch-set is to critically review the usage of this lock, and delete
> the unnecessary once. By doing this we improve the concurrency of
> device operations
On Thu, Apr 19, 2018 at 11:09:09AM +0300, Nikolay Borisov wrote:
> You said that while merging the deleayed refs cleanup/streamlining
> series there were some conflicts. It turns out they are due to these 3
> patches missing. I'm sending them as a separate set or I can also send
> them as part of
On Thu, Apr 19, 2018 at 10:46:34AM +0300, Nikolay Borisov wrote:
> This function already gets the page from which the two extent trees
> are referenced. Simplify its signature by moving the code getting the
> trees inside the function. No functional changes.
>
> Signed-off-by: Nikolay Borisov
On Thu, Apr 19, 2018 at 10:46:39AM +0300, Nikolay Borisov wrote:
> This function is called from only 1 place and is effectively a wrapper
> over wait_completion/kfree. It doesn't really bring any value having
> those two calls in a separate function. Just open code it and remove it.
> No
On Thu, Apr 19, 2018 at 10:46:37AM +0300, Nikolay Borisov wrote:
> list_empty_careful usually is a signal of something tricky going on. Its
> usage in btrfs is actually not needed since both lists it's used on are
> local to a function and cannot be modified concurrently. So switch to
> plain
On Thu, Apr 19, 2018 at 08:57:30PM +0800, Qu Wenruo wrote:
>
>
> On 2018年04月19日 20:49, David Sterba wrote:
> > On Wed, Apr 11, 2018 at 05:08:12PM +0800, Qu Wenruo wrote:
> >> This patch enhance the following things:
> >>
> >> - tree block header
> >> * add generation and owner output for node
On Wed, Apr 11, 2018 at 05:08:13PM +0800, Qu Wenruo wrote:
> It's pretty handy if we can get debug output for locking status of an
> extent buffer, specially for race related debugging.
>
> So add the following output for btrfs_print_tree() and
> btrfs_print_leaf():
> - refs
> - write_locks (as
On 2018年04月19日 20:49, David Sterba wrote:
> On Wed, Apr 11, 2018 at 05:08:12PM +0800, Qu Wenruo wrote:
>> This patch enhance the following things:
>>
>> - tree block header
>> * add generation and owner output for node and leaf
>> - node pointer generation output
>> - allow btrfs_print_tree()
On Wed, Apr 11, 2018 at 05:08:12PM +0800, Qu Wenruo wrote:
> This patch enhance the following things:
>
> - tree block header
> * add generation and owner output for node and leaf
> - node pointer generation output
> - allow btrfs_print_tree() to not follow nodes
> * just like btrfs-progs
>
On Wed, Apr 18, 2018 at 06:02:35PM -0700, Howard McLauchlan wrote:
> le_bitmap_set() is only used by free-space-tree, so move it there and
> make it static. le_bitmap_clear() is not used, so remove it.
>
> Signed-off-by: Howard McLauchlan
Added to the queue, thanks.
--
To
Hi Nikolay,
Updating to 4.15 seems to have fixed it.
Thanks!
Matthew
On 04/18/2018 05:48 PM, Nikolay Borisov wrote:
On 17.04.2018 19:08, Matthew Lai wrote:
Hello!
I am getting ENOSPC on my root filesystem with plenty of unallocated
space according to "fi usage". Any idea why that may be?
On 2018年04月19日 18:59, Nikolay Borisov wrote:
>
>
> On 19.04.2018 12:38, Qu Wenruo wrote:
>> Although we have already checked incompat flags manually before really
>> mounting it, we could still enhance btrfs_check_super_valid() to check
>> incompat flags for later write time super block
On 19.04.2018 12:38, Qu Wenruo wrote:
> Although we have already checked incompat flags manually before really
> mounting it, we could still enhance btrfs_check_super_valid() to check
> incompat flags for later write time super block validation check.
>
> This patch adds such incompat flags
Just like incompat flags check, although we have already done super csum
type check before calling btrfs_check_super_valid(), we can still add
such check for later write time check.
Signed-off-by: Qu Wenruo
---
v2:
Move csum_type check after magic check.
---
fs/btrfs/disk-io.c
There are already 2 reports about strangely corrupted super blocks,
where csum still matches but extra garbage gets slipped into super block.
The corruption would looks like:
--
superblock: bytenr=65536, device=/dev/sdc1
-
csum_type
There are already 2 reports about strangely corrupted super blocks,
where csum still matches but extra garbage gets slipped into super block.
The corruption would looks like:
--
superblock: bytenr=65536, device=/dev/sdc1
-
csum_type
On 2018年04月19日 18:16, David Sterba wrote:
> Looks good, some minor comments below. I'm wondering how to test that.
Currently I'm using the most stupid way to test it, insert code randomly
modifies super blocks.
> We'd have to inject either the corruption or to provide a way to
> forcibly fail
On 2018年04月19日 18:09, David Sterba wrote:
> On Thu, Apr 19, 2018 at 05:38:15PM +0800, Qu Wenruo wrote:
>> Just like incompat flags check, although we have already done super csum
>> type check before calling btrfs_check_super_valid(), we can still add
>> such check for later write time check.
>>
Looks good, some minor comments below. I'm wondering how to test that.
We'd have to inject either the corruption or to provide a way to
forcibly fail the test. For the latter a debugfs should do, I'll send
something for comments.
On Thu, Apr 19, 2018 at 05:38:16PM +0800, Qu Wenruo wrote:
> @@
On Thu, Apr 19, 2018 at 05:38:15PM +0800, Qu Wenruo wrote:
> Just like incompat flags check, although we have already done super csum
> type check before calling btrfs_check_super_valid(), we can still add
> such check for later write time check.
>
> Signed-off-by: Qu Wenruo
> ---
There are already 2 reports about strangely corrupted super blocks,
where csum still matches but extra garbage gets slipped into super block.
The corruption would looks like:
--
superblock: bytenr=65536, device=/dev/sdc1
-
csum_type
Just like incompat flags check, although we have already done super csum
type check before calling btrfs_check_super_valid(), we can still add
such check for later write time check.
Signed-off-by: Qu Wenruo
---
fs/btrfs/disk-io.c | 9 +
1 file changed, 9 insertions(+)
Although we have already checked incompat flags manually before really
mounting it, we could still enhance btrfs_check_super_valid() to check
incompat flags for later write time super block validation check.
This patch adds such incompat flags check for btrfs_check_super_valid(),
currently it
On 19.04.2018 11:06, Nikolay Borisov wrote:
> It's provided by the transaction handle
>
> Signed-off-by: Nikolay Borisov
David,
You said that while merging the deleayed refs cleanup/streamlining
series there were some conflicts. It turns out they are due to these 3
patches
It's provided by the transaction handle.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/delayed-ref.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
index c0608cbf1354..f343ee0b143a 100644
---
It's provided by the transaction handle
Signed-off-by: Nikolay Borisov
---
fs/btrfs/delayed-ref.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c
index e9a624196295..c0608cbf1354 100644
It's provided by the transaction handle.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/delayed-ref.c | 2 +-
fs/btrfs/delayed-ref.h | 1 -
fs/btrfs/extent-tree.c | 3 +--
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c
list_empty_careful usually is a signal of something tricky going on. Its
usage in btrfs is actually not needed since both lists it's used on are
local to a function and cannot be modified concurrently. So switch to
plain list_empty. No functional changes.
Signed-off-by: Nikolay Borisov
This function is called from only 1 place and is effectively a wrapper
over wait_completion/kfree. It doesn't really bring any value having
those two calls in a separate function. Just open code it and remove it.
No functional changes.
Signed-off-by: Nikolay Borisov
---
This function already gets the page from which the two extent trees
are referenced. Simplify its signature by moving the code getting the
trees inside the function. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 6 +++---
fs/btrfs/extent_io.h
This function is called only from btrfs_readpage and is already passed
the mapping. Simplify its signature by moving the code obtaining
reference to the extent tree in the function. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 6 +++---
It can be directly referenced from the passed address_space so do that.
No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 5 ++---
fs/btrfs/extent_io.h | 3 +--
fs/btrfs/inode.c | 5 +
3 files changed, 4 insertions(+), 9 deletions(-)
It's not used in the function so just remove it. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index
On 19.04.2018 08:32, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel and at least dates back to v4.16 .
>
> It's rather rare error and happens when running xfstests.
Yeah, so this is something which only recently was characterised as
leaking delalloc inodes. I can easily
Add btrfs test that checks "rmdir" or "rm -r" command can delete a
subvolume like an ordinary drectory.
This behavior has been restricted long time but becomes allowed by
following patch in the kernel:
btrfs: Allow rmdir(2) to delete an empty subvolume
Signed-off-by: Tomohiro Misono
On 18.04.2018 22:24, Chris Murphy wrote:
> On Wed, Apr 18, 2018 at 10:38 AM, Austin S. Hemmelgarn > wrote:
>
>> For reference, the zstd compression in BTRFS uses level 3 by default (as
>> does zlib compression IIRC), though I'm not sure about lzop (I think it
>> uses the
64 matches
Mail list logo