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
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
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
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
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)
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
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
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,
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 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 下午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 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 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 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 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 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
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 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
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 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
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 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
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 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 下午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
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 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.
>
>
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 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
30 matches
Mail list logo
