> On Aug 13, 2019, at 9:54 PM, Qu Wenruo wrote:
>
>
>
>> On 2019/8/14 上午9:04, Jeff Mahoney wrote:
>> Printing the error number means having to go look up what that error
>> number means. For a developer, it's easy. For a user, it's unhelpful.
>>
>> Signed-off-by: Jeff Mahoney
>> ---
>> mk
On 2019/8/14 上午9:04, Jeff Mahoney wrote:
> Printing the error number means having to go look up what that error
> number means. For a developer, it's easy. For a user, it's unhelpful.
>
> Signed-off-by: Jeff Mahoney
> ---
> mkfs/main.c | 47 ++-
>
On 2019/8/14 上午9:04, Jeff Mahoney wrote:
> If a user attempts to resize a file system to a size under 256MiB,
> it will be rejected with EINVAL and get then unhelpful error message
> "ERROR: unable to resize '/path': Invalid argument."
>
> This commit performs that check before issuing the ioctl
On 2019/8/14 上午9:04, Jeff Mahoney wrote:
> The only difference between parse_limit and parse_size is that
> parse_limit accepts "none" as a valid input. That's easy enough
> to handle as a special case and lets us drop the duplicate code.
>
> Signed-off-by: Jeff Mahoney
Reviewed-by: Qu Wenruo
On 2019/8/14 上午9:03, Jeff Mahoney wrote:
> It's theoretically possible to add multiple devices with sizes that add up
> to or exceed 16EiB. A file system will be created successfully but will
> have a superblock with incorrect values for total_bytes and other fields.
>
> Kernels up to v5.0 will
On 2019/8/14 上午9:03, Jeff Mahoney wrote:
> When btrfs_add_to_fsid fails in mkfs we try to close the ctree. That
> complains that we already have a transaction open. We should be taking
> the error path and exit cleanly without writing.
>
> Signed-off-by: Jeff Mahoney
Reviewed-by: Qu Wenruo
On 13/8/19 2:14 AM, fdman...@kernel.org wrote:
From: Filipe Manana
At ctree.c:get_old_root(), we are accessing a root's header owner field
after we have freed the respective extent buffer. This results in an
use-after-free that can lead to crashes, and when CONFIG_DEBUG_PAGEALLOC
is set, result
The only difference between parse_limit and parse_size is that
parse_limit accepts "none" as a valid input. That's easy enough
to handle as a special case and lets us drop the duplicate code.
Signed-off-by: Jeff Mahoney
---
cmds/qgroup.c | 58
When btrfs_add_to_fsid fails in mkfs we try to close the ctree. That
complains that we already have a transaction open. We should be taking
the error path and exit cleanly without writing.
Signed-off-by: Jeff Mahoney
---
mkfs/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Btrfs kernel module drop its subvolume tree using post-order traversal,
this sometimes makes things harder to determine if we should print
one subtree.
For the full hassle it can lead to, please check the lengthy comment.
This patch will introduce a simple new facility, btrfs_drop_borderline,
to
If a user attempts to resize a file system to a size under 256MiB,
it will be rejected with EINVAL and get then unhelpful error message
"ERROR: unable to resize '/path': Invalid argument."
This commit performs that check before issuing the ioctl to report
a more sensible error message. We also d
It's theoretically possible to add multiple devices with sizes that add up
to or exceed 16EiB. A file system will be created successfully but will
have a superblock with incorrect values for total_bytes and other fields.
Kernels up to v5.0 will crash when they encounter this scenario.
We need to
[BUG]
For certain btrfs image, btrfs ins dump-tree can hit checksum error for
tree blocks:
$ btrfs ins dump-tree -t 256 /dev/test/scratch1 > /dev/null
checksum verify failed on 33173504 found 295F0086 wanted
checksum verify failed on 33173504 found 295F0086 wanted
checksu
For half dropped subvolumes, dump-tree can sometimes lead to csum error
if the dropped tree blocks are also trimmed.
E.g
node 33153024 level 1 items 61 free 60 generation 7 owner 256
fs uuid 793daf87-b345-4896-a500-adf19baabd92
chunk uuid 6fcfe63c-3a64-4e78-b095-5980186a0cc0
key (2
Printing the error number means having to go look up what that error
number means. For a developer, it's easy. For a user, it's unhelpful.
Signed-off-by: Jeff Mahoney
---
mkfs/main.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff -
Thanks for the dump.
Now it's very clear what the problem is.
It's an old kernel behavior which allows compressed file extents to have
NODATASUM flag.
The behavior is going to be fixed in v5.3 by commit 42c16da6d684
("btrfs: inode: Don't compress if NODATASUM or NODATACOW set").
Currently you c
From: Omar Sandoval
Commit ac0c7cf8be00 ("btrfs: fix crash when tracepoint arguments are
freed by wq callbacks") added a void pointer, wtag, which is passed into
trace_btrfs_all_work_done() instead of the freed work item. This is
silly for a few reasons:
1. The freed work item still has the same
From: Omar Sandoval
This does some cleanups to the Btrfs workqueue code following my
previous fix [1]. Changed since v1 [2]:
- Removed errant Fixes: tag in patch 1
- Fixed a comment typo in patch 2
- Added NB: to comments in patch 2
- Added Nikolay and Filipe's reviewed-by tags
Thanks!
1:
htt
From: Omar Sandoval
Commit 9e0af2376434 ("Btrfs: fix task hang under heavy compressed
write") worked around the issue that a recycled work item could get a
false dependency on the original work item due to how the workqueue code
guarantees non-reentrancy. It did so by giving different work functi
On Tue, Aug 13, 2019 at 09:52:31AM +0100, Filipe Manana wrote:
> On Tue, Aug 13, 2019 at 8:27 AM Omar Sandoval wrote:
> >
> > From: Omar Sandoval
> >
> > Commit 9e0af2376434 worked around the issue that a recycled work item
> > could get a false dependency on the original work item due to how the
From: Filipe Manana
The test currently fails on filesystems with a block size greater than 4Kb,
as dedupe operations fail with -EINVAL because the file offsets used are
not multiples of such block sizes (but they are multiples of 4Kb, 2Kb and
1Kb).
So update the test to use offsets that are mult
On 2019/8/13 下午9:40, Konstantin V. Gavrilenko wrote:
>
> Hi Qu,
>
> thanks for the quick response. so I've booted into the latest Archiso (kernel
> 5.2.xx, btrfs 5.2.xx) and rerun the # btrfs check and # btrfs scrub. The
> btrfs check output is rather large and is included as an attachment t
On 2019/8/13 下午5:48, Konstantin V. Gavrilenko wrote:
> Hi list
>
> I have run the btrfs check, and that reported multiple errors on the FS.
>
> # btrfs check --readonly --force /dev/kubuntu-vg/lv_root
>
Please don't skip the output, especially for btrfs check.
The first tree btrfs check chec
Hi list
I have run the btrfs check, and that reported multiple errors on the FS.
# btrfs check --readonly --force /dev/kubuntu-vg/lv_root
root 9214 inode 6850330 errors 2001, no inode item, link count wrong
unresolved ref dir 266982 index 22459 namelen 36 name
9621041045a17a475428a26fcf
On Tue, Aug 13, 2019 at 8:28 AM Omar Sandoval wrote:
>
> From: Omar Sandoval
>
> Commit ac0c7cf8be00 ("btrfs: fix crash when tracepoint arguments are
> freed by wq callbacks") added a void pointer, wtag, which is passed into
> trace_btrfs_all_work_done() instead of the freed work item. This is
>
On 13.08.19 г. 11:33 ч., David Goodwin wrote:
> Hi,
>
> Kernel 4.19.59.
>
>
> % btrfs fi us /backups/
> Overall:
> Device size: 4.00TiB
> Device allocated: 3.44TiB
> * Device unallocated: 572.95GiB*
> Device missing: 0.00B
> Used:
On Tue, Aug 13, 2019 at 8:27 AM Omar Sandoval wrote:
>
> From: Omar Sandoval
>
> Commit 9e0af2376434 worked around the issue that a recycled work item
> could get a false dependency on the original work item due to how the
> workqueue code guarantees non-reentrancy. It did so by giving different
Hi,
Kernel 4.19.59.
% btrfs fi us /backups/
Overall:
Device size: 4.00TiB
Device allocated: 3.44TiB
* Device unallocated: 572.95GiB*
Device missing: 0.00B
Used: 3.43TiB
* Free (estimated): 576.36GiB (min: 576
On 13.08.19 г. 10:26 ч., Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit ac0c7cf8be00 ("btrfs: fix crash when tracepoint arguments are
> freed by wq callbacks") added a void pointer, wtag, which is passed into
> trace_btrfs_all_work_done() instead of the freed work item. This is
> silly
On 13.08.19 г. 10:26 ч., Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit 9e0af2376434 worked around the issue that a recycled work item
> could get a false dependency on the original work item due to how the
> workqueue code guarantees non-reentrancy. It did so by giving different
> work
From: Omar Sandoval
Commit 9e0af2376434 worked around the issue that a recycled work item
could get a false dependency on the original work item due to how the
workqueue code guarantees non-reentrancy. It did so by giving different
work functions to different types of work.
However, the fix in "
From: Omar Sandoval
Commit ac0c7cf8be00 ("btrfs: fix crash when tracepoint arguments are
freed by wq callbacks") added a void pointer, wtag, which is passed into
trace_btrfs_all_work_done() instead of the freed work item. This is
silly for a few reasons:
1. The freed work item still has the same
From: Omar Sandoval
These are a couple of cleanups for Btrfs workqueues as a follow-up to
"Btrfs: fix workqueue deadlock on dependent filesystems" [1]. They are
based on misc-next + that patch.
Patch 1 removes the previous, incomplete fix for the same issue fixed by
[1]. Patch 2 is more of a nit
On 8/12/19 1:21 AM, Qu Wenruo wrote:
> The offending inode item.
>
>> block group 0 mode 100600 links 1 uid 1002 gid 100 rdev 0
>> sequence 0 flags 0x0(none)
>> atime 1395590849.0 (2014-03-23 16:07:29)
>> ctime 1395436187.0 (2014-03-21 21:09:47)
34 matches
Mail list logo
