[BUG]
For certains crafted image, whose csum root leaf has missing backref, if
we try to trigger write with data csum, it could cause deadlock with the
following kernel WARN_ON():
--
WARNING: CPU: 1 PID: 41 at fs/btrfs/locking.c:230 btrfs_tree_lock+0x3e2/0x400
CPU: 1 PID: 41 Comm: kworker/u4:1
On Mon, Aug 13, 2018 at 11:56:05PM +0200, erentheti...@mail.de wrote:
> Running time of 55:06:35 indicates that the counter is right, it is
> not enough time to scrub the entire array using hdd.
>
> 2TiB might be right if you only scrubbed one disc, "sudo btrfs scrub
> start /dev/sdx1" only
On Mon, Aug 13, 2018 at 09:20:22AM +0200, Menion wrote:
> Hi
> I have a BTRFS RAID5 array built on 5x8TB HDD filled with, well :),
> there are contradicting opinions by the, well, "several" ways to check
> the used space on a BTRFS RAID5 array, but I should be aroud 8TB of
> data.
> This array is
The btrfs_release_path() is just useless as path is only used in error handling.
Signed-off-by: Liu Bo
---
fs/btrfs/inode.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index eba61bcb9bb3..5680e9c462a3 100644
--- a/fs/btrfs/inode.c
+++
As we're going to return, it doesn't make sense to get a new
write_lock_level from unlock_up.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 41eb47488e75..f032b48094b4 100644
---
Hi David,
Just a gentle ping..
Thanks, Anand
On 08/08/2018 07:33 AM, Anand Jain wrote:
On 08/08/2018 01:51 AM, David Sterba wrote:
On Mon, Aug 06, 2018 at 09:09:47AM +0800, Anand Jain wrote:
Adds cli and ioctl to forget a scanned device or forget all stale
devices in the kernel.
Running time of 55:06:35 indicates that the counter is right, it is not enough
time to scrub the entire array using hdd.
2TiB might be right if you only scrubbed one disc, "sudo btrfs scrub start
/dev/sdx1" only scrubs the selected partition,
whereas "sudo btrfs scrub start
On Mon, Aug 06, 2018 at 02:25:24PM +0900, Misono Tomohiro wrote:
> There are two members in struct btrfs_root which indicate root's
> objectid: ->objectid and ->root_key.objectid.
>
> They are both set to the same value in __setup_root():
> static void __setup_root(struct btrfs_root *root,
>
On Mon, Aug 06, 2018 at 02:17:54PM +0800, Qu Wenruo wrote:
> > - u64 objectid;
>
> Off topic crazy idea here.
>
> I think it is a little crazy, but it should save a lot of objectid
> related modification:
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 118346aceea9..e6d70f2309a3
On 2018-08-12 03:04, Andrei Borzenkov wrote:
12.08.2018 06:16, Chris Murphy пишет:
On Fri, Aug 10, 2018 at 9:29 PM, Duncan <1i5t5.dun...@cox.net> wrote:
Chris Murphy posted on Fri, 10 Aug 2018 12:07:34 -0600 as excerpted:
But whether data is shared or exclusive seems potentially ephemeral,
Hi
I have a BTRFS RAID5 array built on 5x8TB HDD filled with, well :),
there are contradicting opinions by the, well, "several" ways to check
the used space on a BTRFS RAID5 array, but I should be aroud 8TB of
data.
This array is running on kernel 4.17.3 and it definitely experienced
power loss
For developer, it's pretty common to use "btrfs check" or "btrfs ins
dump-tree" on raw dumps.
Even for end user, they may hit case where they need to run "btrfs check"
on raw images.
However "btrfs check" can only complete real block devices, and
"btrfs inspect dump-tree" can only complete dir.
For developers it's pretty common to call "btrfs check" on a raw image
dump other than real block device.
It's also possible to end users to do some tests on loop devices.
So current _btrfs_devs() is really making things worse. Use _filedir()
to replace _btrfs_devs() so it can complete any
For dump-tree/dump-super the completion uses default filedir -d, which
is far from convenient.
Use filedir for dump-tree/dump-super/inode-resolve just like rootid.
Signed-off-by: Qu Wenruo
---
btrfs-completion | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/btrfs-completion
14 matches
Mail list logo
