On Tue, Mar 23, 2021 at 12:50 AM Dave T wrote:
>
> > d. Just skip the testing and try usebackuproot with a read-write
> > mount. It might make things worse, but at least it's fast to test. If
> > it messes things up, you'll have to recreate this backup from scratch.
>
> I took this approach. My co
From: Filipe Manana
If we reflink to or from a file opened with O_SYNC/O_DSYNC or to/from a
file that has the S_SYNC attribute set, we totally ignore that and do not
durably persist the reflink changes. Since a reflink can change the data
readable from a file (and mtime/ctime, or a file size), it
On Sat, Mar 20, 2021 at 10:27:27AM +0100, pierre.labas...@neuf.fr wrote:
> Note that I doubt this check is needed in configure:
> HAVE_OWN_FIEMAP_EXTENT_DEFINE is used only once in cmds/filesystem-du.c
> in:
> #if !defined(FIEMAP_EXTENT_SHARED) && (HAVE_OWN_FIEMAP_EXTENT_SHARED_DEFINE
> == 1)
> bu
On 3/19/21 7:22 AM, Shiyang Ruan wrote:
In the case where the iomap is a write operation and iomap is not equal
to srcmap after iomap_begin, we consider it is a CoW operation.
The destance extent which iomap indicated is new allocated extent.
So, it is needed to copy the data from srcmap to n
This comment was written in fb124ee4. In this version, parse_group_id()
didn't support to parse path. but this function already can parse path.
So, this comment is outdated and it makes confusing now.
Signed-off-by: Sidong Yang
Reviewed-by: Qu Wenruo
---
v2:
Add detailed changelog
---
cmds/q
On Sat, Mar 20, 2021 at 10:27:28AM +0100, pierre.labas...@neuf.fr wrote:
> From: Pierre Labastie
>
> Autoheader uses the AC_DEFINE macros (and a few others) to populate
> the config.h.in file. The autotools documentation does not tell
> what happens if AC_DEFINE is used twice for the same identif
On 3/19/21 7:22 AM, Shiyang Ruan wrote:
The core logic in the two dax page fault functions is similar. So, move
the logic into a common helper function. Also, to facilitate the
addition of new features, such as CoW, switch-case is no longer used to
handle different iomap types.
Signed-off-by:
On 3/19/21 7:22 AM, Shiyang Ruan wrote:
Add address output in dax_iomap_pfn() in order to perform a memcpy() in
CoW case. Since this function both output address and pfn, rename it to
dax_iomap_direct_access().
Signed-off-by: Shiyang Ruan
Reviewed-by: Christoph Hellwig
---
fs/dax.c | 16
On Wed, Mar 17, 2021 at 04:01:43PM -0400, Neal Gompa wrote:
> This is a patch requesting all substantial copyright owners to sign off
> on changing the license of the libbtrfsutil code to LGPLv2.1+ in order
> to resolve various concerns around the mixture of code in btrfs-progs
> with libbtrfsutil.
On Tue, Mar 23, 2021 at 03:48:16PM +0100, David Sterba wrote:
> On Mon, Mar 22, 2021 at 02:03:16PM +, Sidong Yang wrote:
> > This comment is outdated and this patch remove
> > it to avoid confusion.
>
> Even if it's just a comment removal, changelog should say why it's
> outated, I have no ide
On 3/19/21 7:22 AM, Shiyang Ruan wrote:
The dax page fault code is too long and a bit difficult to read. And it
is hard to understand when we trying to add new features. Some of the
PTE/PMD codes have similar logic. So, factor them as helper functions to
simplify the code.
Signed-off-by: Shiy
On 3/19/21 7:22 AM, Shiyang Ruan wrote:
From: Shiyang Ruan
This patchset is attempt to add CoW support for fsdax, and take XFS,
which has both reflink and fsdax feature, as an example.
Thanks for the patchset. I have tried reviewing the series from logical
correctness and to some extent f
On Mon, Mar 22, 2021 at 02:03:16PM +, Sidong Yang wrote:
> This comment is outdated and this patch remove
> it to avoid confusion.
Even if it's just a comment removal, changelog should say why it's
outated, I have no idea and would have to do the research myself.
From: Arnd Bergmann
gcc complains that the ctl->max_chunk_size member might be used
uninitialized when none of the three conditions for initializing it in
init_alloc_chunk_ctl_policy_zoned() are true:
In function ‘init_alloc_chunk_ctl_policy_zoned’,
inlined from ‘init_alloc_chunk_ctl’ at fs/
On Tue, Mar 23, 2021 at 01:46:19PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The ctl->max_chunk_size member might be used uninitialized
> when none of the three conditions for initializing it in
> init_alloc_chunk_ctl_policy_zoned() are true:
>
> In function ‘init_alloc_chunk_ctl_pol
From: Arnd Bergmann
The ctl->max_chunk_size member might be used uninitialized
when none of the three conditions for initializing it in
init_alloc_chunk_ctl_policy_zoned() are true:
In function ‘init_alloc_chunk_ctl_policy_zoned’,
inlined from ‘init_alloc_chunk_ctl’ at fs/btrfs/volumes.c:502
On 23/03/2021 10:57, Filipe Manana wrote:
> On Fri, Mar 19, 2021 at 10:52 AM Johannes Thumshirn
> wrote:
>>
>> When a file gets deleted on a zoned file system, the space freed is not
>> returned back into the block group's free space, but is migrated to
>> zone_unusable.
>>
>> As this zone_unusabl
On Fri, Mar 19, 2021 at 10:52 AM Johannes Thumshirn
wrote:
>
> When a file gets deleted on a zoned file system, the space freed is not
> returned back into the block group's free space, but is migrated to
> zone_unusable.
>
> As this zone_unusable space is behind the current write pointer it is no
On Fri, Mar 19, 2021 at 01:59:02PM -0400, Josef Bacik wrote:
> On 3/19/21 6:48 AM, Johannes Thumshirn wrote:
> > When a file gets deleted on a zoned file system, the space freed is not
> > returned back into the block group's free space, but is migrated to
> > zone_unusable.
> >
> > As this zone_u
19 matches
Mail list logo
