Re: btrfs goes read-only when btrfs-cleaner runs

On 16.01.19 г. 0:24 ч., Oliver Freyermuth wrote: > Am 14.01.19 um 01:48 schrieb Oliver Freyermuth: >> Am 13.01.19 um 22:51 schrieb Oliver Freyermuth: >>> I just upgraded to 4.20.1 from 4.19 (not sure if related) and my btrfs >>> backup volume entered read-only mode when running btrfs-cleaner, >

[PATCH RESEND 1/2] btrfs-progs: check for no result before using results

User space understands the ioctl BTRFS_IOC_DEV_REPLACE command status using the struct btrfs_ioctl_dev_replace_args::result, and so userspace initializes this to BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_RESULT, so exclude this value in checking for the error. Signed-off-by: Anand Jain --- cmds-replace.

[PATCH RESEND 2/2] btrfs-progs: replace: gracefully handle the exclusive operation report

Replace start fails to report the appropriate error if balance is already running, as below, btrfs rep start -B -f /dev/sdb /dev/sde /btrfs ERROR: ioctl(DEV_REPLACE_START) on '/btrfs' returns error: Fix it by checking if the return is > 0, as the kernel returns BTRFS_ERROR_DEV_EXCL_RUN_IN_PROGRE

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/16 上午9:38, Chris Murphy wrote: > On Tue, Jan 15, 2019 at 5:04 AM David Sterba wrote: >> >> On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: >>> Super nice move, it shows the corruption and the cause. >>> >>> item 66 key (1714119835648 METADATA_ITEM 0) itemoff 13325 item

Re: BTRFS critical corrupt leaf bad key order

On Tue, Jan 15, 2019 at 5:04 AM David Sterba wrote: > > On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: > > Super nice move, it shows the corruption and the cause. > > > > item 66 key (1714119835648 METADATA_ITEM 0) itemoff 13325 itemsize 33 > > item 67 key (10510212874240 M

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2019/1/16 上午9:34, Josef Bacik wrote: > On Wed, Jan 16, 2019 at 09:29:29AM +0800, Qu Wenruo wrote: >> >> >> On 2019/1/16 上午9:15, Josef Bacik wrote: >>> On Wed, Jan 16, 2019 at 09:07:26AM +0800, Qu Wenruo wrote: On 2019/1/16 上午8:31, Qu Wenruo wrote: > > > On 2019/1/16

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On Wed, Jan 16, 2019 at 09:29:29AM +0800, Qu Wenruo wrote: > > > On 2019/1/16 上午9:15, Josef Bacik wrote: > > On Wed, Jan 16, 2019 at 09:07:26AM +0800, Qu Wenruo wrote: > >> > >> > >> On 2019/1/16 上午8:31, Qu Wenruo wrote: > >>> > >>> > >>> On 2019/1/16 上午1:26, Josef Bacik wrote: > On Tue, Jan

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2019/1/16 上午9:15, Josef Bacik wrote: > On Wed, Jan 16, 2019 at 09:07:26AM +0800, Qu Wenruo wrote: >> >> >> On 2019/1/16 上午8:31, Qu Wenruo wrote: >>> >>> >>> On 2019/1/16 上午1:26, Josef Bacik wrote: On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote: > This patchset can be fetche

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On Wed, Jan 16, 2019 at 09:07:26AM +0800, Qu Wenruo wrote: > > > On 2019/1/16 上午8:31, Qu Wenruo wrote: > > > > > > On 2019/1/16 上午1:26, Josef Bacik wrote: > >> On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote: > >>> This patchset can be fetched from github: > >>> https://github.com/ada

Re: btrfs goes read-only when btrfs-cleaner runs

Am 16.01.19 um 02:11 schrieb Chris Murphy: > On Tue, Jan 15, 2019 at 5:41 PM Chris Murphy wrote: >> >> The relevant error messages are: >> >> unable to find ref byte >> errno=-2 No such entry >> >> Somehow a reference byte has been corrupted and inserted into multiple >> locations in the tree and

Re: btrfs goes read-only when btrfs-cleaner runs

Thanks for the reply! Am 16.01.19 um 01:41 schrieb Chris Murphy: > The relevant error messages are: > > unable to find ref byte > errno=-2 No such entry > > Somehow a reference byte has been corrupted and inserted into multiple > locations in the tree and it's not repairable: i.e. neither a corr

Re: btrfs goes read-only when btrfs-cleaner runs

On Tue, Jan 15, 2019 at 5:41 PM Chris Murphy wrote: > > The relevant error messages are: > > unable to find ref byte > errno=-2 No such entry > > Somehow a reference byte has been corrupted and inserted into multiple > locations in the tree and it's not repairable: i.e. neither a correct > value c

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2019/1/16 上午8:31, Qu Wenruo wrote: > > > On 2019/1/16 上午1:26, Josef Bacik wrote: >> On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote: >>> This patchset can be fetched from github: >>> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree >>> >>> Which is based on v5.0-rc1.

Re: btrfs goes read-only when btrfs-cleaner runs

The relevant error messages are: unable to find ref byte errno=-2 No such entry Somehow a reference byte has been corrupted and inserted into multiple locations in the tree and it's not repairable: i.e. neither a correct value can be inferred from other available information, nor do the tools hav

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2019/1/16 上午1:26, Josef Bacik wrote: > On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote: >> This patchset can be fetched from github: >> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree >> >> Which is based on v5.0-rc1. >> > > I've been testing these patches hoping to

Re: btrfs goes read-only when btrfs-cleaner runs

Am 15.01.19 um 23:24 schrieb Oliver Freyermuth: > Am 14.01.19 um 01:48 schrieb Oliver Freyermuth: >> Am 13.01.19 um 22:51 schrieb Oliver Freyermuth: >>> I just upgraded to 4.20.1 from 4.19 (not sure if related) and my btrfs >>> backup volume entered read-only mode when running btrfs-cleaner, >>> i

Re: applications hang on a btrfs spanning two partitions

Am Dienstag, 15. Januar 2019, 09:33:40 CET schrieb Duncan: > Marc Joliet posted on Mon, 14 Jan 2019 12:35:05 +0100 as excerpted: > > Am Montag, 14. Januar 2019, 06:49:58 CET schrieb Duncan: > > [...] > > > >> Unless you have a known reason not to[1], running noatime with btrfs > >> instead of the

Re: btrfs goes read-only when btrfs-cleaner runs

Am 14.01.19 um 01:48 schrieb Oliver Freyermuth: > Am 13.01.19 um 22:51 schrieb Oliver Freyermuth: >> I just upgraded to 4.20.1 from 4.19 (not sure if related) and my btrfs >> backup volume entered read-only mode when running btrfs-cleaner, >> i.e. when purging old subvolumes. >> >> I have attache

Re: issue mounting volume

On Tue, Jan 15, 2019 at 10:03 AM Christian Schneider wrote: > uname -a > Linux jane 4.19.6-gentoo #1 SMP PREEMPT Sat Dec 15 13:26:24 CET 2018 > x86_64 Intel(R) Core(TM) i7-4785T CPU @ 2.20GHz GenuineIntel GNU/Linux Your problem could be due to a block layer bug that's been discovered. It should

Re: [PATCH] Proposal for more detail in scrub doc

On Tue, Nov 27, 2018 at 03:14:37PM +0100, Andrea Gelmini wrote: > Wise words from Qu: > https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg82557.html > --- > Documentation/btrfs-scrub.asciidoc | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/btrfs-

Re: [PATCH v2 07/13] btrfs-progs: Fix Wmaybe-uninitialized warning

On Wed, Dec 05, 2018 at 10:03:30PM +0800, Qu Wenruo wrote: > > > On 2018/12/5 下午9:40, David Sterba wrote: > > On Wed, Dec 05, 2018 at 02:40:12PM +0800, Qu Wenruo wrote: > >> GCC 8.2.1 will report the following warning with "make W=1": > >> > >> ctree.c: In function 'btrfs_next_sibling_tree_bloc

Re: [PATCH] btrfs-progs: fix stray error message in check

On Fri, Jan 11, 2019 at 05:07:49PM -0500, je...@suse.com wrote: > From: Jeff Mahoney > > Commit e578b59bf61 (btrfs-progs: convert strerror to implicit %m) missed > adding braces after a conditional so we will see the following message > whenever a tree block needs repair, regardless of whether re

Re: [PATCH] btrfs-progs: image: Only enlarge result image if it's regular file

On Tue, Dec 18, 2018 at 03:58:41PM +0800, Qu Wenruo wrote: > This patch can also be folded into the original commit a7a44164c84e > ("btrfs-progs: image: Use correct device size when restoring") in devel > branch. I've applied this patch right after that one, as it's fixing a bit different problem.

Re: [PATCH] btrfs-progs: handle balance and replace concurrency

On Wed, Dec 19, 2018 at 12:01:44AM +0800, Anand Jain wrote: > Test case: > Run replace > btrfs repl start -B -f /dev/sdd /dev/sdb /btrfs; > while replace is still running, from another terminal try to start > balance > btrfs bal start --full-balance /btrfs; echo ...:$? > Done, had to relocate 0

Re: [PATCH 3/3] Btrfs-progs: add test for receive

On Mon, Jan 14, 2019 at 02:11:17PM +, Filipe Manana wrote: > On Mon, Jan 14, 2019 at 2:08 PM David Disseldorp wrote: > > > > On Mon, 14 Jan 2019 13:31:46 +, fdman...@kernel.org wrote: > > > > > From: Filipe Manana > > > > > > Add a test for a scenario that used to fail due to find_mount_r

Re: [PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote: > This patchset can be fetched from github: > https://github.com/adam900710/linux/tree/qgroup_delayed_subtree > > Which is based on v5.0-rc1. > I've been testing these patches hoping to get rid of the qgroup deadlock that these patches a

issue mounting volume

Hello all, after a power failure I have issues mounting a btrfs volume: mount /dev/md42 mount: /home: wrong fs type, bad option, bad superblock on /dev/md42, missing codepage or helper program, or other error dmesg [...] [ 4322.061000] BTRFS info (device md42): use lzo compression, level 0

Re: BTRFS critical corrupt leaf bad key order

Qu Wenruo writes: >> I'm working on the fix. >> Please make sure there is no write into the fs (just in case, since the >> fs should be RO). > > Here it is: > https://github.com/adam900710/btrfs-progs/tree/dirty_fix_for_leonard_lausen > > You need to git checkout the branch, and then compile. > (N

Re: btrfs hang on nfs?

Nikolay Borisov writes: > > > > > I'll have to rebuild the kernel with debug symbols. Do I have to be > > booted into the kernel for that command to be useful? > > Actually I think you are hitting the issue fixed by the following patch: > https://github.com/kdave/btrfs-devel/commit/

Re: How to repair "btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1"?,Re: How to repair "btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1"?

Dear Qu, At Tue, 15 Jan 2019 20:55:38 +0800, Qu Wenruo wrote: > On 2019/1/15 下午7:47, HIRAKI Hideaki wrote: >> Hello, >> >> I have two questions and a bug report. >> >> Once upon a time I converted an ext3 partition to BTRFS to mount on >> /var/lib/docker and was happy with it. Recently an error

Btrfs progs pre-release 4.20-rc1

Hi, this is a pre-release of btrfs-progs, 4.20-rc1. The 4.20 release is scheduled to this Friday, +3 days (2019-01-18). Changelog: * image: fix blockgroups when restroring from multi-device image * new feature: metadata uuid * lightweight change of UUID without rewriting all metadata

Re: How to repair "btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1"?

On 2019/1/15 下午7:47, HIRAKI Hideaki wrote: > Hello, > > I have two questions and a bug report. > > Once upon a time I converted an ext3 partition to BTRFS to mount on > /var/lib/docker and was happy with it. Recently an error occured: > > kernel: BTRFS info (device sdc1): leaf 2013170442240 t

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/15 下午8:28, Leonard Lausen wrote: > > Thanks Qu and David for your prompt attention! > > Qu Wenruo writes: >>> following tree-dumps: >>> >>> sudo btrfs inspect dump-tree -t root /dev/mapper/vg1-root > >>> /tmp/btrfsdumproot >>> sudo btrfs inspect dump-tree -b 1350630375424 /dev/m

Re: BTRFS critical corrupt leaf bad key order

Thanks Qu and David for your prompt attention! Qu Wenruo writes: >> following tree-dumps: >> >> sudo btrfs inspect dump-tree -t root /dev/mapper/vg1-root > >> /tmp/btrfsdumproot >> sudo btrfs inspect dump-tree -b 1350630375424 /dev/mapper/vg1-root > >> /tmp/btrfsdump1350630375424 >> >>

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/15 下午7:48, Qu Wenruo wrote: > > > On 2019/1/15 下午7:28, Leonard Lausen wrote: >> Hi everyone, >> >> I just found my btrfs filesystem to be remounted read-only with the >> following in my journalctl [1]: >> >> Jan 15 08:56:40 leonard-xps13 kernel: BTRFS critical (device dm-2): >> cor

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/15 下午8:03, David Sterba wrote: > On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: >> Super nice move, it shows the corruption and the cause. >> >> item 66 key (1714119835648 METADATA_ITEM 0) itemoff 13325 itemsize 33 >> item 67 key (10510212874240 METADATA_ITEM 0) it

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/15 下午7:51, David Sterba wrote: > On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: >>> following tree-dumps: >>> >>> sudo btrfs inspect dump-tree -t root /dev/mapper/vg1-root > >>> /tmp/btrfsdumproot >>> sudo btrfs inspect dump-tree -b 1350630375424 /dev/mapper/vg1-root >

Re: BTRFS critical corrupt leaf bad key order

On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: > Super nice move, it shows the corruption and the cause. > > item 66 key (1714119835648 METADATA_ITEM 0) itemoff 13325 itemsize 33 > item 67 key (10510212874240 METADATA_ITEM 0) itemoff 13283 itemsize 42 > item 68 key (1

Re: BTRFS critical corrupt leaf bad key order

On Tue, Jan 15, 2019 at 07:48:47PM +0800, Qu Wenruo wrote: > > following tree-dumps: > > > > sudo btrfs inspect dump-tree -t root /dev/mapper/vg1-root > > > /tmp/btrfsdumproot > > sudo btrfs inspect dump-tree -b 1350630375424 /dev/mapper/vg1-root > > > /tmp/btrfsdump1350630375424 > > > > Th

Re: BTRFS critical corrupt leaf bad key order

On 2019/1/15 下午7:28, Leonard Lausen wrote: > Hi everyone, > > I just found my btrfs filesystem to be remounted read-only with the > following in my journalctl [1]: > > Jan 15 08:56:40 leonard-xps13 kernel: BTRFS critical (device dm-2): corrupt > leaf: root=2 block=1350630375424 slot=68, bad

How to repair "btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1"?

Hello, I have two questions and a bug report. Once upon a time I converted an ext3 partition to BTRFS to mount on /var/lib/docker and was happy with it. Recently an error occured: kernel: BTRFS info (device sdc1): leaf 2013170442240 total ptrs 171 free space 6365 kernel: BTRFS error (device s

BTRFS critical corrupt leaf bad key order

Hi everyone, I just found my btrfs filesystem to be remounted read-only with the following in my journalctl [1]: Jan 15 08:56:40 leonard-xps13 kernel: BTRFS critical (device dm-2): corrupt leaf: root=2 block=1350630375424 slot=68, bad key order, prev (10510212874240 169 0) current (1714119868

Re: applications hang on a btrfs spanning two partitions

Marc Joliet posted on Mon, 14 Jan 2019 12:35:05 +0100 as excerpted: > Am Montag, 14. Januar 2019, 06:49:58 CET schrieb Duncan: > [...] >> Unless you have a known reason not to[1], running noatime with btrfs >> instead of the kernel-default relatime is strongly recommended, >> especially if you use

[PATCH v4 6/7] btrfs: qgroup: Use delayed subtree rescan for balance

Before this patch, qgroup code trace the whole subtree of file and reloc trees unconditionally. This makes qgroup numbers consistent, but it could cause tons of unnecessary extent trace, which cause a lot of overhead. However for subtree swap of balance, since both subtree contains the same conte

[PATCH v4 4/7] btrfs: qgroup: Refactor btrfs_qgroup_trace_subtree_swap()

Refactor btrfs_qgroup_trace_subtree_swap() into qgroup_trace_subtree_swap(), which only needs two extent buffer and some other bool to control the behavior. This provides the basis for later delayed subtree scan work. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 78 +

[PATCH v4 3/7] btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots()

Relocation code will drop btrfs_root::reloc_root as soon as merge_reloc_root() finishes. However later qgroup code will need to access btrfs_root::reloc_root after merge_reloc_root() for delayed subtree rescan. So alter the timming of resetting btrfs_root:::reloc_root, make it happens after trans

[PATCH v4 2/7] btrfs: qgroup: Don't trigger backref walk at delayed ref insert time

[BUG] Since fb235dc06fac ("btrfs: qgroup: Move half of the qgroup accounting time out of commit trans"), kernel may lockup with quota enabled. There is one backref trace triggered by snapshot dropping along with write operation in the source subvolume. The example can be stably reproduced. btrf

[PATCH v4 5/7] btrfs: qgroup: Introduce per-root swapped blocks infrastructure

To allow delayed subtree swap rescan, btrfs needs to record per-root info about which tree blocks get swapped. So this patch introduces per-root btrfs_qgroup_swapped_blocks structure, which records which tree blocks get swapped. The designed workflow will be: 1) Record the subtree root block get

Re: btrfs hang on nfs?

On 14.01.19 г. 15:13 ч., Scott E. Blomquist wrote: > > Nikolay Borisov writes: > > > > On 14.01.19 г. 13:42 ч., Scott E. Blomquist wrote: > > > > > > > > > > The file system hung again below is the sysrq output > > > > > > Linux kanlabfs 4.19.13-custom #1 SMP Wed Jan 9 08:36:50 EST

[PATCH v4 7/7] btrfs: qgroup: Cleanup old subtree swap code

Since it's replaced by new delayed subtree swap code, remove the original code. The cleanup is small since most of its core function is still used by delayed subtree swap trace. Signed-off-by: Qu Wenruo --- fs/btrfs/qgroup.c | 94 --- fs/btrfs/qgroup.

[PATCH v4 1/7] btrfs: qgroup: Move reserved data account from btrfs_delayed_ref_head to btrfs_qgroup_extent_record

[BUG] Btrfs/139 will fail with a pretty high possibility if the testing machine (VM) only has 2G ram. Resulting the final write success while it should fail due to EDQUOT, and the result fs will has quota exceeding the limit by 16K. The simplified reproducer will be: (needs a 2G ram VM) mkfs.b

[PATCH v4 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

This patchset can be fetched from github: https://github.com/adam900710/linux/tree/qgroup_delayed_subtree Which is based on v5.0-rc1. This patch address the heavy load subtree scan, but delaying it until we're going to modify the swapped tree block. The overall workflow is: 1) Record the subtre