Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 65536
But since btrfs subpage support for 64K page size is comming, this
output is populating the golden outpu
Resize to nums without sign prefix makes false output:
btrfs fi resize 1:150g /srv/extra
Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
The resize operation would take effect though.
check_resize_args() does not handle the mod 0 case and new_size is 0.
Simply assigning @diff to @new_size
On Tue 20 Apr 2021 at 01:08, Boris Burkov wrote:
On Mon, Apr 19, 2021 at 09:05:49PM +0800, Su Yue wrote:
Resize to nums without sign prefix makes false output:
btrfs fi resize 1:150g /srv/extra
Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
The resize operation would take effect th
On 2021/4/20 上午12:31, Boris Burkov wrote:
On Mon, Apr 19, 2021 at 02:45:12PM +0800, Qu Wenruo wrote:
Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 655
On Mon, Apr 19, 2021 at 10:08:50AM -0700, Boris Burkov wrote:
> On Mon, Apr 19, 2021 at 09:05:49PM +0800, Su Yue wrote:
> > @@ -1158,6 +1158,16 @@ static int check_resize_args(const char *amount,
> > const char *path) {
> > }
> > old_size = di_args[dev_idx].total_bytes;
> >
On Mon, Apr 19, 2021 at 09:05:49PM +0800, Su Yue wrote:
> Resize to nums without sign prefix makes false output:
> btrfs fi resize 1:150g /srv/extra
> Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
>
> The resize operation would take effect though.
>
> Fix it by handling the case if mod
On Mon, Apr 19, 2021 at 09:05:49PM +0800, Su Yue wrote:
> Resize to nums without sign prefix makes false output:
> btrfs fi resize 1:150g /srv/extra
> Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
>
> The resize operation would take effect though.
>
> Fix it by handling the case if mod
On Mon, Apr 19, 2021 at 02:45:12PM +0800, Qu Wenruo wrote:
> Currently mkfs.btrfs will output a warning message if the sectorsize is
> not the same as page size:
> WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
> page size 65536
>
> But since btrfs subpage support f
Resize to nums without sign prefix makes false output:
btrfs fi resize 1:150g /srv/extra
Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
The resize operation would take effect though.
Fix it by handling the case if mod is 0 in check_resize_args().
Issue: #307
Reported-by: Chris Murphy
S
On Mon 19 Apr 2021 at 20:45, Su Yue wrote:
Resize to nums without sign prefix makes false output:
Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
The resize operation would take effect though.
Fix it by handling the case if mod is 0 in check_resize_args().
Issue: #307
Reported-by: C
Resize to nums without sign prefix makes false output:
Resize device id 1 (/dev/sdb1) from 298.09GiB to 0.00B
The resize operation would take effect though.
Fix it by handling the case if mod is 0 in check_resize_args().
Issue: #307
Reported-by: Chris Murphy
Signed-off-by: Su Yue
---
cmds/fil
Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 65536
But since btrfs subpage support for 64K page size is comming, this
output is populating the golden outpu
Fail is the correct result for now. It should pass with patch "btrfs-
progs: Correct check_running_fs_exclop() return value"
https://patchwork.kernel.org/project/linux-btrfs/patch/20210409155644.qkk6puelfjvtjwqs@fiona/
Thanks,
An Long
On Fri, 2021-04-16 at 10:38 -0700, Boris Burkov w
On 2021/4/17 上午2:14, Boris Burkov wrote:
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 6553
On 2021/4/17 上午1:46, David Sterba wrote:
On Fri, Mar 26, 2021 at 08:50:47PM +0800, Qu Wenruo wrote:
This new test case is to make sure the restored image file has been
properly enlarged so that newer kernel won't complain.
Signed-off-by: Qu Wenruo
---
.../047-image-restore-mount/test.sh
On 2021/4/17 上午1:40, David Sterba wrote:
On Fri, Mar 26, 2021 at 08:50:46PM +0800, Qu Wenruo wrote:
[BUG]
If restoring dumpped image into a new file, under most cases kernel will
reject it:
# mkfs.btrfs -f /dev/test/test
# btrfs-image /dev/test/test /tmp/dump
# btrfs-image -r /tmp/dump
On Fri, Apr 16, 2021 at 10:07:09PM +0200, David Sterba wrote:
> On Fri, Apr 16, 2021 at 11:14:08AM -0700, Boris Burkov wrote:
> > On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> > > +/*
> > > + * The buffer size if strlen("4096 8192 16384 32768 65536"),
> > > + * which is 28, then roun
On Fri, Apr 16, 2021 at 11:14:08AM -0700, Boris Burkov wrote:
> On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> > +/*
> > + * The buffer size if strlen("4096 8192 16384 32768 65536"),
> > + * which is 28, then round up to 32.
>
> I think there is a typo in this comment, because it doe
t; 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.
> > >
> > > Each significant (i.e. non-trivial) commit author has been CC'd to
On Tue, Apr 06, 2021 at 04:55:03PM +0300, Nikolay Borisov wrote:
> In case the right buffer is emptied it's first set to null and
> subsequently it's dereferenced to get its size to pass to root_sub_used.
> This naturally leads to a null pointer dereference. The correct thing
> to do is to pass the
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> Currently mkfs.btrfs will output a warning message if the sectorsize is
> not the same as page size:
> WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
> page size 65536
>
> But since btrfs subpage support f
On Thu, Apr 15, 2021 at 01:30:11PM +0800, Qu Wenruo wrote:
> Currently mkfs.btrfs will output a warning message if the sectorsize is
> not the same as page size:
> WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
> page size 65536
>
> But since btrfs subpage support f
On Fri, Mar 26, 2021 at 08:50:47PM +0800, Qu Wenruo wrote:
> This new test case is to make sure the restored image file has been
> properly enlarged so that newer kernel won't complain.
>
> Signed-off-by: Qu Wenruo
> ---
> .../047-image-restore-mount/test.sh | 19 +++
>
On Fri, Mar 26, 2021 at 08:50:46PM +0800, Qu Wenruo wrote:
> [BUG]
> If restoring dumpped image into a new file, under most cases kernel will
> reject it:
>
> # mkfs.btrfs -f /dev/test/test
> # btrfs-image /dev/test/test /tmp/dump
> # btrfs-image -r /tmp/dump ~/test.img
> # mount ~/test.img /m
$(seq 1 5); do
> +run_check $SUDO_HELPER fallocate -l 200M "$TEST_MNT/file$i"
> +done
> +
> +# Do btrfs balance in background, then try commands with enqueue parameter
> +run_check $SUDO_HELPER "$TOP/btrfs" balance start --full-balance "$TEST_MNT"
On Thu, Apr 01, 2021 at 05:41:00PM +0900, Naohiro Aota wrote:
> Marking BUG() unreachable helps us silence unnecessary warnings e.g.
> "warning: control reaches end of non-void function [-Wreturn-type]" like
> the code below.
>
>int foo()
>{
>...
> if (XXX)
> return
On Fri, Apr 9, 2021 at 12:32 PM Wang Yugui wrote:
>
> Hi,
>
> > btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do
> > the real probe. After calling blkid_new_probe() &
> > blkid_probe_set_device() to setup blkid_probe context, it directly
> > calls blkid_probe_lookup_value(). This
Currently mkfs.btrfs will output a warning message if the sectorsize is
not the same as page size:
WARNING: the filesystem may not be mountable, sectorsize 4096 doesn't match
page size 65536
But since btrfs subpage support for 64K page size is comming, this
output is populating the golden outpu
te it some time ago.
That opened up an Alice-in-Wonderland rabbit hole... the documentation
for the common command options in btrfs-progs is not just awful, I ended
up very confused about what I was seeing...
There are several issues:
1) The man pages do not describe the top-level btrfs command op
The exclusive ops will not start if there's one already running. The
enqueue parameter allows operations to be queued.
Signed-off-by: An Long
---
.../misc-tests/048-enqueue-parameter/test.sh | 52 +++
1 file changed, 52 insertions(+)
create mode 100755 tests/misc-tests/048-enqu
On 6:50 10/04, Anand Jain wrote:
> On 09/04/2021 23:56, Goldwyn Rodrigues wrote:
> > check_running_fs_exclop() can return 1 when exclop is changed to "none"
> > The ret is set by the return value of the select() operation. Checking
> > the exclusive op changes just the exclop variable while ret is
On 09/04/2021 23:56, Goldwyn Rodrigues wrote:
check_running_fs_exclop() can return 1 when exclop is changed to "none"
The ret is set by the return value of the select() operation. Checking
the exclusive op changes just the exclop variable while ret is still
set to 1.
Set ret exclusively if exclo
check_running_fs_exclop() can return 1 when exclop is changed to "none"
The ret is set by the return value of the select() operation. Checking
the exclusive op changes just the exclop variable while ret is still
set to 1.
Set ret exclusively if exclop is set to BTRFS_EXCL_NONE.
---
common/utils.c
Hi,
> btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do
> the real probe. After calling blkid_new_probe() &
> blkid_probe_set_device() to setup blkid_probe context, it directly
> calls blkid_probe_lookup_value(). This results in
> blkid_probe_lookup_value returning -1, because pr-
On 4/6/21 9:55 AM, Nikolay Borisov wrote:
In case the right buffer is emptied it's first set to null and
subsequently it's dereferenced to get its size to pass to root_sub_used.
This naturally leads to a null pointer dereference. The correct thing
to do is to pass the stashed right->len in "block
ch is merged, the warnings will disappear.
I see. Thanks.
--
Su
https://lore.kernel.org/linux-btrfs/5c7b703beca572514a28677df0caaafab28bfff8.1617265419.git.naohiro.a...@wdc.com/T/#u
--
Su
> Naohiro Aota (12):
> btrfs-progs: introduce chunk allocation policy
> btrfs-progs: refac
In case the right buffer is emptied it's first set to null and
subsequently it's dereferenced to get its size to pass to root_sub_used.
This naturally leads to a null pointer dereference. The correct thing
to do is to pass the stashed right->len in "blocksize".
Fixes #296
Signed-off-by: Nikolay B
bort the program.
The warnings are showing up because the BUG() macro is not marked as
unreachable. This is addressed in the following patch. So, once the
following patch is merged, the warnings will disappear.
https://lore.kernel.org/linux-btrfs/5c7b703beca572514a28677df0caaafab28bfff8.1617265419.gi
/volumes.c:465:1: warning: control reaches end of
non-void function [-Wreturn-type]
465 | }
| ^
Looked at locations just two nits about 'switch'. Care to fix?
--
Su
Naohiro Aota (12):
btrfs-progs: introduce chunk allocation policy
btrfs-progs: refactor find_free_dev_extent_start
On 06/04/2021 10:07, Naohiro Aota wrote:
> This is the userland counterpart of the following series.
>
> https://lore.kernel.org/linux-btrfs/20200225035626.1049501-1-naohiro.a...@wdc.com/
>
> This series refactors chunk allocation and device_extent allocation
> functions and make them generalized
alloc_chunk_ctl::calc_size is actually the stripe_size in the kernel side
code. Let's rename it to clarify what the "calc" is.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 56 -
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/
Chunk_bytes_by_type() takes type, calc_size, and ctl as arguments. But the
first two can be obtained from the ctl. Let's drop these arguments for
simplicity.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/k
Since commit b9444efb6658 ("btrfs-progs: don't pretend RAID56 has a
different stripe length"), alloc_chunk_ctl::stripe_len is always fixed to
BTRFS_STRIPE_LEN. Let's replace alloc_chunk_ctl::stripe_len with
BTRFS_STRIPE_LEN, like in the kernel code.
Signed-off-by: Naohiro Aota
Several calculations in the chunk allocation process use this pattern.
x /= y;
x *= y;
Replace this pattern with round_down().
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel-shared/volumes.
In the DUP profile, we can use only half of the space available in a device
extent. Fix the calculation of calc_size for it.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel-shared/volumes.c b/kernel-shared/vol
Factor out create_chunk() from btrfs_alloc_chunk(). This new function
creates a chunk.
There is no functional changes.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 217 ++--
1 file changed, 120 insertions(+), 97 deletions(-)
diff --git a/kernel-
btrfs_alloc_data_chunk() and create_chunk() have the most part in common.
Let's rewrite btrfs_alloc_data_chunk() using create_chunk().
There are two differences between btrfs_alloc_data_chunk() and
create_chunk(). create_chunk() uses find_next_chunk() to decide the logical
address of the chunk, an
Factor out decide_stripe_size() from btrfs_alloc_chunk(). This new function
calculates the actual stripe size to allocate and decides the size of a
stripe (ctl->calc_size).
This commit has no functional changes.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 44 ++
Convert alloc_chunk_ctl::type to take the original type in
btrfs_alloc_chunk(). This will help refactoring in the following commits.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel-shared/volumes.c b/kernel-
Move parameter initialization code for regular allocator to
init_alloc_chunk_ctl_policy_regular(). This will help adding another
allocator in the future.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 112 +++-
1 file changed, 64 insertions(+), 48 d
Factor out the function dev_extent_search_start() from
find_free_dev_extent_start() to decide the starting position of a device
extent search.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/ker
btrfs_alloc_data_chunk().
Patch 8 fixes a bug of calculating stripe size in DUP profile.
Patches 9 to 12 clean up btrfs_alloc_chunk() code by dropping unnecessary
parameters, and using better macro/variable name to clarify the meaning.
Naohiro Aota (12):
btrfs-progs: introduce chunk allocation policy
btrfs
Introduce chunk allocation policy for btrfs. This policy controls how
chunks and device extents are allocated from devices.
Signed-off-by: Naohiro Aota
---
kernel-shared/volumes.c | 1 +
kernel-shared/volumes.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/kernel-shared/volumes.c b/
Marking BUG() unreachable helps us silence unnecessary warnings e.g.
"warning: control reaches end of non-void function [-Wreturn-type]" like
the code below.
int foo()
{
...
if (XXX)
return 0;
else if (YYY)
return 1;
else
> to resolve various concerns around the mixture of code in btrfs-progs
> > with libbtrfsutil.
> >
> > Each significant (i.e. non-trivial) commit author has been CC'd to
> > request their sign-off on this. Please reply to this to acknowledge
> > whether or not this is
kernel commit mentioned above.
Link: https://github.com/kdave/btrfs-progs/issues/338
Signed-off-by: Su Yue
Reviewed-by: Boris Burkov
---
Changelog:
v2:
Change the commit description little.
Add the reviewed-by.
Remove 'RFC' from subject.
---
check/main.c | 5 +
1 fil
On Fri 26 Mar 2021 at 21:52, Su Yue wrote:
On Fri 26 Mar 2021 at 20:50, Qu Wenruo wrote:
[BUG]
If restoring dumpped image into a new file, under most cases
kernel will
reject it:
# mkfs.btrfs -f /dev/test/test
# btrfs-image /dev/test/test /tmp/dump
# btrfs-image -r /tmp/dump ~/test.img
On Fri 26 Mar 2021 at 20:50, Qu Wenruo wrote:
[BUG]
If restoring dumpped image into a new file, under most cases
kernel will
reject it:
# mkfs.btrfs -f /dev/test/test
# btrfs-image /dev/test/test /tmp/dump
# btrfs-image -r /tmp/dump ~/test.img
# mount ~/test.img /mnt/btrfs
mount: /mnt
/bash
+# Verify that the restored image of an empty btrfs can still be mounted
+
+source "$TEST_TOP/common"
+
+check_prereq btrfs-image
+check_prereq mkfs.btrfs
+check_prereq btrfs
+
+tmp=$(mktemp -d --tmpdir btrfs-progs-image.)
+prepare_test_dev
+
+run_check_mkfs_test_dev
+run_ch
d with new test case to detect
such problem.
Also remove one dead code exposed during the development.
Qu Wenruo (3):
btrfs: image: remove the dead stat() call
btrfs-progs: image: enlarge the output file if no tree modification is
needed for restore
btrfs-progs: misc-tests: add test to
[BUG]
If restoring dumpped image into a new file, under most cases kernel will
reject it:
# mkfs.btrfs -f /dev/test/test
# btrfs-image /dev/test/test /tmp/dump
# btrfs-image -r /tmp/dump ~/test.img
# mount ~/test.img /mnt/btrfs
mount: /mnt/btrfs: wrong fs type, bad option, bad superblock on /
btrfs_wipe_existing_sb() misses calling blkid_do_fullprobe() to do
the real probe. After calling blkid_new_probe() &
blkid_probe_set_device() to setup blkid_probe context, it directly
calls blkid_probe_lookup_value(). This results in
blkid_probe_lookup_value returning -1, because pr->values is empt
Hi,
btrfs-progs version 5.11.1 have been released. This is a bugfix release.
Changelog:
* properly format checksums when a mismatch is reported
* check: fix false alert on tree block crossing 64K page boundary
* convert:
* refuse to convert filesystem with 'needs_rec
HARED_DEFINE
> == 1)
> but HAVE_OWN_FIEMAP_EXTENT_SHARED_DEFINE is set to 1 by configure only if
> FIEMAP_EXTENT_SHARED is not defined in the kernel headers.
>
> If you agree, I'll send a patch to completely remove this check.
The explanation why we want the configure-time check is
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 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
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 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.
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
On 2021/3/22 下午10:03, Sidong Yang wrote:
This comment is outdated and this patch remove
it to avoid confusion.
Signed-off-by: Sidong Yang
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
cmds/qgroup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cmds/qgroup.c b/cmds/qgroup.c
index 2da8
This comment is outdated and this patch remove
it to avoid confusion.
Signed-off-by: Sidong Yang
---
cmds/qgroup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cmds/qgroup.c b/cmds/qgroup.c
index 2da83ffd..b33f77fa 100644
--- a/cmds/qgroup.c
+++ b/cmds/qgroup.c
@@ -81,9 +81,6 @@ static
If extent tree is corrupted then open_ctree without OPEN_CTREE_NO_BLOCK_GROUPS
does fail preventing use of btrfs-map-logical at all.
Also even if we can't find extent it still can be useful to get physical
offset which could be correct.
Signed-off-by: Dāvis Mosāns
---
btrfs-map-logical.c | 7 +++
Given extents:
[21057146519552,21057146535936)
[21057146552320,21057146568704)
and trying to map 21057146535936 we would find 21057146519552
which would give us extent with length of 0 because
> real_logical = max(logical, cur_logical); // logical (21057146535936)
> real_len = min(logical + bytes
On 2021/3/21 下午7:33, Sidong Yang wrote:
Hello!
I see an comment in qgroup cmds below.
diff --git a/cmds/qgroup.c b/cmds/qgroup.c
index 2da83ffd..a71089e9 100644
--- a/cmds/qgroup.c
+++ b/cmds/qgroup.c
@@ -84,6 +84,7 @@ static int _cmd_qgroup_assign(const struct cmd_struct
*cmd, int assign,
Hello!
I see an comment in qgroup cmds below.
diff --git a/cmds/qgroup.c b/cmds/qgroup.c
index 2da83ffd..a71089e9 100644
--- a/cmds/qgroup.c
+++ b/cmds/qgroup.c
@@ -84,6 +84,7 @@ static int _cmd_qgroup_assign(const struct cmd_struct
*cmd, int assign,
/*
* FIXME src should accept s
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 identifier.
This patch prevents using AC_DEFINE twice for
HAVE_OWN_FIEMAP_EXTENT_DEFINE,
) && (HAVE_OWN_FIEMAP_EXTENT_SHARED_DEFINE ==
1)
but HAVE_OWN_FIEMAP_EXTENT_SHARED_DEFINE is set to 1 by configure only if
FIEMAP_EXTENT_SHARED is not defined in the kernel headers.
If you agree, I'll send a patch to completely remove this check.
Pierre Labastie (1):
btrfs-progs: build system - do not
When user assign qgroup with qgroup id that is too big to exceeds
range and invade level value, and it works without any error. but
this action would be make undefined error. this code make sure that
qgroup id doesn't exceed range [0, 2^48-1]. and also checks qgroup
level that is in range [0, 2^16-
When user assign qgroup with qgroup id that is too big to exceeds
range and invade level value, and it works without any error. but
this action would be make undefined error. this code make sure that
qgroup id doesn't exceed range [0, 2^48-1]. and also checks qgroup
level that is in range [0, 2^16-
On Thu, Mar 18, 2021 at 09:34:14PM +0100, David Sterba wrote:
> On Thu, Mar 18, 2021 at 02:22:20AM +, Sidong Yang wrote:
> > On Wed, Mar 17, 2021 at 07:36:47PM +0100, David Sterba wrote:
> > > On Tue, Mar 16, 2021 at 01:27:46PM +, Sidong Yang wrote:
> > > > When user assign qgroup with qgro
btrfs inspect-internal --help show some incomplete sentenses. As shown
below,
btrfs inspect-internal --help
btrfs inspect-internal min-dev-size [options]
Get the minimum size the device can be shrunk to. The
btrfs inspect-internal dump-tree [options] [ ..]
This pat
btrfs inspect-internal --help show some incomplete sentenses. As shown
below,
btrfs inspect-internal --help
btrfs inspect-internal min-dev-size [options]
Get the minimum size the device can be shrunk to. The
btrfs inspect-internal dump-tree [options] [ ..]
This pat
On Thu, Mar 18, 2021 at 02:22:20AM +, Sidong Yang wrote:
> On Wed, Mar 17, 2021 at 07:36:47PM +0100, David Sterba wrote:
> > On Tue, Mar 16, 2021 at 01:27:46PM +, Sidong Yang wrote:
> > > When user assign qgroup with qgroup id that is too big to exceeds
> > > range and invade level value, a
lve various concerns around the mixture of code in btrfs-progs
> > with libbtrfsutil.
> >
> > Each significant (i.e. non-trivial) commit author has been CC'd to
> > request their sign-off on this. Please reply to this to acknowledge
> > whether or not this is accepta
On 18/03/2021 04:01, 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.
Each significant (i.e
On Wed, 2021-03-17 at 16:01 -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
>
On 2021/3/18 上午10:22, Sidong Yang wrote:
On Wed, Mar 17, 2021 at 07:36:47PM +0100, David Sterba wrote:
On Tue, Mar 16, 2021 at 01:27:46PM +, Sidong Yang wrote:
When user assign qgroup with qgroup id that is too big to exceeds
range and invade level value, and it works without any error.
On Wed, Mar 17, 2021 at 07:36:47PM +0100, David Sterba wrote:
> On Tue, Mar 16, 2021 at 01:27:46PM +, Sidong Yang wrote:
> > When user assign qgroup with qgroup id that is too big to exceeds
> > range and invade level value, and it works without any error. but
> > this action would be make unde
On 2021/3/18 上午4:01, 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.
Each significant (i.e
> Subject: [PATCH 0/1] btrfs-progs: libbtrfsutil: Relicense to LGPLv2.1+
>
> 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
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
inks to
> > `libbtrfsutil`
> > statically this might cause a license conflict. See [3]. This would be the
> > part
> > that might require upstream fixing.
>
> Thanks for bringing it up.
>
> > [1]
> > https://github.com/kdave/btrfs-progs/blob/master/libbtrf
This resolves the licensing conflict with GPLv2 code and makes it
suitable for environments that have a policy against GNU v3 licenses.
Signed-off-by: Neal Gompa
---
libbtrfsutil/COPYING | 1130 -
libbtrfsutil/COPYING.LESSER | 165 -
libbtrfsut
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.
Each significant (i.e. non-trivial) commit author has been CC&#
On Tue, Mar 16, 2021 at 01:27:46PM +, Sidong Yang wrote:
> When user assign qgroup with qgroup id that is too big to exceeds
> range and invade level value, and it works without any error. but
> this action would be make undefined error. this code make sure that
> qgroup id doesn't exceed range
On Wed, Mar 17, 2021 at 12:53:00PM +0100, Adam Borowski wrote:
> This is https://bugs.debian.org/985400
>
> - Forwarded message from Claudius Heine -
>
> Dear Maintainer,
>
> I looked into the licenses of the btrfs-progs project and found that the
> libbtrfsu
This is https://bugs.debian.org/985400
- Forwarded message from Claudius Heine -
Dear Maintainer,
I looked into the licenses of the btrfs-progs project and found that the
libbtrfsutils library is licensed under LGPL-3.0-or-later [1]
The `copyright` file does not show this this.
IANAL
On 2021/3/16 下午9:27, Sidong Yang wrote:
When user assign qgroup with qgroup id that is too big to exceeds
range and invade level value, and it works without any error. but
this action would be make undefined error. this code make sure that
qgroup id doesn't exceed range(0 ~ 2^48-1).
Signed-of
From: Boris Burkov
Adapt the existing send/receive tests by passing '-o --force-compress'
to the mount commands in a new test. After writing a few files in the
various compression formats, send/receive them with and without
--force-decompress to test both the encoded_write path and the
fallback t
1 - 100 of 3149 matches
Mail list logo
