On Wed, Feb 17, 2021 at 11:24 PM Qu Wenruo wrote:
> 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] re
On 2021/2/18 下午3:59, Erik Jensen wrote:
On Wed, Feb 17, 2021 at 11:24 PM Qu Wenruo wrote:
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.
[ 2
On Thu, Feb 18, 2021 at 12:38 AM Qu Wenruo wrote:
> We got it!
>
> The eb->start mismatch with page_offset(), this means something is wrong
> with page->index.
>
> Considering page->index is just unsigned long thus when we initialize
> page->index using a real u64, we truncated some high bits.
>
>
Hi,
Recently we got a strange bug report that, one 32bit systems like armv6
or non-64bit x86, certain large btrfs can't be mounted.
It turns out that, since page->index is just unsigned long, and on 32bit
systemts, that can just be 32bit.
And when filesystems is utilizing any page offset over 4
On 2021/2/18 下午4:52, Erik Jensen wrote:
On Thu, Feb 18, 2021 at 12:38 AM Qu Wenruo wrote:
We got it!
The eb->start mismatch with page_offset(), this means something is wrong
with page->index.
Considering page->index is just unsigned long thus when we initialize
page->index using a real u64
On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
> Recently we got a strange bug report that, one 32bit systems like armv6
> or non-64bit x86, certain large btrfs can't be mounted.
>
> It turns out that, since page->index is just unsigned long, and on 32bit
> systemts, that can just be 3
On 2021/2/18 下午8:15, Matthew Wilcox wrote:
On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
Recently we got a strange bug report that, one 32bit systems like armv6
or non-64bit x86, certain large btrfs can't be mounted.
It turns out that, since page->index is just unsigned long, an
On Thu, Feb 18, 2021 at 08:42:14PM +0800, Qu Wenruo wrote:
> On 2021/2/18 下午8:15, Matthew Wilcox wrote:
> > Yes, this is a known limitation. Some vendors have gone to the trouble
> > of introducing a new page_index_t. I'm not convinced this is a problem
> > worth solving. There are very few 32-b
There are two objectives of this test case. 1. by default, with
LOAD_FACTOR = 1, it sanity tests the read policies. And 2. Run the
test case individually with a larger LOAD_FACTOR. For example, 10
for the comparative study of the read policy performance.
LOAD_FACTOR parameter controls the fio scal
On 8.01.21 г. 7:36 ч., Qu Wenruo wrote:
> There are several qgroup flush related bugs fixed recently, all of them
> are caused by the fact that we can trigger qgroup metadata space
> reservation holding a transaction handle.
>
> Thankfully the only situation to trigger above reservation is
> bt
On 1/8/21 12:36 AM, Qu Wenruo wrote:
There are several qgroup flush related bugs fixed recently, all of them
are caused by the fact that we can trigger qgroup metadata space
reservation holding a transaction handle.
Thankfully the only situation to trigger above reservation is
btrfs_dirty_inode(
On Wed, Feb 17, 2021 at 11:24:18AM +0800, Ruan Shiyang wrote:
>
>
> On 2021/2/10 下午9:19, Christoph Hellwig wrote:
> > On Tue, Feb 09, 2021 at 05:46:13PM +0800, Ruan Shiyang wrote:
> > >
> > >
> > > On 2021/2/9 下午5:34, Christoph Hellwig wrote:
> > > > On Tue, Feb 09, 2021 at 05:15:13PM +0800, Ru
btrfs_chunk_alloc() uses dev_alloc_list to allocate new chunks. The
function's stack leading to btrfs_cmp_device_info() sorts the
dev_alloc_list in the descending order of unallocated space. This
sorting helps to maximize the filesystem space.
But, there might be other types of preferences when al
On 2/18/21 6:20 PM, Anand Jain wrote:
btrfs_chunk_alloc() uses dev_alloc_list to allocate new chunks. The
function's stack leading to btrfs_cmp_device_info() sorts the
dev_alloc_list in the descending order of unallocated space. This
sorting helps to maximize the filesystem space.
But, there mig
On Feb 17, 2021 at 16:56, Samir Benmendil wrote:
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:
Any advice on what to do next would be appreciated.
The first thing to do is run memtest for a while (I'd usually
reco
On Thu, Feb 18, 2021 at 08:46:02PM +, Samir Benmendil wrote:
> On Feb 17, 2021 at 16:56, Samir Benmendil wrote:
> > 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:
> > > > Any advice on what to do next would b
On 2/18/21 4:15 AM, Matthew Wilcox wrote:
On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
Recently we got a strange bug report that, one 32bit systems like armv6
or non-64bit x86, certain large btrfs can't be mounted.
It turns out that, since page->index is just unsigned long, and o
On Wed, Feb 17, 2021 at 7:43 PM Daniel Dawson wrote:
>
> I was attempting to replace the drives in an array with RAID6 profile.
metadata raid6 as well?
What replacement command(s) are you using?
> The first replacement was seemingly successful (and there was a scrub
> afterward, with no errors
On 2021/2/18 下午11:28, Nikolay Borisov wrote:
On 8.01.21 г. 7:36 ч., Qu Wenruo wrote:
There are several qgroup flush related bugs fixed recently, all of them
are caused by the fact that we can trigger qgroup metadata space
reservation holding a transaction handle.
Thankfully the only situat
On 2021/2/19 上午12:14, Josef Bacik wrote:
On 1/8/21 12:36 AM, Qu Wenruo wrote:
There are several qgroup flush related bugs fixed recently, all of them
are caused by the fact that we can trigger qgroup metadata space
reservation holding a transaction handle.
Thankfully the only situation to tr
On 2021/2/18 下午9:39, Matthew Wilcox wrote:
On Thu, Feb 18, 2021 at 08:42:14PM +0800, Qu Wenruo wrote:
On 2021/2/18 下午8:15, Matthew Wilcox wrote:
Yes, this is a known limitation. Some vendors have gone to the trouble
of introducing a new page_index_t. I'm not convinced this is a problem
wor
On 2/18/21 3:57 PM, Chris Murphy wrote:
> metadata raid6 as well?
Yes.
> What replacement command(s) are you using?
For this drive, it was "btrfs replace start -r 3 /dev/sda3 /"
> What device is devid 3?
It would normally be sdc3. I'll address the confusion below.
> 16315=0x3fbb, 16283=0x3f9b,
ceturtd., 2021. g. 14. janv., plkst. 01:39 — lietotājs Dāvis Mosāns
() rakstīja:
>
> >
> > Hi,
> >
> > I've 6x 3TB HDD RAID1 BTRFS filesystem where HBA card failed and
> > caused some corruption.
> > When I try to mount it I get
> > $ mount /dev/sdt /mnt
> > mount: /mnt/: wrong fs type, bad option,
On 19/02/2021 03:11, Goffredo Baroncelli wrote:
On 2/18/21 6:20 PM, Anand Jain wrote:
btrfs_chunk_alloc() uses dev_alloc_list to allocate new chunks. The
function's stack leading to btrfs_cmp_device_info() sorts the
dev_alloc_list in the descending order of unallocated space. This
sorting helps
Hi, Josef Bacik
We noticed an error in 5.10.x backport of 'btrfs: fix possible free
space tree corruption with online conversion'
It is wrong in 5.10.13, but right in 5.11.
5.10.13
@@ -146,6 +146,9 @@ enum {
BTRFS_FS_STATE_DEV_REPLACING,
/* The btrfs_fs_info created for self-test
Hi Linus,
Please pull these new changes to the iomap code for 5.12. The big
change in this cycle is some new code to make it possible for XFS to try
unaligned directio overwrites without taking locks. If the block is
fully written and within EOF (i.e. doesn't require any further fs
intervention)
On Thu, Feb 18, 2021 at 6:12 PM Daniel Dawson wrote:
>
> On 2/18/21 3:57 PM, Chris Murphy wrote:
> > metadata raid6 as well?
>
> Yes.
Once everything else is figured out, you should consider converting
metadata to raid1c3.
https://lore.kernel.org/linux-btrfs/20200627032414.gx10...@hungrycats.org
On Thu, Feb 18, 2021 at 8:08 PM Dāvis Mosāns wrote:
>
> ceturtd., 2021. g. 14. janv., plkst. 01:39 — lietotājs Dāvis Mosāns
> () rakstīja:
> >
> > >
> > > Hi,
> > >
> > > I've 6x 3TB HDD RAID1 BTRFS filesystem where HBA card failed and
> > > caused some corruption.
> > > When I try to mount it I g
Fix the following coccicheck warnings:
./fs/btrfs/disk-io.c:4403:5-8: Unneeded variable: "ret". Return "0" on
line 4411.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
fs/btrfs/disk-io.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/disk-io.c
Fix build warnings of function signature when CONFIG_STACKTRACE is not
enabled by reordering the 'inline' and 'void' keywords.
../fs/btrfs/ref-verify.c:221:1: warning: ‘inline’ is not at beginning of
declaration [-Wold-style-declaration]
static void inline __save_stack_trace(struct ref_action *r
30 matches
Mail list logo
