On 2021/3/2 上午12:30, David Sterba wrote:
On Mon, Feb 22, 2021 at 02:33:45PM +0800, Qu Wenruo wrote:
This patchset can be fetched from the following github repo, along with
the full subpage RW support:
https://github.com/adam900710/linux/tree/subpage
This patchset is for metadata read write s
On Mon, Mar 1, 2021 at 2:47 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinn
On 2021/3/2 上午1:24, Christian Völker wrote:
Hi,
just a little update on the issue.
As soon as I omit the encryption part I can easily add the device to the
btrfs filesystem. It does not matter if the crypted device is on top of
DRBD or directly on the /dev/sdc. In both cases btrs refuses to
On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
[..]
> We do not need a DAX specific mechanism to tell us "DAX device
> gone", we need a generic block device interface that tells us "range
> of block device is gone".
This is the crux of the disagreement. The block_device is going away
*and* th
On Mon, Mar 01, 2021 at 04:32:36PM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 2:47 PM Dave Chinner wrote:
> > Now we have the filesytem people providing a mechanism for the pmem
> > devices to tell the filesystems about physical device failures so
> > they can handle such failures correct
On Tue, Feb 09, 2021 at 06:33:37PM +0100, Marek Behún wrote:
> When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
> location key offset other than -1, it currently fails via BUG_ON.
>
> The offset can have other value than -1, though. This can happen for
> example if a subvolume
On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> >
> > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan
On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> [..]
> > We do not need a DAX specific mechanism to tell us "DAX device
> > gone", we need a generic block device interface that tells us "range
> > of block device is gone".
>
> T
On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > > On Sat, Feb 27, 2021 at 2:36 PM Dave Ch
On Mon, Mar 1, 2021 at 9:38 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> > [..]
> > > We do not need a DAX specific mechanism to tell us "DAX device
> > > gone", we need a generic block device int
On 26/02/2021 23:10, David Sterba wrote:
On Fri, Feb 26, 2021 at 01:01:02PM +0800, Anand Jain wrote:
On 25/02/2021 12:39, Su Yue wrote:
While playing with seed device(misc/next and v5.11), lockdep complains
the following:
To reproduce:
dev1=/dev/sdb1
dev2=/dev/sdb2
umount /mnt
mkfs.btrfs -
Hi Qu Wenro,
thanks for debugging this. What I am wondering- why did it work when
creating the initial device?
For Debian it looks like there is no other version of btrfs-progs
available, so I used this version (5.10.1-1) to create the btrfs device.
And may I workaround this issue by manually
Ok,
tried to do with a symlink. No working, getting segfault:
>root@backuppc41:/dev# ln -s mapper/crypt_test crypt_temp
>root@backuppc41:/dev# btrfs de ad /dev/crypt_temp /var/lib/backuppc/
>Speicherzugriffsfehler
Greetings
/KNEBB
Am 02.03.2021 um 02:18 schrieb Qu Wenruo:
On 2021/3/2 上午
On 2021/3/2 下午3:09, Christian Völker wrote:
Hi Qu Wenro,
thanks for debugging this. What I am wondering- why did it work when
creating the initial device?
Fs creation (mkfs) doesn't canonicalize the path, and it all happens in
user space, so no problem.
Only device add is affected, and if
On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > I really don't see you seem to be telling us that invalidation is an
> > > > either/or choice. There's more ways to convert physical block
> > > > address -> inode file off
Hi, Qu Wenruo
This warning message happen even in new created filesystem on amd64
system.
Should we slicent it before mkfs.btrfs is ready for 64K page system?
The paration is aligned in 1GiB
btrfs-progs: v5.10.x branch
# mkfs.btrfs /dev/sdb1 -f
# btrfs check /dev/sdb1
Opening filesystem to c
fstests btrfs/028 failed once, but there is no clear error message in
the output of 'btrfs check' [*1].
There is some places in 'btrfs check' where 'err' is set, but no error("")
message is outputed, so we add them.
[*1]
# cat /ssd/git/os/xfstests/results//btrfs/028.full
# /usr/sbin/btrfs quota
As btrfs zoned device support was merged with 5.12 here are the 1st two
preparational patches for zoned device support in fstests.
The 1st patch adds missing checks for fallocate support to tests that are
lacking it and the second patch checks for discard support availability.
Johannes Thumshirn
These functions always return '0' and no callers use the return
value. So make it a void function.
It fixes the following warning detected by coccinelle:
./fs/btrfs/disk-io.c:4522:5-8: Unneeded variable: "ret". Return "0" on
line 4530
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
fs/btrfs
Hallöchen!
Alexander Wetzel writes:
> I have a strange problem with btrfs send/receive. While I can
> create incremental snaphosts but when I try to restore them I
> reproducible get:
>
>> At snapshot 2021-02-20-TEMP
>> ERROR: clone: did not find source subvol
I observe the same thing regularly
Some test cases for btrfs require the scratch device to support discard.
Check if the scratch device does support discard before trying to execute
the test.
Signed-off-by: Johannes Thumshirn
---
common/rc | 8
tests/btrfs/116 | 1 +
tests/btrfs/156 | 1 +
3 files changed, 10 inser
From: Naohiro Aota
Many test cases use xfs_io -c 'falloc' but forgot to add
_require_xfs_io_command "falloc". This will fail the test case if we run
the test case on a file system without fallcoate support e.g. F2FS ZZ
While we believe that normal fallocate(mode = 0) is always supported on
Linux
On 2021/3/2 下午4:48, Wang Yugui wrote:
Hi, Qu Wenruo
This warning message happen even in new created filesystem on amd64
system.
Should we slicent it before mkfs.btrfs is ready for 64K page system?
Nope.
If your fs reports such problem, it means your metadata chunk is not
properly aligne
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 you want
to force metadata duplication.
Lab
The major complexity when it comes to error handling in btrfs_zero_range
stems from the code executed under the 'reserve_space' label. Rather
than it having an effect on the whole of btrfs_zero_range refactor it
so that error handling specific to the functions called in this branch
is contained onl
Signed-off-by: Nikolay Borisov
---
fs/btrfs/qgroup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 4ee51a082af6..1b7d3cadc39e 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -3617,8 +3617,7 @@ static int qgroup_reserve_
I've just tripped over this lockdep splat on v5.12-rc1 (Linus' tree not
misc-next),
while investigating a different bug report.
[ 1250.721882] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
[ 1250.722641] turning off the locking correctness validator.
[ 1250.723486] CPU: 0 PID: 468 Comm: fsstress Not ta
On Tue, Mar 02, 2021 at 01:04:19PM +0800, Anand Jain wrote:
> On 26/02/2021 23:10, David Sterba wrote:
> > On Fri, Feb 26, 2021 at 01:01:02PM +0800, Anand Jain wrote:
> >> On 25/02/2021 12:39, Su Yue wrote:
> >>>
> >>> While playing with seed device(misc/next and v5.11), lockdep complains
> >>> the
On Tue, Mar 02, 2021 at 04:57:56PM +0800, Yang Li wrote:
> These functions always return '0' and no callers use the return
> value. So make it a void function.
The reasoning needs to go the other way around: you can make a function
return void iff all callees also return void and don't do BUG_ON i
On Sat, Feb 27, 2021 at 10:07:02PM +0200, Dāvis Mosāns wrote:
> Currently only single checksum byte is outputted.
> This fixes it so that full checksum is outputted.
Thanks, that really needs fixing.
> Signed-off-by: Dāvis Mosāns
> ---
> kernel-shared/disk-io.c | 47
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:
>
> a646ddc2bba2 (kdave-gitlab/misc-next) btrfs: unlock extents in
> btrfs_zero_range in case of quota reservation errors
>
> Looks like
On Fri, Feb 19, 2021 at 02:18:58PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./fs/btrfs/disk-io.c:4403:5-8: Unneeded variable: "ret". Return "0" on
> line 4411.
That maybe stops the check to report the warning but it's not the right
way to fix the code. The callees
On Mon, Mar 1, 2021 at 11:57 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > > I really don't see you seem to be telling us that invalidation is an
> > > > > either/or choice. There's more w
On 3/2/21 4:13 AM, Johannes Thumshirn wrote:
From: Naohiro Aota
Many test cases use xfs_io -c 'falloc' but forgot to add
_require_xfs_io_command "falloc". This will fail the test case if we run
the test case on a file system without fallcoate support e.g. F2FS ZZ
While we believe that normal f
On 3/2/21 4:13 AM, Johannes Thumshirn wrote:
Some test cases for btrfs require the scratch device to support discard.
Check if the scratch device does support discard before trying to execute
the test.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Josef Bacik
Thanks,
Josef
Hi,
thanks to Qu Wenruo it worked for me as he suggested.
So I created my additional drbd device and put the encryption on top of
it. To workaround the issue with adding a device with /dev/mapper/ as
prefix I created in my /root a node with the same major and minor
numbers as the dm-* device.
Hi all,
might be a simple question but I did not find a trustable source for this.
BTRFS uses COW which might lead to fragmentation.
So using "btrfs fi defrag -r /mnt" will bring most file extend in a row
and copy previously deduplicated extends.
Obviously this uses more disk space. This is not
37 matches
Mail list logo
