Since commit 90020a760584 ("btrfs-progs: mkfs: refactor how we handle
sectorsize override") we have extra warning message if the sectorsize of
mkfs doesn't match page size.
But this warning is show as stderr, which makes a lot of fstests cases
failure due to golden output mismatch.
Fix this by ma
hi,
First thanks for your patchset.
I'd like to know whether your patchset pass fstests? Thanks.
Regards,
Xiaoguang Wang
This patchset is attempt to add CoW support for fsdax, and take XFS,
which has both reflink and fsdax feature, as an example.
Changes from V1:
- Factor some helper functi
On Mon, Mar 8, 2021 at 5:04 PM Josef Bacik wrote:
>
> On 3/8/21 3:01 PM, Neal Gompa wrote:
> > On Mon, Mar 8, 2021 at 1:38 PM Josef Bacik wrote:
> >>
> >> On 3/5/21 8:03 PM, Neal Gompa wrote:
> >>> On Fri, Mar 5, 2021 at 5:01 PM Josef Bacik wrote:
>
> On 3/5/21 9:41 AM, Neal Gompa wrot
On Tue, Aug 4, 2020 at 3:29 PM Qu Wenruo wrote:
>
> [BUG]
> When running btrfs/071 with inode_need_compress() removed from
> compress_file_range(), we got the following crash:
>
> BUG: kernel NULL pointer dereference, address: 0018
> #PF: supervisor read access in kernel mode
> #
On 3/8/21 3:01 PM, Neal Gompa wrote:
On Mon, Mar 8, 2021 at 1:38 PM Josef Bacik wrote:
On 3/5/21 8:03 PM, Neal Gompa wrote:
On Fri, Mar 5, 2021 at 5:01 PM Josef Bacik wrote:
On 3/5/21 9:41 AM, Neal Gompa wrote:
On Fri, Mar 5, 2021 at 9:12 AM Josef Bacik wrote:
On 3/4/21 6:54 PM, Neal G
On 26.02.2021 18:00 David Sterba wrote:
> On Fri, Jan 08, 2021 at 12:02:48AM +, Martin Raiber wrote:
>> When reading from btrfs file via io_uring I get following
>> call traces:
>>
>> [<0>] wait_on_page_bit+0x12b/0x270
>> [<0>] read_extent_buffer_pages+0x2ad/0x360
>> [<0>] btree_read_extent_buf
On 3/5/21 8:03 PM, Neal Gompa wrote:
On Fri, Mar 5, 2021 at 5:01 PM Josef Bacik wrote:
On 3/5/21 9:41 AM, Neal Gompa wrote:
On Fri, Mar 5, 2021 at 9:12 AM Josef Bacik wrote:
On 3/4/21 6:54 PM, Neal Gompa wrote:
On Thu, Mar 4, 2021 at 3:25 PM Josef Bacik wrote:
On 3/3/21 2:38 PM, Neal G
On Thu, Mar 04, 2021 at 06:44:19PM +0100, David Sterba wrote:
> On Tue, Feb 23, 2021 at 12:08:46PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > The first patch fixes a race between fsync and memory mapped writes, which
> > can result in corruptions. The second one fixes a dif
On Thu, Mar 04, 2021 at 06:47:41PM +0100, David Sterba wrote:
> On Wed, Feb 10, 2021 at 05:14:32PM -0500, Josef Bacik wrote:
> > v1->v2:
> > - Rebase against misc-next.
> > - Add Filipe's reviewed-bys.
> >
> > --- Original email ---
> >
> > Hello,
> >
> > Both Filipe and I have found different i
On Wed, Mar 03, 2021 at 06:41:51PM +0800, Qu Wenruo wrote:
> There is a piece of weird code in insert_prealloc_file_extent(), which
> looks like:
>
> ret = btrfs_qgroup_release_data(inode, file_offset, len);
> if (ret < 0)
> return ERR_PTR(ret);
> if (trans) {
>
On Mon, Mar 08, 2021 at 05:20:17PM +0800, Qu Wenruo wrote:
> [BUG]
> Btrfs fails at generic/091 test case, with the following output:
>
> fsx -N 1 -o 128000 -l 50 -r PSIZE -t BSIZE -w BSIZE -Z -W
> mapped writes DISABLED
> Seed set to 1
> main: filesystem does not support fallocate
On Sun, Mar 07, 2021 at 08:57:37AM -0500, Sasha Levin wrote:
> From: Qu Wenruo
>
> [ Upstream commit c28ea613fafad910d08f67efe76ae552b1434e44 ]
>
> [BUG]
> When running fstresss, we can hit strange data csum mismatch where the
> on-disk data is in fact correct (passes scrub).
>
> With some extr
On Mon, Mar 08, 2021 at 12:13:17AM +0100, Adam Borowski wrote:
> On Fri, Mar 05, 2021 at 02:36:05PM +0100, David Sterba wrote:
> > btrfs-progs version 5.11 have been released.
>
> W: btrfs-progs source: absolute-symbolic-link-target-in-source
> ci/images/ci-centos-7-x86_64/docker-build ->
> /hom
On 2021/3/8 下午6:02, chil L1n wrote:
Hi Qu,
Thanks for some explanation.
Personally, I prefer binary to compare bit-level changes.
Actually, I also miscounted. I count 3 bit flips.
Yes, you're right, xor also returns 3 bits flips.
But the point is not about directly comparing the two key of
Hi Qu,
Thanks for some explanation.
Personally, I prefer binary to compare bit-level changes.
Actually, I also miscounted. I count 3 bit flips. Isn't that extremely
unlikely, assuming that each bit flip is independent?
Nonetheless, I'm running another RAM test with memtester and 6GB RAM
blocks
On 2021/3/8 下午5:23, Qu Wenruo wrote:
On 2021/3/8 下午4:56, chil L1n wrote:
Hi Johannes,
Thanks for the advice. I'm running memtester now. This will take some
time as the machine has 32GB RAM.
Regarding your explanation, I count two bit position differences, not
1. Can you explain your reason
On 2021/3/8 下午5:23, Qu Wenruo wrote:
On 2021/3/8 下午4:56, chil L1n wrote:
Hi Johannes,
Thanks for the advice. I'm running memtester now. This will take some
time as the machine has 32GB RAM.
Regarding your explanation, I count two bit position differences, not
1. Can you explain your reason
On 2021/3/8 下午4:56, chil L1n wrote:
Hi Johannes,
Thanks for the advice. I'm running memtester now. This will take some
time as the machine has 32GB RAM.
Regarding your explanation, I count two bit position differences, not
1. Can you explain your reasoning?
It looks like Johannes missed one
[BUG]
Btrfs fails at generic/091 test case, with the following output:
fsx -N 1 -o 128000 -l 50 -r PSIZE -t BSIZE -w BSIZE -Z -W
mapped writes DISABLED
Seed set to 1
main: filesystem does not support fallocate mode FALLOC_FL_COLLAPSE_RANGE,
disabling!
main: filesystem does not s
Hi Johannes,
Thanks for the advice. I'm running memtester now. This will take some
time as the machine has 32GB RAM.
Regarding your explanation, I count two bit position differences, not
1. Can you explain your reasoning?
Thanks,
chill
On Mon, Mar 8, 2021 at 9:41 AM Johannes Thumshirn
wrote:
On 06/03/2021 10:11, chil L1n wrote:
> [211.868642] BTRFS critical (device sda4): corrupt leaf: root=258
> block=250975895552 slot=78, bad key order, prev (256703 108 3276800)
> current (256703 108 1310720)
> [211.868650] BTRFS error (device sda4): block=250975895552 write
> time tree block
21 matches
Mail list logo
