Hi,
It passed the test. Thanks a lot.
Best Regards
Wang Yugui (wangyu...@e16-tech.com)
2021/03/06
> [BUG]
> When btrfs-check is executed on even newly created fs, it can report
> tree blocks crossing 64K page boundary like this:
>
> Opening filesystem to check...
> Checking filesystem on /d
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 Gompa wrot
[BUG]
When btrfs-check is executed on even newly created fs, it can report
tree blocks crossing 64K page boundary like this:
Opening filesystem to check...
Checking filesystem on /dev/test/test
UUID: 80d734c8-dcbc-411b-9623-a10bd9e7767f
[1/7] checking root items
[2/7] checking extents
On 2021/3/2 下午6:36, Wang Yugui wrote:
Hi,
This is a full mkfs.btrtfs log
[root@T7610 ~]# mkfs.btrfs -O no-holes -R free-space-tree /dev/sdb1 -f
btrfs-progs v5.10.1
See http://btrfs.wiki.kernel.org for more information.
Detected a SSD, turning off metadata duplication. Mkfs with -m dup if y
On 2021/3/6 上午1:26, Chris Murphy wrote:
Hi,
Downstream user is running into this bug:
https://github.com/kdave/btrfs-progs/issues/349
But additionally the scrub of this converted file system, which still
has ext2_saved/image, produces this message:
[36365.549230] BTRFS error (device sda8):
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 Gompa wrote:
On Wed, Mar 3, 2021 at 1:42 PM Josef Bacik wrote:
On 2/24/21 10:47 PM, Neal
The pull request you sent on Fri, 5 Mar 2021 16:55:17 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.12-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f09b04cc6447331e731629e8b72587287f3a4490
Thank you!
--
Deet-doot-dot, I am a
Hello,
I am using linux 5.9.1 and have experienced tracebacks in conjunction
with btrfs and several filesystems:
btrfs fi show
Label: 'Daten' uuid: c217331c-cf0c-49ae-86c7-48a67d1c346b
Total devices 1 FS bytes used 54.69GiB
devid1 size 81.79GiB used 57.02GiB path /dev/sde2
The majority of reads receive a verity check after the bio is complete
as the page is marked uptodate. However, there is a class of reads which
are handled with btrfs logic in readpage, rather than by submitting a
bio. Specifically, these are inline extents, preallocated extents, and
holes. Tweak r
If we don't finish creating fsverity metadata for a file, or fail to
clean up already created metadata after a failure, we could leak the
verity items.
To address this issue, we use the orphan mechanism. When we start
enabling verity on a file, we also add an orphan item for that inode.
When we ar
Reading the contents with direct IO would circumvent verity checks, so
fallback to buffered reads. For what it's worth, this is how ext4
handles it as well.
Signed-off-by: Boris Burkov
---
fs/btrfs/file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
in
From: Chris Mason
Add support for fsverity in btrfs. To support the generic interface in
fs/verity, we add two new item types in the fs tree for inodes with
verity enabled. One stores the per-file verity descriptor and the other
stores the Merkle tree data itself.
Verity checking is done at the
The tree checker currently rejects unrecognized flags when it reads
btrfs_inode_item. Practically, this means that adding a new flag makes
the change backwards incompatible if the flag is ever set on a file.
Take up one of the 4 reserved u64 fields in the btrfs_inode_item as a
new "compat_flags".
This patchset provides support for fsverity in btrfs.
At a high level, we store the verity descriptor and Merkle tree data
in the file system btree with the file's inode as the objectid, and
direct reads/writes to those items to implement the generic fsverity
interface required by fs/verity/.
The
On Fri, 5 Mar 2021 at 05:38, Anand Jain wrote:
>
> On 05/03/2021 15:15, Alexandru Stan wrote:
> > Hello,
> >
> > My raid1 btrfs fs went read only recently. It was comprised of 2 drives:
> > /dev/sda ST4000VN008 (firmware SC60) - 6 month old drive
> > /dev/sdb ST4000VN000 (firmware SC44) - 5 year o
Hi,
Downstream user is running into this bug:
https://github.com/kdave/btrfs-progs/issues/349
But additionally the scrub of this converted file system, which still
has ext2_saved/image, produces this message:
[36365.549230] BTRFS error (device sda8): scrub: tree block
1777055424512 spanning stri
On Wed, Mar 03, 2021 at 09:18:44PM +0200, Dāvis Mosāns wrote:
> Currently only single checksum byte is outputted.
> This fixes it so that full checksum is outputted.
>
> Signed-off-by: Dāvis Mosāns
> ---
> kernel-shared/disk-io.c | 32 +++-
> 1 file changed, 27 insert
On Wed, Mar 03, 2021 at 09:39:09PM +0200, Dāvis Mosāns wrote:
> otrd., 2021. g. 2. marts, plkst. 16:18 — lietotājs David Sterba
> () rakstīja:
> > So the direction says if it's big endian or little endian, right, so for
> > xxhash it's bigendian but the crc32c above it's little.
>
> The problem is
From: David Sterba
Hi,
more regression fixes and stabilization. Please pull, thanks.
Regressions:
- zoned mode
- count zone sizes in wider int types
- fix space accounting for read-only block groups
- subpage: fix page tail zeroing
Fixes:
- fix spurious warning when remounting with free
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 Gompa wrote:
> >>> On Wed, Mar 3, 2021 at 1:42 PM Josef Bacik wrote:
>
> On 2/24/21 10:47 PM, Neal Gompa wr
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 Gompa wrote:
On Wed, Mar 3, 2021 at 1:42 PM Josef Bacik wrote:
On 2/24/21 10:47 PM, Neal Gompa wrote:
On Wed, Feb 24, 2021 at 10:44 AM Josef Bacik wrote:
On 2/24/21 9:23 AM, N
On Fri, Feb 26, 2021 at 08:39:47AM -0800, Eric Biggers wrote:
> On Fri, Feb 26, 2021 at 10:36:53AM +0100, David Sterba wrote:
> > On Thu, Feb 25, 2021 at 10:50:56AM -0800, Eric Biggers wrote:
> > > On Thu, Feb 25, 2021 at 02:26:47PM +0100, David Sterba wrote:
> Okay so you have 128K to compress, b
On 05/03/2021 15:15, Alexandru Stan wrote:
Hello,
My raid1 btrfs fs went read only recently. It was comprised of 2 drives:
/dev/sda ST4000VN008 (firmware SC60) - 6 month old drive
/dev/sdb ST4000VN000 (firmware SC44) - 5 year old drive (but it was
mostly idly spinning, very little accesses were
Hi,
btrfs-progs version 5.11 have been released.
Changelog:
* fix device path canonicalization for device mapper devices
* receive: remove workaround for setting capabilities, all stable kernels
have been patched
* receive: fix duplicate mount path detection
* rescue: new subcommand
On Fri, Mar 5, 2021 at 1:08 AM Zygo Blaxell
wrote:
>
> On Tue, Mar 02, 2021 at 04:24:19PM +, Filipe Manana wrote:
> > On Sat, Feb 27, 2021 at 3:53 PM Zygo Blaxell
> > wrote:
> > >
> > > Hit this twice so far, while running the usual
> > > balance/dedupe/rsync/snapshots/all at once on:
> > >
>
On Fri, Mar 5, 2021 at 9:46 AM Jia-Ju Bai wrote:
>
> When the list of reloc_roots is empty, no error return code of
> btrfs_recover_relocation() is assigned.
> To fix this bug, err is assigned with -ENOENT as error return code.
No, there isn't any such bug.
If there are no reloc roots, it means
When the list of reloc_roots is empty, no error return code of
btrfs_recover_relocation() is assigned.
To fix this bug, err is assigned with -ENOENT as error return code.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
fs/btrfs/relocation.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
27 matches
Mail list logo
