> On Fri, Feb 26, 2021 at 08:20:27AM +0800, Shiyang Ruan wrote:
> > Some operations, such as comparing a range of data in two files under
> > fsdax mode, requires nested iomap_open()/iomap_end() on two file. Thus,
> > we introduce iomap_apply2() to accept arguments from two files and
> > iomap_act
Some operations, such as comparing a range of data in two files under
fsdax mode, requires nested iomap_open()/iomap_end() on two file. Thus,
we introduce iomap_apply2() to accept arguments from two files and
iomap_actor2_t for actions on two files.
Signed-off-by: Shiyang Ruan
---
fs/iomap/appl
With dax we cannot deal with readpage() etc. So, we create a dax
comparison funciton which is similar with
vfs_dedupe_file_range_compare().
And introduce dax_remap_file_range_prep() for filesystem use.
Signed-off-by: Goldwyn Rodrigues
Signed-off-by: Shiyang Ruan
---
fs/dax.c | 56 ++
These are fixes for zoned btrfs.
Patch 01 moves the superblock location to address based. Patch 02 fixes
type conversion for zone size >= 4G. Patch 03 fixes zone_unusable acconting
when a block group is read-only.
Naohiro Aota (3):
btrfs: zoned: move superblock logging zone location
btrfs: z
We need to cast zone_sectors from u32 to u64 when setting the zone_size, or
it set the zone size = 0 when the size >= 4G.
Fixes: 5b316468983d ("btrfs: get zone information of zoned block devices")
Signed-off-by: Naohiro Aota
---
fs/btrfs/zoned.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
We migrate zone unusable bytes to read-only bytes when a block group is set
to read-only, and account all the free region as bytes_readonly. Thus, we
should not increase block_group->zone_unusable when the block group is
read-only.
Fixes: 169e0da91a21 ("btrfs: zoned: track unusable bytes for zones
This commit moves the location of superblock logging zones basing on the
static address instead of the static zone number.
The following zones are reserved as the circular buffer on zoned btrfs.
- The primary superblock: zone at LBA 0 and the next zone
- The first copy: zone at LBA 16G and the
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:
> >
> > LZ4 support has been asked for so many times that it has it's own FAQ
> > entry:
> > https://btrfs.wiki.kernel.org/index.php/FAQ#Will_btrfs_support_LZ4.3F
> >
> >
Hi, guys
Beside this patchset, I'd like to confirm something about the "EXPERIMENTAL"
tag for dax in XFS.
In XFS, the "EXPERIMENTAL" tag, which is reported in waring message when we
mount a pmem device with dax option, has been existed for a while. It's a bit
annoying when using fsdax feature
On 25/02/2021 13:57, Qu Wenruo wrote:
There are some btrfs test cases utilizing
_btrfs_forget_or_module_reload() to unregister all btrfs devices.
However _btrfs_forget_or_module_reload() will unregister all devices,
meaning if TEST_DEV is part of a multi-device btrfs, after those test
cases TEST
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:
> > >
> > > LZ4 support has been asked for so many times that it has it's own FAQ
> > > entry:
> > > https
On Fri, Feb 26, 2021 at 07:28:54PM +0800, Gao Xiang 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:
> > > >
> > > > LZ4 support has been aske
On Fri, Feb 26, 2021 at 07:28:54PM +0800, Gao Xiang 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:
> >
> > ZLIB and ZSTD can have a separate dictionary and don't need the input
> > chunks to be contiguous. Th
Hi David,
On Fri, Feb 26, 2021 at 03:12:03PM +0100, David Sterba wrote:
> On Fri, Feb 26, 2021 at 07:28:54PM +0800, Gao Xiang 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:
> > >
> > > ZLIB and ZSTD can
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.b
From: Filipe Manana
When doing a full send we know that we are going to be reading every node
and leaf of the send root, so we benefit from enabling read ahead for the
btree.
This change enables read ahead for full send operations only, incremental
sends will have read ahead enabled in a differe
From: Filipe Manana
This patchset adds btree read ahead for full and incremental send operations,
which results in some nice speedups. Test and results are mentioned in the
change log of each patch.
Filipe Manana (2):
btrfs: add btree read ahead for full send operations
btrfs: add btree read
From: Filipe Manana
Currently we do not do btree read ahead when doing an incremental send,
however we know that we will read and process any node or leaf in the
send root that has a generation greater than the generation of the parent
root. So triggering read ahead for such nodes and leafs is be
On Fri, Feb 26, 2021 at 07:43:36AM +0800, Qu Wenruo wrote:
> On 2021/2/25 下午11:34, David Sterba wrote:
> > On Thu, Feb 25, 2021 at 07:44:19AM +0800, Qu Wenruo wrote:
> >>
> >>
> >> On 2021/2/25 上午3:18, David Sterba wrote:
> >>> On Sat, Feb 20, 2021 at 10:06:33AM +0800, Qu Wenruo wrote:
> Due t
> > I think you best chance is to start out trying to restore from a
> > recent snapshot. As long as the failed controller wasn't writing
> > totally spurious data in random locations, that snapshot should be
> > intact.
>
> i.e. the strategy for this is btrfs restore -r option
>
> That only takes
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:
> > >
> > > LZ4 support has been asked for so many times that it has it's own FAQ
> > > entry:
> > > https
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_buffer_pages+0x97/0x110
> [<0>] read_tree_block+0x
On Thu, Feb 25, 2021 at 02:58:22PM -0600, Goldwyn Rodrigues wrote:
> force_nocow can be calculated by btrfs_inode and does not need to be
> passed as an argument.
>
> This simplifies run_delalloc_nocow() call from btrfs_run_delalloc_range()
> since the decision whether the extent is cow'd or not c
Hello my friend
I have sent several emails, have you received my previous complaints?
Willson J. Mutanda
Email: willsonmutand...@gmail.com
From: Filipe Manana
When we have smack enabled, during the creation of a directory smack may
attempt to add a "smack transmute" xattr on the inode, which results in
the following warning and trace:
[ 220.732359] [ cut here ]
[ 220.732398] WARNING: CPU: 3 PID: 2548 at fs
On Wed, Dec 16, 2020 at 11:26:19AM -0500, Josef Bacik wrote:
> Currently select_reloc_root() doesn't return an error, but followup
> patches will make it possible for it to return an error. We do have
> proper error recovery in do_relocation however, so handle the
> possibility of select_reloc_roo
On 18:14 26/02, David Sterba wrote:
> On Thu, Feb 25, 2021 at 02:58:22PM -0600, Goldwyn Rodrigues wrote:
> > force_nocow can be calculated by btrfs_inode and does not need to be
> > passed as an argument.
> >
> > This simplifies run_delalloc_nocow() call from btrfs_run_delalloc_range()
> > since t
On Wed, Dec 16, 2020 at 11:26:18AM -0500, Josef Bacik wrote:
> We can create a reloc root when we record the root in the trans, which
> can fail for all sorts of different reasons. Propagate this error up
> the chain of callers. Future patches will fix the callers of
> btrfs_record_root_in_trans(
On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> Hi, guys
>
> Beside this patchset, I'd like to confirm something about the
> "EXPERIMENTAL" tag for dax in XFS.
>
> In XFS, the "EXPERIMENTAL" tag, which is reported in waring message
> when we mount a pmem device with dax
On Fri, Feb 26, 2021 at 06:34:36PM +0900, Naohiro Aota wrote:
> This commit moves the location of superblock logging zones basing on the
> static address instead of the static zone number.
>
> The following zones are reserved as the circular buffer on zoned btrfs.
> - The primary superblock: zon
On Fri, Feb 26, 2021 at 06:34:37PM +0900, Naohiro Aota wrote:
> We need to cast zone_sectors from u32 to u64 when setting the zone_size, or
> it set the zone size = 0 when the size >= 4G.
>
> Fixes: 5b316468983d ("btrfs: get zone information of zoned block devices")
> Signed-off-by: Naohiro Aota
On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
>
> On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > Hi, guys
> >
> > Beside this patchset, I'd like to confirm something about the
> > "EXPERIMENTAL" tag for dax in XFS.
> >
> > In XFS, the "EXPERIMENTAL" tag, whi
On 2/26/2021 9:51 AM, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we have smack enabled, during the creation of a directory smack may
> attempt to add a "smack transmute" xattr on the inode, which results in
> the following warning and trace:
>
> [ 220.732359] [ cut here
On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> >
> > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > > Hi, guys
> > >
> > > Beside this patchset, I'd like to confirm something about the
> > > "E
On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> > >
> > > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > > > Hi, guys
> > > >
> > > >
On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> >
> > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong
> > > wrote:
> > > >
> > > > On Fri, Feb 26, 2021 at 0
On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> > >
> > > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > > > On Fri, Feb 26, 2021 at 11:05 AM Darrick
On 2021/2/27 上午1:51, fdman...@kernel.org wrote:
From: Filipe Manana
When we have smack enabled, during the creation of a directory smack may
attempt to add a "smack transmute" xattr on the inode, which results in
the following warning and trace:
[ 220.732359] [ cut here ]--
On Fri, Feb 26, 2021 at 9:01 AM Sebastian Roller
wrote:
>
> > > I think you best chance is to start out trying to restore from a
> > > recent snapshot. As long as the failed controller wasn't writing
> > > totally spurious data in random locations, that snapshot should be
> > > intact.
> >
> > i.e
On Wed, Feb 24, 2021 at 9:40 PM 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 -f $dev1
>
> btrfstune -S 1 $dev1
No mount or copying data to the file s
On 2021/2/27 上午9:01, Qu Wenruo wrote:
On 2021/2/27 上午1:51, fdman...@kernel.org wrote:
From: Filipe Manana
When we have smack enabled, during the creation of a directory smack may
attempt to add a "smack transmute" xattr on the inode, which results in
the following warning and trace:
[ 2
> On Feb 27, 2021, at 09:12, Chris Murphy wrote:
>
> On Wed, Feb 24, 2021 at 9:40 PM 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.bt
42 matches
Mail list logo
