Re: [PATCH] Btrfs: fix the mount failure due to missing devices

On Tue, May 02, 2017 at 05:48:40PM -0600, Liu Bo wrote: > Say there is a raid1 btrfs which consists of two disks, after one disk > becomes unavailable, we can still mount it in degraded mode once, for > the second mount it would refuse to mount it with an error > > "BTRFS warning (device sdf):

[PATCH] btrfs-progs: check: Fix heap use after free.

fsck/004-no-dir-index makes valgrinds complaining about Invalid read. ==31890== Invalid read of size 1 ==31890==at 0x453D09: repair_inode_backrefs (cmds-check.c:2690) ==31890==by 0x453D09: check_inode_recs (cmds-check.c:3330) ==31890==by 0x453D09: check_fs_root (cmds-check.c:4012)

[PATCH] Btrfs: fix the mount failure due to missing devices

Say there is a raid1 btrfs which consists of two disks, after one disk becomes unavailable, we can still mount it in degraded mode once, for the second mount it would refuse to mount it with an error "BTRFS warning (device sdf): missing devices (1) exceeds the limit (0), writeable mount is not

Re: Can I see what device was used to mount btrfs?

On Tue, May 02, 2017 at 10:15:06PM +0200, Kai Krakow wrote: > Ideally, the btrfs wouldn't even appear in /dev until it was assembled > by udev. But apparently that's not the case, and I think this is where > the problems come from. I wish, btrfs would not show up as device nodes > in /dev that the

Re: Can I see what device was used to mount btrfs?

Am Tue, 2 May 2017 21:50:19 +0200 schrieb Goffredo Baroncelli : > On 2017-05-02 20:49, Adam Borowski wrote: > >> It could be some daemon that waits for btrfs to become complete. > >> Do we have something? > > Such a daemon would also have to read the chunk tree. > > I

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Am Mon, 1 May 2017 22:56:06 -0600 schrieb Chris Murphy : > On Mon, May 1, 2017 at 9:23 PM, Marc MERLIN wrote: > > Hi Chris, > > > > Thanks for the reply, much appreciated. > > > > On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote: > >> What

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Am Tue, 2 May 2017 05:01:02 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Of course on-list I'm somewhat known for my arguments propounding the > notion that any filesystem that's too big to be practically > maintained (including time necessary to restore from backups, should > that be

Re: Can I see what device was used to mount btrfs?

On 2017-05-02 20:49, Adam Borowski wrote: >> It could be some daemon that waits for btrfs to become complete. Do we >> have something? > Such a daemon would also have to read the chunk tree. I don't think that a daemon is necessary. As proof of concept, in the past I developed a mount helper

Re: Can I see what device was used to mount btrfs?

On Tue, May 02, 2017 at 05:19:34PM +0300, Andrei Borzenkov wrote: > On Tue, May 2, 2017 at 4:58 PM, Adam Borowski wrote: > > On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote: > >> systemd waits for the final device that makes btrfs complete and mounts > >> it

btrfs check --repair: failed to repair damaged filesystem, aborting

(cc trimmed) The one in debian/unstable crashed: gargamel:~# btrfs --version btrfs-progs v4.7.3 gargamel:~# btrfs check --repair /dev/mapper/dshelf2 bytenr mismatch, want=2899180224512, have=3981076597540270796 extent-tree.c:2721: alloc_reserved_tree_block: Assertion `ret` failed. btrfs[0x43e418]

Re: [PATCH] Tidy while loop in end_compressed_writeback

I didn't consider it before, but I agree with your point on explicitly handling the return value from find_get_pages_contig. Thanks for looking over it, Sahil Original Message From: David Sterba Sent: May 2, 2017 9:01:34 AM PDT To: Sahil Kang

Re: [PATCH] btrfs-progs: tests: add variable quotation to convert-tests

On Mon, Apr 24, 2017 at 12:30:00AM +0530, Lakshmipathi.G wrote: > Signed-off-by: Lakshmipathi.G Applied, thanks. > - if [[ $TEST_LOG =~ dump ]]; then > + if [[ "$TEST_LOG" =~ dump ]]; then Please note, that the matched string

Re: [PATCH] Btrfs-progs: run_next_block: Return error code when extent buffer read fails

On Mon, Apr 24, 2017 at 04:57:17PM +0530, Praveen K Pandey wrote: > run_next_block() ignores the return value of read_tree_block() and > always returns success status. This might cause deal_root_from_list() > to loop infinitely when reading metadata block fails. This bug fixes > the issue by

Re: [PATCH 3/3 v2] Make max_size consistent with nr

On Fri, Apr 28, 2017 at 11:51:21AM +0200, Christophe de Dinechin wrote: > Since we memset tmpl, max_size==0. This does not seem consistent with nr = 1. > In check_extent_refs, we will call: > > set_extent_dirty(root->fs_info->excluded_extents, >rec->start, >

Re: [PATCH 2/3 v2] Prevent attempt to insert extent record with max_size==0

On Fri, Apr 28, 2017 at 11:50:23AM +0200, Christophe de Dinechin wrote: > When this happens, we will trip a BUG_ON(end < start) in insert_state > because in check_extent_refs, we use this max_size expecting it's not zero: > > set_extent_dirty(root->fs_info->excluded_extents, >

[PATCH] btrfs: always write superblocks synchronously

Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as synchronous" removed REQ_SYNC flag from WRITE_FUA implementation. Since REQ_FUA and REQ_FLUSH flags are stripped from submitted IO when the disk doesn't have volatile write cache and thus effectively make the write async. This was seen

Re: [PATCH 1/3] Disambiguate between cases where add_tree_backref fails

On Fri, Apr 28, 2017 at 11:12:35AM +0200, Christophe de Dinechin wrote: > See https://bugzilla.redhat.com/show_bug.cgi?id=1435567 for an example > where the message occurs, > > Signed-off-by: Christophe de Dinechin Applied, thanks. I've moved the strings to next line so

Re: [PATCH] Tidy while loop in end_compressed_writeback

On Wed, Apr 19, 2017 at 05:43:19AM -0700, Sahil Kang wrote: > This is my first patch so it's a minor code change. > I think removing the early continue from the loop makes the function a > little easier to follow. I think the opposite. In the current code, it's clear that if ret is 0, then

Re: [PATCH] Btrfs: remove an unused variable

On Tue, May 02, 2017 at 12:25:27PM +0300, Dan Carpenter wrote: > "item" is never used. > > Signed-off-by: Dan Carpenter Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: [PATCH 1/1 linux-next] btrfs: kmap() can't fail

On Tue, Apr 25, 2017 at 08:11:02PM +0200, Fabian Frederick wrote: > Remove NULL test on kmap() > > Signed-off-by: Fabian Frederick Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: [PATCH 6/7] btrfs: Make flush bios explicitely sync

On Tue, May 02, 2017 at 05:03:50PM +0200, Jan Kara wrote: > Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as > synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...} > definitions. generic_make_request_checks() however strips REQ_FUA and > REQ_PREFLUSH flags from a bio when

Re: [PATCH] btrfs-progs: btrfs-convert: Add larger device support

On Tue, May 02, 2017 at 05:06:01PM +0200, David Sterba wrote: > On Thu, Apr 27, 2017 at 03:35:34PM +0530, Lakshmipathi.G wrote: > > Bug: Fail to convert 22TB EXT4 to BTRFS > > https://bugzilla.kernel.org/show_bug.cgi?id=194795 > > Thanks for working on the bug, the proposed fix looks good to me

Re: [PATCH] btrfs-progs: btrfs-convert: Add larger device support

On Tue, May 02, 2017 at 05:06:01PM +0200, David Sterba wrote: > On Thu, Apr 27, 2017 at 03:35:34PM +0530, Lakshmipathi.G wrote: > > Bug: Fail to convert 22TB EXT4 to BTRFS > > https://bugzilla.kernel.org/show_bug.cgi?id=194795 > > Thanks for working on the bug, the proposed fix looks good to me

Re: [PATCH] btrfs-progs: check: Fix heap use after free.

On Tue, May 02, 2017 at 02:26:19PM +0800, Su Yue wrote: > The repair_inode_backrefs use the backref again after free while iterating > over backrefs. > So let it continue to next step after free can fix it. Please enhance the changelog. I'm missing some explanation that the new code is still

Re: [PATCH] btrfs-progs: btrfs-convert: Add larger device support

On Thu, Apr 27, 2017 at 03:35:34PM +0530, Lakshmipathi.G wrote: > Bug: Fail to convert 22TB EXT4 to BTRFS > https://bugzilla.kernel.org/show_bug.cgi?id=194795 Thanks for working on the bug, the proposed fix looks good to me judging by the use of extended API. This would need a test though. I'm

[PATCH 0/7] Fix fallout from changes to FUA and PREFLUSH definitions

Hello, this series addresses a performance issue caused by commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as synchronous". We know for certain this problem significanly regresses (over 10%, in some cases up to 100%) ext4 and btrfs for dbench4 and reaim benchmarks. Based on this I

[PATCH 6/7] btrfs: Make flush bios explicitely sync

Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...} definitions. generic_make_request_checks() however strips REQ_FUA and REQ_PREFLUSH flags from a bio when the storage doesn't report volatile write cache and thus write

Re: [PATCH v2] fstests: regression test for nocsum buffered read's repair

On Fri, Apr 28, 2017 at 6:26 PM, Liu Bo wrote: > This is to test whether buffered read retry-repair code is able to work in > raid1 case as expected. > > Please note that without checksum, btrfs doesn't know if the data used to > repair is correct, so repair is more of

Re: [PATCH v2] fstests: regression test for nocsum dio read's repair

On Fri, Apr 28, 2017 at 6:26 PM, Liu Bo wrote: > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > introduced this regression. It'd cause 'Segmentation fault' error. > > The upstream fix is > Btrfs: fix segment fault when doing dio read >

Re: [PATCH v3] fstests: regression test for btrfs buffered read's repair

On Fri, Apr 28, 2017 at 6:26 PM, Liu Bo wrote: > This case tests whether buffered read can repair the bad copy if we > have a good copy. > > Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed > and drop checks") introduced the regression. > > The upstream

Re: [PATCH v3] fstests: regression test for btrfs dio read repair

On Fri, Apr 28, 2017 at 6:25 PM, Liu Bo wrote: > This case tests whether dio read can repair the bad copy if we have > a good copy. > > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > introduced the regression. > > The upstream fix is >

Re: [PATCH] btrfs-progs: Use more restrict check to read out tree root

On Tue, Apr 25, 2017 at 04:40:16PM +0800, Qu Wenruo wrote: > For fuzzed image bko-156811-bad-parent-ref-qgroup-verify.raw, it cause > qgroup to report -ENOMEM. > > But the fact is, such image is heavy damaged so there is not valid root > item for extent tree. > > Normal extent tree key in root

Re: [PATCH] btrfs-progs: Fix fuzz-test for bko-161821.raw.txt

On Tue, May 02, 2017 at 03:36:09PM +0800, Lu Fengqi wrote: > Fuzzed image bko-161821.raw cause btrfs check to get segmentation fault. > > The function check_owner_ref attempts to access a non-exist quota tree > when dealing with extent_item [4198400 4096] in the corrupted filesystem. > > The

Re: [PATCH] btrfs-progs: check: Fix memory leak in check_chunks_and_extents

On Tue, May 02, 2017 at 11:17:25AM +0800, Qu Wenruo wrote: > fsck/003-shift-offsets makes valgrinds complaining about memory leaks. > ==5910== > ==5910== HEAP SUMMARY: > ==5910== in use at exit: 1,112 bytes in 11 blocks > ==5910== total heap usage: 161 allocs, 150 frees, 164,800 bytes

Re: [PATCH] btrfs-progs: tests: fssum, fix memory leak

On Wed, Apr 26, 2017 at 09:22:41AM +0800, Lu Fengqi wrote: > Free the alloced memory and close dir before exit. > > Signed-off-by: Lu Fengqi Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: Can I see what device was used to mount btrfs?

On Tue, May 2, 2017 at 4:58 PM, Adam Borowski wrote: > On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote: >> I'm chasing issue with btrfs mounts under systemd >> (https://github.com/systemd/systemd/issues/5781) - to summarize, systemd >> waits for the final

Re: [PATCH] btrfs-progs: Fix memory leak when 0 sized block group item is found

On Tue, Apr 25, 2017 at 04:01:17PM +0800, Qu Wenruo wrote: > When a 0 sized block group item is found, set_extent_bits() will not > really set any bits. > While set_state_private() still inserts allocated block group cache into > block group extent_io_tree. > > So at close_ctree() time, we won't

Re: [PATCH] btrfs-progs: tests: add variable quotation to fsck-tests

On Mon, Apr 24, 2017 at 06:59:40PM +0530, Lakshmipathi.G wrote: > Signed-off-by: Lakshmipathi.G Applied, thanks. As this was done out of order with other patches, tests/fsck-tests/026-check-inode-link/test.sh was skipped. -- To unsubscribe from this list: send the line

Re: Can I see what device was used to mount btrfs?

On Sun, Apr 30, 2017 at 08:47:43AM +0300, Andrei Borzenkov wrote: > I'm chasing issue with btrfs mounts under systemd > (https://github.com/systemd/systemd/issues/5781) - to summarize, systemd > waits for the final device that makes btrfs complete and mounts it using > this device name. Systemd

Re: BTRFS warning (device sda7): block group 181491728384 has wrong amount of free space

Marat Khalili posted on Tue, 02 May 2017 09:14:12 +0300 as excerpted: > I cannot understand two messages in syslog, could someone please shed > some light? Here they are: > >> Apr 29 08:54:03 container-name kernel: [792742.662375] BTRFS warning >> (device sda7): block group 181491728384 has

[PATCH] Btrfs: remove an unused variable

"item" is never used. Signed-off-by: Dan Carpenter diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 1e4e4532f381..337aef86dae5 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -5881,7 +5881,6 @@ static int btrfs_real_readdir(struct file *file, struct

[PATCH] btrfs-progs: Fix fuzz-test for bko-161821.raw.txt

Fuzzed image bko-161821.raw cause btrfs check to get segmentation fault. The function check_owner_ref attempts to access a non-exist quota tree when dealing with extent_item [4198400 4096] in the corrupted filesystem. The function btrfs_new_fs_info always allocate memory for fs_info->quota_root

Re: btrfs won't mount any more

On Thu, Apr 13, 2017 at 10:45:09AM +0200, Marc Haber wrote: > I do have a dd copy of the device now. > > $ sudo losetup --find --show ./dropbtr0.btrfs > $ sudo mount -o skip_balance -t btrfs /dev/loop0 /mnt/tempdisk > > does immediately result in: > > Apr 12 22:37:48 fan kernel: [ 124.742104]

runtime btrfsck

Hello list, i wanted to check an fs cause it has bad key ordering. But btrfscheck is now running since 7 days. Current output: # btrfsck -p --repair /dev/mapper/crypt_md0 enabling repair mode Checking filesystem on /dev/mapper/crypt_md0 UUID: 37b15dd8-b2e1-4585-98d0-cc0fa2a5a7c9 bad key ordering

[PATCH] btrfs-progs: check: Fix heap use after free.

fsck/004-no-dir-index makes valgrinds complaining about Invalid read. ==31890== Invalid read of size 1 ==31890==at 0x453D09: repair_inode_backrefs (cmds-check.c:2690) ==31890==by 0x453D09: check_inode_recs (cmds-check.c:3330) ==31890==by 0x453D09: check_fs_root (cmds-check.c:4012)

BTRFS warning (device sda7): block group 181491728384 has wrong amount of free space

Dear all, I cannot understand two messages in syslog, could someone please shed some light? Here they are: Apr 29 08:54:03 container-name kernel: [792742.662375] BTRFS warning (device sda7): block group 181491728384 has wrong amount of free space Apr 29 08:54:03 container-name kernel: