When I try to access a btrfs filesystem via nfs, I get the error:
root@tsmsrvi:~# mount tsmsrvj:/data/fex /nfs/tsmsrvj/fex
root@tsmsrvi:~# time find /nfs/tsmsrvj/fex | wc -l
find: File system loop detected; '/nfs/tsmsrvj/fex/spool' is part of the same
file system loop as '/nfs/tsmsrvj/fex'.
1
roo
On Tue, Mar 9, 2021 at 4:36 PM Heiko Becker wrote:
>
> Hard-coding the pkg-config executable might result in build errors
> on system and cross environments that have prefixed toolchains. The
> PKG_CONFIG variable already holds the proper one and is already used
> in a few other places.
>
> Signed
Hard-coding the pkg-config executable might result in build errors
on system and cross environments that have prefixed toolchains. The
PKG_CONFIG variable already holds the proper one and is already used
in a few other places.
Signed-off-by: Heiko Becker
---
configure.ac | 6 +++---
1 file chang
> hi,
>
> First thanks for your patchset.
> I'd like to know whether your patchset pass fstests? Thanks.
It has been tested by xfstests with quick and clone groups. I did not test it
with other groups yet.
--
Thanks,
Ruan Shiyang.
>
> Regards,
> Xiaoguang Wang
>
> > This patchset is attemp
>
> Hi Shiang,
>
> Thanks for picking up this work.
>
> On 8:20 26/02, Shiyang Ruan wrote:
> > This patchset is attempt to add CoW support for fsdax, and take XFS,
> > which has both reflink and fsdax feature, as an example.
>
> How does this work for read sequence for two different files
> map
Qu,
thanks, much appreciated. I'd missed that. Good, an easy fix.
>> Kernel 5.10.19
>> btrfs-progs 5.10.1
>
> It's a known regression in v5.10.1 btrfs-progs, which did wrong path
> normalization for device map.
>
> It's fixed in v5.11 btrfs-progs.
>
> Thanks,
> Qu
Hardware: nvme0
-> dm-crypt
--> lvm
--> nvme_vg-lxc-20200226 - existing btrfs
--> nvme_vg-lxc_db - xfs for mariadb data
--> nvme_vg_virt - for qemu images etc. (xfs I think)
--> nvme_vg-lxc-20210309 - new device to add to existing btrfs
This is
qemu images etc. (xfs I think)
--> nvme_vg-lxc-20210309 - new device to add to existing btrfs
This is opened (with small tweaks for privacy) with:
/usr/sbin/cryptsetup luksOpen UUID= nvme0
I have created a physical volume group on this device:
root@phoenix:/mnt# pvscan
PV /dev/mapper/nvme0 VG
On 2021/3/9 下午9:33, David Sterba wrote:
On Tue, Mar 09, 2021 at 03:39:09PM +0800, Qu Wenruo wrote:
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
On Tue, Mar 9, 2021 at 4:56 PM Josef Bacik wrote:
>
> On 3/9/21 4:06 PM, Neal Gompa wrote:
> > On Tue, Mar 9, 2021 at 2:04 PM Josef Bacik wrote:
> >>
> >> On 3/8/21 8:12 PM, Neal Gompa wrote:
> >>> On Mon, Mar 8, 2021 at 5:04 PM Josef Bacik wrote:
>
> On 3/8/21 3:01 PM, Neal Gompa wrot
On 3/9/21 4:06 PM, Neal Gompa wrote:
On Tue, Mar 9, 2021 at 2:04 PM Josef Bacik wrote:
On 3/8/21 8:12 PM, Neal Gompa wrote:
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 G
From: Ira Weiny
The memset() does not need to be performed atomically. Use
kmap_local_page() which will improved performance for this call.
Cc: Chaitanya Kulkarni
Cc: David Sterba
Signed-off-by: Ira Weiny
---
include/linux/highmem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Ira Weiny
Previously this was submitted to convert to zero_user()[1]. zero_user() is not
the same as memzero_user() and in fact some zero_user() calls may be better off
as memzero_user(). Regardless it was incorrect to convert btrfs to
zero_user().
This series corrects this by lifting me
From: Ira Weiny
There are many places where kmap/memset/kunmap patterns occur.
Use the newly lifted memzero_page() to eliminate direct uses of kmap and
leverage the new core functions use of kmap_local_page().
The development of this patch was aided by the following coccinelle
script:
//
// S
From: Ira Weiny
memzero_page() can replace the kmap/memset/kunmap pattern in other
places in the code. While zero_user() has the same interface it is not
the same call and its use should be limited and some of those calls may
be better converted from zero_user() to memzero_page().[1] But that i
On Tue, Mar 9, 2021 at 10:03 AM Sebastian Roller
wrote:
> I found 12 of these 'tree roots' on the volume. All the snapshots are
> under the same tree root. This seems to be the subvolume where I put
> the snapshots.
Snapshots are subvolumes. All of them will appear in the root tree,
even if they
On 3/8/21 8:12 PM, Neal Gompa wrote:
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 G
> > Would it make sense to just try restore -t on any root I got with
> > btrfs-find-root with all of the snapshots?
>
> Yes but I think you've tried this and you only got corrupt files or
> files with holes, so that suggests very recent roots are just bad due
> to the corruption, and older ones a
Hi Shiang,
Thanks for picking up this work.
On 8:20 26/02, Shiyang Ruan wrote:
> This patchset is attempt to add CoW support for fsdax, and take XFS,
> which has both reflink and fsdax feature, as an example.
How does this work for read sequence for two different files
mapped to the same extent
On Sat, Feb 20, 2021 at 12:41:17PM +, Sidong Yang wrote:
> This patch make output of filesystem-resize command more readable and
> give detail information for users. This patch provides more information
> about filesystem like below.
>
> Before:
> Resize '/mnt' of '1:-1G'
>
> After:
> Resize
On Sat, Feb 20, 2021 at 12:41:17PM +, Sidong Yang wrote:
> This patch make output of filesystem-resize command more readable and
> give detail information for users. This patch provides more information
> about filesystem like below.
>
> Before:
> Resize '/mnt' of '1:-1G'
>
> After:
> Resize
On Sat, Mar 06, 2021 at 08:40:19AM +0800, Qu Wenruo wrote:
> [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-
On Tue, Mar 09, 2021 at 03:39:09PM +0800, Qu Wenruo wrote:
> 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
Hi Yang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kdave/for-next]
[also build test ERROR on v5.12-rc2 next-20210309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
On Tue, Mar 09, 2021 at 05:32:54PM +0800, Yang Li wrote:
> This function always return '0' and no callers use the return value.
> So make it a void function.
>
> This eliminates the following coccicheck warning:
> ./fs/btrfs/disk-io.c:4522:5-8: Unneeded variable: "ret". Return "0" on
> line 4530
>
Hi Yang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kdave/for-next]
[also build test ERROR on v5.12-rc2 next-20210309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
On 9/3/21 5:32 pm, Yang Li wrote:
This function always return '0' and no callers use the return value.
So make it a void function.
This eliminates the following coccicheck warning:
./fs/btrfs/disk-io.c:4522:5-8: Unneeded variable: "ret". Return "0" on
line 4530
Reported-by: Abaci Robot
Signed-
This function always return '0' and no callers use the return value.
So make it a void function.
This eliminates the following coccicheck warning:
./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/disk-
On 9.03.21 г. 10:49 ч., kernel test robot wrote:
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 5297199a8bca12b8b96afcbf2341605efb6005de ("btrfs: remove inode number
> cache feature")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
29 matches
Mail list logo
