On Wed, Feb 17, 2021 at 10:59 PM Erik Jensen wrote:
> On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
> > On 2021/2/18 下午1:49, Erik Jensen wrote:
> > > On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> > >> Got it now.
> > >>
> > >> [ 295.249182] read_extent_buffer_pages: eb->start=262077806
On 2021/2/18 下午2:59, Erik Jensen wrote:
On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
On 2021/2/18 下午1:49, Erik Jensen wrote:
On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
Got it now.
[ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
[ 295.249188] __btrfs
On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
> On 2021/2/18 下午1:49, Erik Jensen wrote:
> > On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> >> Got it now.
> >>
> >> [ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
> >> [ 295.249188] __btrfs_map_block: logical=861
On 2021/2/18 下午1:49, Erik Jensen wrote:
On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
Got it now.
[ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
[ 295.249188] __btrfs_map_block: logical=8615594639360 chunk
start=8614760677376 len=4294967296 type=0x81
[ 295.2
On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> Got it now.
>
> [ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
> [ 295.249188] __btrfs_map_block: logical=8615594639360 chunk
> start=8614760677376 len=4294967296 type=0x81
> [ 295.249189] __btrfs_map_block: stripe[0]
On 2021/2/18 下午12:03, Erik Jensen wrote:
On Wed, Feb 17, 2021 at 5:24 PM Qu Wenruo wrote:
On 2021/2/11 上午7:47, Qu Wenruo wrote:
On 2021/2/11 上午6:17, Erik Jensen wrote:
On Tue, Feb 9, 2021 at 9:47 PM Qu Wenruo wrote:
[...]
Unfortunately I didn't get much useful info from the trace event
On Wed, Feb 17, 2021 at 5:24 PM Qu Wenruo wrote:
> On 2021/2/11 上午7:47, Qu Wenruo wrote:
> > On 2021/2/11 上午6:17, Erik Jensen wrote:
> >> On Tue, Feb 9, 2021 at 9:47 PM Qu Wenruo wrote:
> > [...]
> >>>
> >>> Unfortunately I didn't get much useful info from the trace events.
> >>> As a lot of the
Hi!
I found some error when I run unittest code in btrfs-progs.
fsck/012-leaf-corruption test corrupt leaf and check that it's recovered.
but the test was failed and demsg below
[ 47.284095] BTRFS error (device loop5): device total_bytes should be at most
27660288 but found 67108864
[ 47.284
I was attempting to replace the drives in an array with RAID6 profile.
The first replacement was seemingly successful (and there was a scrub
afterward, with no errors). However, about 0.6% into the second
replacement (sdc), something went wrong, and it went read-only (I should
have copied the log o
On 2021/2/11 上午7:47, Qu Wenruo wrote:
On 2021/2/11 上午6:17, Erik Jensen wrote:
On Tue, Feb 9, 2021 at 9:47 PM Qu Wenruo wrote:
[...]
Unfortunately I didn't get much useful info from the trace events.
As a lot of the values doesn't even make sense to me
But the chunk tree dump proves
On Thu 18 Feb 2021 at 06:18, Boris Burkov wrote:
On Mon, Feb 15, 2021 at 05:20:11PM +0800, Su Yue wrote:
User reported that test fsck-tests/037-freespacetree-repair
fails:
# TEST=037\* ./fsck-tests.sh
[TEST/fsck] 037-freespacetree-repair
btrfs check should have detected corruption
te
On Mon, Feb 15, 2021 at 05:20:11PM +0800, Su Yue wrote:
> User reported that test fsck-tests/037-freespacetree-repair fails:
> # TEST=037\* ./fsck-tests.sh
> [TEST/fsck] 037-freespacetree-repair
> btrfs check should have detected corruption
> test failed for case 037-freespacetree-repair
>
On Wed, Feb 17, 2021 at 03:12:46PM +0200, Nikolay Borisov wrote:
> Here are 4 patches which are independent of one another. The first 2 just
> change two more function to take btrfs_inode. Patch 3 just extends the usage
> of
> in_range which renders offset_in_entry redundant thus removing the func
On Wed, Feb 17, 2021 at 04:06:18PM +0900, Johannes Thumshirn wrote:
> Lockdep with fstests test-case btrfs/041 detected a unsafe locking
> scenario when we allocate the log node on a zoned filesystem.
>
> btrfs/041
>
> WARNING: possible recursive lock
On Thu, Feb 11, 2021 at 01:25:52PM +0200, Nikolay Borisov wrote:
>
>
> On 11.02.21 г. 0:50 ч., David Sterba wrote:
> > On Tue, Jan 26, 2021 at 09:30:45AM -0500, Josef Bacik wrote:
> >> On 1/26/21 4:02 AM, Nikolay Borisov wrote:
> >>> On 25.01.21 г. 23:42 ч., Josef Bacik wrote:
> In __btrfs_r
On Tue, Feb 16, 2021 at 11:09:25AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When using the NO_HOLES feature, if we clone a file range that spans only
> a hole into a range that is at or beyond the current i_size of the
> destination file, we end up not setting the full sync run
On Tue, Feb 16, 2021 at 03:43:22PM -0500, Josef Bacik wrote:
> The tree checker checks the extent ref hash at read and write time to
> make sure we do not corrupt the file system. Generally extent
> references go inline, but if we have enough of them we need to make an
> item, which looks like
>
On 17 February 2021 13:45:02 GMT+00:00, Hugo Mills wrote:
>On Wed, Feb 17, 2021 at 01:26:40PM +, Samir Benmendil wrote:
>> Hello list,
>>
>> I've just had my btrfs volume remounted read-only, the logs read as such:
>>
>>BTRFS critical (device dm-0): corrupt leaf: root=2 block=71187092
On 2/17/21 11:29 AM, Neal Gompa wrote:
On Wed, Feb 17, 2021 at 9:59 AM Josef Bacik wrote:
On 2/17/21 9:50 AM, Neal Gompa wrote:
On Wed, Feb 17, 2021 at 9:36 AM Josef Bacik wrote:
On 2/16/21 9:05 PM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 4:24 PM Josef Bacik wrote:
On 2/16/21 3:29 PM
Dear Btrfs folks,
I've got a few thoughts about the development, perception, progress, and
other things concerning Btrfs. I realized that these ideas center on
the presentation, and especially, documentation, of Btrfs.
Is there anything like a Btrfs subproject for documentation or "Btrfs
newbies
On Wed, Feb 17, 2021 at 9:59 AM Josef Bacik wrote:
>
> On 2/17/21 9:50 AM, Neal Gompa wrote:
> > On Wed, Feb 17, 2021 at 9:36 AM Josef Bacik wrote:
> >>
> >> On 2/16/21 9:05 PM, Neal Gompa wrote:
> >>> On Tue, Feb 16, 2021 at 4:24 PM Josef Bacik wrote:
>
> On 2/16/21 3:29 PM, Neal Gomp
On 2/17/21 9:50 AM, Neal Gompa wrote:
On Wed, Feb 17, 2021 at 9:36 AM Josef Bacik wrote:
On 2/16/21 9:05 PM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 4:24 PM Josef Bacik wrote:
On 2/16/21 3:29 PM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 1:11 PM Josef Bacik wrote:
On 2/16/21 11:27 AM
On Wed, Feb 17, 2021 at 9:36 AM Josef Bacik wrote:
>
> On 2/16/21 9:05 PM, Neal Gompa wrote:
> > On Tue, Feb 16, 2021 at 4:24 PM Josef Bacik wrote:
> >>
> >> On 2/16/21 3:29 PM, Neal Gompa wrote:
> >>> On Tue, Feb 16, 2021 at 1:11 PM Josef Bacik wrote:
>
> On 2/16/21 11:27 AM, Neal Gom
On 2/16/21 9:05 PM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 4:24 PM Josef Bacik wrote:
On 2/16/21 3:29 PM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 1:11 PM Josef Bacik wrote:
On 2/16/21 11:27 AM, Neal Gompa wrote:
On Tue, Feb 16, 2021 at 10:19 AM Josef Bacik wrote:
On 2/14/21 3:25 P
On Wed, Feb 17, 2021 at 01:26:40PM +, Samir Benmendil wrote:
> Hello list,
>
> I've just had my btrfs volume remounted read-only, the logs read as such:
>
>BTRFS critical (device dm-0): corrupt leaf: root=2 block=711870922752
> slot=275, bad key order, prev (693626798080 182 702129324032
Hello list,
I've just had my btrfs volume remounted read-only, the logs read as
such:
BTRFS critical (device dm-0): corrupt leaf: root=2 block=711870922752
slot=275, bad key order, prev (693626798080 182 702129324032) current
(693626798080 182 701861986304)
BTRFS info (device dm-0): le
btrfs_inc_block_group_ro wants to ensure that the current transaction is
not running dirty block groups, if it is it waits and loops again.
That logic is currently implemented using a goto label. Actually using
a proper do {} while() construct doesn't hurt readibility nor does it
introduce excessiv
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 5 +++--
fs/btrfs/file.c| 51 +++---
fs/btrfs/inode.c | 2 +-
fs/btrfs/reflink.c | 10 -
4 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctr
Here are 4 patches which are independent of one another. The first 2 just
change two more function to take btrfs_inode. Patch 3 just extends the usage of
in_range which renders offset_in_entry redundant thus removing the function.
Final patch just restructures btrfs_inc_block_group_ro to use a do{}
No point in duplicating the functionality just use the generic helper
we have.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ordered-data.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
index 985a21558437.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/file.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index a4e6fb43e3a7..1e68349c3884 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -3492,13 +3492,13 @@ static long btrfs_fa
On Wed, Feb 17, 2021 at 12:29 PM Qu Wenruo wrote:
>
>
>
> On 2021/2/17 下午8:12, Filipe Manana wrote:
> > On Wed, Feb 17, 2021 at 11:28 AM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2021/2/17 下午6:59, Filipe Manana wrote:
> >>> On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
>
>
>
> >
On 2021/2/17 下午8:12, Filipe Manana wrote:
On Wed, Feb 17, 2021 at 11:28 AM Qu Wenruo wrote:
On 2021/2/17 下午6:59, Filipe Manana wrote:
On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
On 2021/2/16 下午10:45, Filipe Manana wrote:
On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
[B
On Wed, Feb 17, 2021 at 11:28 AM Qu Wenruo wrote:
>
>
>
> On 2021/2/17 下午6:59, Filipe Manana wrote:
> > On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2021/2/16 下午10:45, Filipe Manana wrote:
> >>> On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
>
> [BUG]
> >
On 2021/2/17 下午6:59, Filipe Manana wrote:
On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
On 2021/2/16 下午10:45, Filipe Manana wrote:
On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
[BUG]
The following script could lead to corrupted btrfs fs after
btrfs-convert:
fallocate -l 1
On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
>
>
>
> On 2021/2/16 下午10:45, Filipe Manana wrote:
> > On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
> >>
> >> [BUG]
> >> The following script could lead to corrupted btrfs fs after
> >> btrfs-convert:
> >>
> >>fallocate -l 1G test.img
> >
On Tue, Feb 16, 2021 at 4:28 PM Sidong Yang wrote:
>
> Remove a code that inserting new line in fmt_end() for text mode.
> Old code made a failure in fstest btrfs/006.
>
> Signed-off-by: Sidong Yang
> ---
> Hi, I've just read mail that Filipe written that some failure about fstest.
> I'm worried
On Tue, Feb 16, 2021 at 8:46 PM Josef Bacik wrote:
>
> The tree checker checks the extent ref hash at read and write time to
> make sure we do not corrupt the file system. Generally extent
> references go inline, but if we have enough of them we need to make an
> item, which looks like
>
> key.ob
On Wed, Feb 17, 2021 at 7:38 AM Johannes Thumshirn
wrote:
>
> Lockdep with fstests test-case btrfs/041 detected a unsafe locking
> scenario when we allocate the log node on a zoned filesystem.
>
> btrfs/041
>
> WARNING: possible recursive locking dete
On Tue, Feb 16, 2021 at 8:45 PM Josef Bacik wrote:
>
> This is a regression test for a problem where we would flip read only if
> we reflink'ed enough extents to generate key'ed references, and then got
> a hash collision with those references. This is a test for the fix
>
> btrfs: do not
40 matches
Mail list logo
