On Wed, Mar 10, 2021 at 7:53 PM Dan Williams wrote:
>
> On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox wrote:
> >
> > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > > On 13:02 10/03, Matthew Wilcox wrote:
> > > > On Wed, Mar 10, 2021 at 07:30:41AM -0500, Neal Gompa wrote:
On Thu, Mar 04, 2021 at 01:41:42PM +0800, Shiyang Ruan wrote:
> Some operations, such as comparing a range of data in two files under
> fsdax mode, requires nested iomap_open()/iomap_end() on two file. Thus,
> we introduce iomap_apply2() to accept arguments from two files and
> iomap_actor2_t for
From: Filipe Manana
While resolving backreferences, as part of a logical ino ioctl call or
fiemap, we can end up hitting a BUG_ON() when replaying tree mod log
operations of a root, triggering a stack trace like the following:
[ cut here ]
kernel BUG at fs/btrfs/ctree
From: Filipe Manana
This patchset fixes a couple bugs, in the two first patches, with the tree
mod log code. The remaining patches just move all that code into a separate
file, since it's quite large and ctree.c is huge as well, and do some small
refactorings and cleanups.
One of the bugs in par
From: Filipe Manana
When freeing a tree block we may end up adding its extent back to the
free space cache/tree, as long as there are no more references for it,
it was created in the current transaction and writeback for it never
happened. This is generally fine, however when we have tree mod log
From: Filipe Manana
Instead of exposing implementation details of the tree mod log to check
if there are active tree mod log users at btrfs_free_tree_block(), use
the new bit BTRFS_FS_TREE_MOD_LOG_USERS for fs_info->flags instead. This
way extent-tree.c does not need to known about any of the int
From: Filipe Manana
The tree modification log functions are called very frequently, basically
they are called everytime a btree is modified (a pointer added or removed
to a node, a new root for a btree is set, etc). Because of that, to avoid
heavy lock contention on the lock that protects the lis
From: Filipe Manana
At btrfs_tree_mod_log_free_eb() we check if we are dealing with a leaf,
and if so, return immediately and do nothing. However this check can be
removed, because after it we call tree_mod_need_log(), which returns
false when given an extent buffer that corresponds to a leaf.
S
From: Filipe Manana
We used to encode two different numbers in the tree mod log counter used
for sequence numbers, one in the upper 32 bits and the other one in the
lower 32 bits. However that is no longer the case, we stopped doing that
since commit fcebe4562dec83 ("Btrfs: rework qgroup accounti
From: Filipe Manana
Several functions of the tree modification log use integers as booleans,
so change them to use booleans instead, making their use more clear.
Signed-off-by: Filipe Manana
---
fs/btrfs/ctree.c| 6 +++---
fs/btrfs/tree-mod-log.c | 42 -
From: Filipe Manana
The tree modification log, which records modifications done to btrees, is
quite large and currently spread all over ctree.c, which is a huge file
already.
To make things better organized, move all that code into its own separate
source and header files. Functions and definiti
From: Filipe Manana
There are two places outside the tree mod log module that extract the
lowest sequence number of the tree mod log. These places end up
duplicating code and open coding the logic and internal implementation
details of the tree mod log. So add a helper to the tree mod log module
On Wed, Mar 10, 2021 at 5:52 PM Zygo Blaxell
wrote:
>
> On Fri, Mar 05, 2021 at 12:45:08PM +, Filipe Manana wrote:
> > On Fri, Mar 5, 2021 at 1:08 AM Zygo Blaxell
> > wrote:
> > >
> > > On Tue, Mar 02, 2021 at 04:24:19PM +, Filipe Manana wrote:
> > > > On Sat, Feb 27, 2021 at 3:53 PM Zygo
On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
>
> Hi,
>
> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg,
> no scrub errors:
>
> ls -lh
> total 19G
> -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat
> -rwxr-x--- 1 root root 783 Mar 10 14
From: Filipe Manana
When using a zoned filesystem, while syncing the log, if we fail to
allocate the root node for the log root tree, we are not removing the
log context we allocated on stack from the list of log contextes of the
log root tree. This means after the return from btrfs_sync_log() we
Looks good, Thanks!
Reviewed-by: Johannes Thumshirn
On Wed, Mar 10, 2021 at 03:58:36PM -0800, Andrew Morton wrote:
> On Tue, 9 Mar 2021 13:21:34 -0800 ira.we...@intel.com wrote:
>
> > Previously this was submitted to convert to zero_user()[1]. zero_user() is
> > not
> > the same as memzero_user() and in fact some zero_user() calls may be better
Hello,
My recent debugging session with Neal's broken filesystem uncovered a glaring
hole in my rescue=all patches, they don't deal with a NULL dev_root properly.
In testing I only ever tested corrupting the extent tree or the csum tree, since
those are the most problematic. The following 3 fixes
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP NOPTI
CPU: 0 PID: 696 Comm: mount Tainted: GW 5.12.0-rc2+ #296
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32
0
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 0 PID: 4095 Comm: mount Not tainted 5.11.0-0.rc7.149.fc34.x86_64 #1
RIP: 0010:btrfs_device_init_dev_stats+0x4c/0x1f0
RSP: 0018:a60285fbfb68
While helping Neal fix his broken file system I added a debug patch to
catch if we were calling btrfs_search_slot with a NULL root, and this
stack trace popped
we tried to search with a NULL root
CPU: 0 PID: 1760 Comm: mount Not tainted 5.11.0-155.nealbtrfstest.1.fc34.x86_64
#1
Hardware name: VMw
‐‐‐ Original Message ‐‐‐
On Wednesday, 10 March 2021 г., 20:15, Martin Raiber
wrote:
> Hi,
>
> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg,
> no scrub errors:
>
> ls -lh
> total 19G
> -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat
> -rwxr
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v5.12-rc2]
[also build test WARNING on next-20210311]
[cannot apply to kdave/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Thu, Mar 11, 2021 at 5:27 PM kernel test robot wrote:
>
> Hi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on v5.12-rc2]
> [also build test WARNING on next-20210311]
> [cannot apply to kdave/for-next]
> [If your patch is ap
On 01.02.2021 23:08 Martin Raiber wrote:
> On 27.01.2021 22:03 Chris Murphy wrote:
>> On Wed, Jan 27, 2021 at 10:27 AM Martin Raiber wrote:
>>> Hi,
>>>
>>> seems 5.10.8 still has the ENOSPC issue when compression is used
>>> (compress-force=zstd,space_cache=v2):
>>>
>>> Jan 27 11:02:14 kernel: [
On 11.03.2021 15:43 Filipe Manana wrote:
> On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
>> Hi,
>>
>> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg,
>> no scrub errors:
>>
>> ls -lh
>> total 19G
>> -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.da
On 2/26/21 1:30 PM, David Sterba wrote:
On Wed, Dec 16, 2020 at 11:26:19AM -0500, Josef Bacik wrote:
Currently select_reloc_root() doesn't return an error, but followup
patches will make it possible for it to return an error. We do have
proper error recovery in do_relocation however, so handle
On Thu, Mar 11, 2021 at 6:05 PM Martin Raiber wrote:
>
> On 11.03.2021 15:43 Filipe Manana wrote:
> > On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
> >> Hi,
> >>
> >> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in
> >> dmesg, no scrub errors:
> >>
> >> ls -lh
> >> to
On Thu, Mar 11, 2021 at 11:25 AM Josef Bacik wrote:
>
> Hello,
>
> My recent debugging session with Neal's broken filesystem uncovered a glaring
> hole in my rescue=all patches, they don't deal with a NULL dev_root properly.
> In testing I only ever tested corrupting the extent tree or the csum tr
I'm in the process of converting my "single" data to "raid0" for the
performance benefits of striping. However, watching the output of
btrfs fi usage, I'm seeing something odd. Here's the current usage:
Data,single: Size:4.47TiB, Used:4.47TiB (99.98%)
/dev/mapper/neutrino3 300.00GiB
Commit b3df561fbf has introduced the ability to convert extended
inode time precision on ext4, but this breaks builds on older distros,
where ext4 does not have the nsec time precision.
Commit c615287cc tried to fix that by testing the availability of
the EXT4_EPOCH_MASK macro, but the test is not
On Thu, Mar 11, 2021 at 02:43:26PM +, Filipe Manana wrote:
> On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
> >
> > Hi,
> >
> > I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg,
> > no scrub errors:
> >
> > ls -lh
> > total 19G
> > -rwxr-x--- 1 root root
On 12/3/21 12:23 am, Josef Bacik wrote:
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP NOPTI
CPU: 0 PID: 696 Comm: mount Tainted: GW 5.12.0-rc2+ #296
Hardware name: QEMU Standard PC
On 12/3/21 1:52 pm, Anand Jain wrote:
On 12/3/21 12:23 am, Josef Bacik wrote:
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP NOPTI
CPU: 0 PID: 696 Comm: mount Tainted: G W 5.12.0
On 12/3/21 12:23 am, Josef Bacik wrote:
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP NOPTI
CPU: 0 PID: 696 Comm: mount Tainted: GW 5.12.0-rc2+ #296
Hardware name: QEMU Standard PC
On 12/3/21 12:23 am, Josef Bacik wrote:
Neal reported a panic trying to use -o rescue=all
BUG: kernel NULL pointer dereference, address: 0030
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 0 PID: 4095 Comm: mount Not tainted 5.11.0-0.rc7.149.fc34.x86_64 #1
RIP: 0010:btrfs_device_init_dev_s
On Wed, Mar 10, 2021 at 10:48:35AM +, Filipe Manana wrote:
> On Sun, Mar 7, 2021 at 3:24 PM Eryu Guan wrote:
> >
> > On Sun, Mar 07, 2021 at 03:07:43PM +, Filipe Manana wrote:
> > > On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
> > > >
> > > > On Thu, Feb 11, 2021 at 05:01:18PM +, f
On 12/3/21 12:23 am, Josef Bacik wrote:
While helping Neal fix his broken file system I added a debug patch to
catch if we were calling btrfs_search_slot with a NULL root, and this
stack trace popped
we tried to search with a NULL root
CPU: 0 PID: 1760 Comm: mount Not tainted 5.11.0-155.nealbtrf
Hello,
I have observed this error messages in systemd journal:
BTRFS error (device sda1): bdev /dev/sdb1 errs: wr 2702175, rd 2719033,
flush 0, corrupt 6, gen 0
Here are the bottom lines of journalctl -xb:
är 12 08:30:41 pc1-desktop kernel: attempt to access beyond end of device
39 matches
Mail list logo
