On 30/08/2019 17:06, David Sterba wrote:
> On Fri, Aug 30, 2019 at 01:36:07PM +0200, Johannes Thumshirn wrote:
>> Now that Nikolay's XXHASH64 support for the Crypto API has landed and BTRFS
>> is
>> prepared for an easy addition of new checksums, this patchset implements
>> XXHASH64 as a second, f
Hi!
I'm afraid that asciidoctor 2.0 dropped support for docbook45. The
explanation given is here:
https://github.com/asciidoctor/asciidoctor/issues/3005
This makes btrfs-progs fail to build unless docs are off, with:
asciidoctor: FAILED: missing converter for backend 'docbook45'. Processing
abor
On Mon, Sep 02, 2019 at 08:39:19PM +0200, David Sterba wrote:
> On Thu, Aug 29, 2019 at 11:14:05AM +0200, Stanislaw Gruszka wrote:
> > This patch adds -p option for 'fi df' and 'fi show' commands to print
> > procentate of used space. Output with the option will look like on
> > example below:
> >
Before this patch, btrfs check can only repair bad free space cache
inode mode (as it was the first case detected by tree-checker and reported)
But now what may happen finally happened, we have user reorting bad
inode mode in subvolumes trees.
Although the reported get the fs fixed by removing th
For lowmem mode, if we hit a bad inode mode, normally it is reported
when we checking the DIR_INDEX/DIR_ITEM of the parent inode.
If we didn't repair at that timing, the error will be recorded even we
fixed it later.
So this patch will check for INODE_ITEM_MISMATCH error type, and if it's
really
Before this patch, repair_imode_common() can only handle two types of
inodes:
- Free space cache inodes
- ROOT DIR inodes
For inodes in subvolume trees, the problem is how to determine the
correct imode, thus it was not implemented.
However there are more reports of incorrect imode in subvolume t
Add new test image for imode repair in subvolume trees.
Also rename the existing test case 039-bad-free-space-cache-inode-mode
to 039-bad-inode-mode, since now we can fix all bad imode.
And add the beacon file for lowmem test.
Signed-off-by: Qu Wenruo
---
.../039-bad-inode-mode/.lowmem_repaira
To make original mode to repair imode error in subvolume trees, this
patch will do:
- Remove the show-stopper checks for root->objectid.
Now repair_imode_original() will accept inodes in subvolume trees.
- Export detect_imode() for original mode
Due to the call requirement, original mode must
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba
Date: Thu May 2 16:53:47 2019 +0200
btrfs: s
On 3.09.19 г. 11:55 ч., Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
> P9 box running mainline kernel 5.3.0-rc5
>
> BUG_ON was first introduced by below commit
>
> commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
> Author:
Hi Anand,
This patch breaks misc-tests/021-image-multi-devices for me:
jthumshirn@adalid:btrfs-progs ((b41eba548d89...)|BISECTING)$ git bisect log
git bisect start
# good: [9a85732d8beaae4b80cab98bb3355660389c1d36] Btrfs progs v5.2.1
git bisect good 9a85732d8beaae4b80cab98bb3355660389c1d36
# bad:
On 9/3/19 10:17 AM, Adam Borowski wrote:
Hi!
I'm afraid that asciidoctor 2.0 dropped support for docbook45. The
explanation given is here:
https://github.com/asciidoctor/asciidoctor/issues/3005
This makes btrfs-progs fail to build unless docs are off, with:
asciidoctor: FAILED: missing converte
On 2019-09-01 21:09, Chris Murphy wrote:
I'm still mostly convinced the policy questions and management should
be dealt with a btrfsd userspace daemon.
Btrfs kernel code itself tolerates quite a lot of read and write
errors, where a userspace service could say, yeah forget that we're
moving over
On Mon, Sep 02, 2019 at 06:22:30PM +0200, David Sterba wrote:
> On Mon, Sep 02, 2019 at 04:01:56PM +0800, Anand Jain wrote:
> >
> > David,
> >
> > I don't see this patch is integrated. Can you please integrated this
> > patch thanks.
>
> I don't know why but the patch got lost somewhere, addi
The test-case 'misc-tests/025-zstd-compression' is failing on a kernel
without zstd compression support.
Check if zstd compression is supported by the kernel and if not skip the
test-case.
Signed-off-by: Johannes Thumshirn
---
tests/misc-tests/025-zstd-compression/test.sh | 5 +
1 file chan
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
> P9 box running mainline kernel 5.3.0-rc5
>
> BUG_ON was first introduced by below commit
Well, technically the bug_on was there already
On 18:43 02/09, Christoph Hellwig wrote:
> On Sun, Sep 01, 2019 at 03:08:21PM -0500, Goldwyn Rodrigues wrote:
> > This is an effort to use iomap for btrfs. This would keep most
> > responsibility of page handling during writes in iomap code, hence
> > code reduction. For CoW support, changes are ne
Hi all,
This is my first message in this list. I'm looking for advice because I have a
weird silent data corruption and maybe with btrfs and the checksum capability
this could be, at least, notified to the system, and detected using some
btrfs-utils tool or dmesg.
Imagine you have an SSD with
On 18:31 02/09, Christoph Hellwig wrote:
> On Sun, Sep 01, 2019 at 03:08:23PM -0500, Goldwyn Rodrigues wrote:
> > --- a/include/linux/iomap.h
> > +++ b/include/linux/iomap.h
> > @@ -37,6 +37,7 @@ struct vm_fault;
> > #define IOMAP_MAPPED 0x03/* blocks allocated at @addr */
> > #define I
On 20:18 02/09, Darrick J. Wong wrote:
> On Mon, Sep 02, 2019 at 06:31:04PM +0200, Christoph Hellwig wrote:
> > On Sun, Sep 01, 2019 at 03:08:23PM -0500, Goldwyn Rodrigues wrote:
> > > --- a/include/linux/iomap.h
> > > +++ b/include/linux/iomap.h
> > > @@ -37,6 +37,7 @@ struct vm_fault;
> > > #def
On 2019/9/3 下午9:50, Jorge Fernandez Monteagudo wrote:
> Hi all,
>
> This is my first message in this list. I'm looking for advice because I have
> a weird silent data corruption and maybe with btrfs and the checksum
> capability this could be, at least, notified to the system, and detected
>
On Tue, Sep 03, 2019 at 09:05:36AM -0500, Goldwyn Rodrigues wrote:
> On 18:31 02/09, Christoph Hellwig wrote:
> > On Sun, Sep 01, 2019 at 03:08:23PM -0500, Goldwyn Rodrigues wrote:
> > > --- a/include/linux/iomap.h
> > > +++ b/include/linux/iomap.h
> > > @@ -37,6 +37,7 @@ struct vm_fault;
> > > #d
Now that Nikolay's XXHASH64 support for the Crypto API has landed and BTRFS is
prepared for an easy addition of new checksums, this patchset implements
XXHASH64 as a second, fast but not cryptographically secure checksum hash.
For changes since v2, please see the individual patches. Additionally a
Signed-off-by: Johannes Thumshirn
---
btrfs-sb-mod.c | 9 ++---
check/main.c| 2 +-
cmds/inspect-dump-super.c | 3 ++-
cmds/rescue-chunk-recover.c | 2 +-
convert/common.c| 3 ++-
disk-io.c | 12 ++--
disk-io.h
Cache the super-block's checksum type field in 'struct recover_control'.
This will be needed for further refactoring the checksum handling.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
cmds/rescue-chunk-recover.c | 2 ++
ctree.h | 4 +++-
2 files change
With the introduction of xxhash64 to btrfs-progs we created a crypto/
directory for all the hashes used in btrfs (although no
cryptographically secure hash is there yet).
Move the crc32c implementation from kernel-lib/ to crypto/ as well so we
have all hashes consolidated.
Signed-off-by: Johannes
In preparation to supporting new checksum algorithm pass the checksum type
to btrfs_csum_data/btrfs_csum_final, this allows us to encapsulate any
differences in processing into the respective functions
Signed-off-by: Johannes Thumshirn
---
Changes to v1:
- Update changelog and squashed the other
From: David Sterba
Update the checksumming API to be able to cope with more checksum types
than just CRC32C.
Co-developed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Johannes Thumshirn
---
btrfs-sb-mod.c | 21 ++--
check/main.c| 20 +++
From: David Sterba
Add xxhash64 as another checksumming algorithm.
Signed-off-by: David Sterba
Signed-off-by: Johannes Thumshirn
---
Changes to v3:
- Fix usage of is_valid_csum_type() (Nikolay)
- Remove unrelated whitespace change (Nikolay)
Changes to v2:
- Integrated comments from Nikolay
-
The callers of csum_tree_block_size() blindly assume we're only having
crc32c as a possible checksum and thus pass in
btrfs_csum_sizes[BTRFS_CSUM_TYPE_CRC32] for the size argument of
csum_tree_block_size().
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
mkfs/common.c | 14 ++
Add the checksum type to csum_tree_block_size(), __csum_tree_block_size()
and verify_tree_block_csum_silent().
Signed-off-by: Johannes Thumshirn
---
btrfs-corrupt-block.c | 3 ++-
cmds/rescue-chunk-recover.c | 3 ++-
convert/common.c| 3 ++-
convert/main.c | 3
From: David Sterba
git://github.com/Cyan4973/xxHash
Signed-off-by: David Sterba
Signed-off-by: Johannes Thumshirn
---
crypto/xxhash.c | 1025 +++
crypto/xxhash.h | 445
2 files changed, 1470 insertions(+)
create mo
Add test-cases for creating a file-system xxhash64 as checksumming
algorithm.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
tests/mkfs-tests/001-basic-profiles/test.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/mkfs-tests/001-basic-profiles/test.sh
b/tests
update_block_csum() in btrfs-sb-mod.c is always called with the 'is_sb'
argument set to 1.
Get rid of the special case for is_sb == 0.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
btrfs-sb-mod.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
d
Add an option to mkfs to specify which checksum algorithm will be used for
the filesystem.
Signed-off-by: Johannes Thumshirn
---
convert/common.c | 2 +-
mkfs/common.c| 2 +-
mkfs/main.c | 21 -
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/conver
On Mon, Sep 02, 2019 at 07:18:00PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 02, 2019 at 10:09:16AM -0700, Darrick J. Wong wrote:
> > On Mon, Sep 02, 2019 at 06:29:34PM +0200, Christoph Hellwig wrote:
> > > On Sun, Sep 01, 2019 at 03:08:22PM -0500, Goldwyn Rodrigues wrote:
> > > > From: Goldwyn
On Tue, Sep 03, 2019 at 10:17:04AM +0200, Adam Borowski wrote:
> I'm afraid that asciidoctor 2.0 dropped support for docbook45. The
> explanation given is here:
> https://github.com/asciidoctor/asciidoctor/issues/3005
>
> This makes btrfs-progs fail to build unless docs are off, with:
> asciidoct
On Tue, Sep 03, 2019 at 02:27:21PM +0200, Johannes Thumshirn wrote:
> The test-case 'misc-tests/025-zstd-compression' is failing on a kernel
> without zstd compression support.
>
> Check if zstd compression is supported by the kernel and if not skip the
> test-case.
>
> Signed-off-by: Johannes Th
From: Nikolay Borisov
[ Upstream commit 5eaad97af8aeff38debe7d3c69ec3a0d71f8350f ]
This callback is called only from writepage_delalloc which in turn is
guaranteed to be called from the data page writeout path. In the end
there is no reason to have the call to this function to be indrected via
t
From: David Sterba
[ Upstream commit 0e94c4f45d14cf89d1f40c91b0a8517e791672a7 ]
The scrub context is allocated with GFP_KERNEL and called from
btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe
regarding reclaim that could try to flush filesystem data in order to
get the memo
From: Johannes Thumshirn
[ Upstream commit aa53e3bfac7205fb3a8815ac1c937fd6ed01b41e ]
Nikolay reported the following KASAN splat when running btrfs/048:
[ 1843.470920]
==
[ 1843.471971] BUG: KASAN: slab-out-of-bounds in strncmp+0x
From: Filipe Manana
[ Upstream commit 8eaf40c0e24e98899a0f3ac9d25a33aafe13822a ]
If a task is removing the block group that currently has the highest start
offset amongst all existing block groups, there is a short time window
where it races with a concurrent block group allocation, resulting in
From: Dan Robertson
[ Upstream commit e49be14b8d80e23bb7c53d78c21717a474ade76b ]
The scrub_ctx csum_list member must be initialized before scrub_free_ctx
is called. If the csum_list is not initialized beforehand, the
list_empty call in scrub_free_csums will result in a null deref if the
allocati
From: Anand Jain
[ Upstream commit 1cec3f27168d7835ff3d23ab371cd548440131bb ]
This fixes a longstanding lockdep warning triggered by
fstests/btrfs/011.
Circular locking dependency check reports warning[1], that's because the
btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lo
From: David Sterba
[ Upstream commit 92f7ba434f51e8e9317f1d166105889aa230abd2 ]
We can pass fs_info directly as this is the only member of btrfs_device
that's bing used inside scrub_setup_ctx.
Reviewed-by: Nikolay Borisov
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/s
From: Qu Wenruo
[ Upstream commit 05a37c48604c19b50873fd9663f9140c150469d1 ]
Add extra dev extent end check against device boundary.
Signed-off-by: Qu Wenruo
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
---
fs/btrfs/volumes.c | 17 +
1 fi
From: Qu Wenruo
[ Upstream commit 1b3922a8bc74231f9a767d1be6d9a061a4d4eeab ]
[BUG]
Linux v5.0-rc1 will fail fstests/btrfs/163 with the following kernel
message:
BTRFS error (device dm-6): dev extent devid 1 physical offset 13631488 len
8388608 is beyond device boundary 0
BTRFS error (devic
From: Nikolay Borisov
[ Upstream commit d1051d6ebf8ef3517a5a3cf82bba8436d190f1c2 ]
Running btrfs/124 in a loop hung up on me sporadically with the
following call trace:
btrfs D0 5760 5324 0x
Call Trace:
? __schedule+0x243/0x800
schedule
From: Filipe Manana
[ Upstream commit a5fb11429167ee6ddeeacc554efaf5776b36433a ]
When a transaction commit starts, it attempts to pause scrub and it blocks
until the scrub is paused. So while the transaction is blocked waiting for
scrub to pause, we can not do memory allocation with GFP_KERNEL f
From: Omar Sandoval
[ Upstream commit 32934280967d00dc2b5c4d3b63b21a9c8638326e ]
struct scrub_ctx has an ->is_dev_replace member, so there's no point in
passing around is_dev_replace where sctx is available.
Signed-off-by: Omar Sandoval
Signed-off-by: David Sterba
Signed-off-by: Sasha Levin
On Wed, Aug 28, 2019 at 02:06:50PM +0200, David Sterba wrote:
> On Thu, Aug 15, 2019 at 02:04:06PM -0700, Omar Sandoval wrote:
> > #define BTRFS_IOC_SEND_32 _IOW(BTRFS_IOCTL_MAGIC, 38, \
> >struct btrfs_ioctl_send_args_32)
> > +
> > +struct btrfs_ioctl_compressed_pwrite
Hi all,
two days ago my btrfs filesystem became quite slow and the logs showed a
lot of I/O errors on one of the HDDs. I ordered a replacement drive and
tried to remove the failing drive from the filesystem (btrfs device
remove). That removal command did not finish but just sat there without
any
On Tue, Sep 3, 2019 at 2:20 PM Edmund Urbani wrote:
>
>
> Hi all,
>
> two days ago my btrfs filesystem became quite slow and the logs showed a
> lot of I/O errors on one of the HDDs. I ordered a replacement drive and
> tried to remove the failing drive from the filesystem (btrfs device
> remove).
raid56 status grid says Unstable, but the body text below says
"Feature marked as mostly OK for now."
Both might be true. The feature with this version of the feature flag
might be mostly OK, with the write hole. But if an intent log will be
needed to fix it, and if it suggests a new feature flag,
Anybody notice this?
--Hongzhi
On 7/17/19 4:34 PM, Hongzhi, Song wrote:
Hi friends,
*Description:*
One LTP testcase, fs_fill.c, fails on btrfs with kernel error when
unlink files on Btrfs device:
"BTRFS warning (device loop0): could not allocate space for a
delete; will truncate
I remake the test case to be more simply.
And the send the new email.
Thanks,
--Hongzhi
On 9/4/19 10:36 AM, Hongzhi, Song wrote:
Anybody notice this?
--Hongzhi
On 7/17/19 4:34 PM, Hongzhi, Song wrote:
Hi friends,
*Description:*
One LTP testcase, fs_fill.c, fails on btrfs with kern
On 09/04/2019 01:30 AM, Chris Murphy wrote:
> On Tue, Sep 3, 2019 at 2:20 PM Edmund Urbani wrote:
>>
>> Hi all,
>>
>> two days ago my btrfs filesystem became quite slow and the logs showed a
>> lot of I/O errors on one of the HDDs. I ordered a replacement drive and
>> tried to remove the failin
On Tue, Sep 3, 2019 at 10:41 PM Edmund Urbani wrote:
>
> Also there are a few of these:
> Sep 1 21:10:17 phoenix kernel: ata6.00: exception Emask 0x0 SAct
> 0x1020 SErr 0x0 action 0x0
> Sep 1 21:10:17 phoenix kernel: ata6.00: irq_stat 0x4008
> Sep 1 21:10:17 phoenix kernel: ata6.00: fai
Hi Qu, thanks for answering!
>RO of the ext4, and still get corruption? Definitely looks like a
>hardware problem to me.
It's a weird error, because rebooting the machine the previous error disapears
and the file could be read ok, then we know that the info in disk is ok. Then,
the suspects lis
Hi list,
Is there an advised way to completely “clone” a complete BTRFS
filesystem, I mean to get an exact copy of a BTRFS filesystem including
subvolumes (even readonly snapshots) and complete file attributes
including extended attributes, ACLs and so, to another storage pool,
possibly defined wi
On 09/04/2019 07:36 AM, Chris Murphy wrote:
> On Tue, Sep 3, 2019 at 10:41 PM Edmund Urbani
> wrote:
>> Also there are a few of these:
>> Sep 1 21:10:17 phoenix kernel: ata6.00: exception Emask 0x0 SAct
>> 0x1020 SErr 0x0 action 0x0
>> Sep 1 21:10:17 phoenix kernel: ata6.00: irq_stat 0x4
Hi all!
Is it possible to get a crypted btrfs in a file? Currently I'm doing this to
get a crypted ISO filesystem in a file:
# genisoimage -R -J -iso-level 4 -o iso.img
# fallocate iso-crypted.img -l $(stat --printf="%s" iso.img)
# cryptsetup -d create test iso-crypted.img
# dd if=iso.img of=/
On 2019/9/4 下午2:08, Jorge Fernandez Monteagudo wrote:
> Hi Qu, thanks for answering!
>
>> RO of the ext4, and still get corruption? Definitely looks like a
>> hardware problem to me.
>
> It's a weird error, because rebooting the machine the previous error
> disapears and the file could be read
63 matches
Mail list logo
