[PATCH V2] fstests: btrfs: Use compressible data

/dev/urandom is incompressible and, /dev/zero is highly compressible, so both are less effective in testing the compress code logic in btrfs. This patch introduces a text data generator cat /dev/urandom | od to populate the files where /dev/urandom is currently being used in the btrfs test

Re: [PATCH] fstests: btrfs: Use compressible data

On 02/06/17 12:20, Eryu Guan wrote: On Wed, Feb 01, 2017 at 09:50:28PM +0800, Anand Jain wrote: /dev/urandom is incompressible and, /dev/zero is highly compressible, so both are less effective in testing the compress code logic in btrfs. This patch introduces a text data generator cat

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On 2017/02/06 12:35, Liu Bo wrote: a) __extent_writepage has handled the case when nr == 0. Yes, I agree this. b) when nr == 1, the page is marked with writeback bit and added into a bio, thus we have bio_end to deal with page bits. However, I don't think this is always correct,

[PATCH v2 10/12] btrfs-progs: fsck-test: Add new test case for file extent false alerts

Lowmem mode exposed several false alerts, all related to file extents check. 1) Partly written prealloc extent Cause lowmem mode to report missing csum or prealloc extent should not have csum 2) Compressed inline extent Cause lowmem mode to find mismatch on inline len and item len.

[PATCH v2 11/12] btrfs-progs: fsck: Fix lowmem mode override to allow it skip repair work

From: Lu Fengqi Current common.local doesn't handle lowmem mode well. It passes "--mode=lowmem" alone with "--repair", making it unable to check lowmem mode. It's caused by the following bugs: 1) Wrong variable in test/common.local We should check TEST_ARGS_CHECK,

[PATCH v2 00/12] Variant lowmem mode fixes

Patches can be fetch from github: https://github.com/adam900710/btrfs-progs/tree/lowmem_fixes Thanks for reports from Chris Murphy and Christoph Anton Mitterer, several new bugs are exposed for lowmem mode fsck. Special thank to Christoph, who did rounds of test during the patch development.

[PATCH v2 12/12] btrfs-progs: cmds-check.c: walk_down_tree_v2 break cause of leaf process

From: Su Yue In lowmem mode, 'walk_down_tree_v2' returns negative values wheather the error is fatal or not. It causes the loop where 'walk_down_tree_v2' is to break even the error is tolerated and then subsequent nodes process will be skipped. Fix it by redefining

[PATCH v2 09/12] btrfs-progs: fsck-test: Make 013 compatible with lowmem mode

fsck-tests/013-extent-tree-rebuild uses "--init-extent-tree", which implies "--repair". But the test script doesn't specify "--repair" for lowmem mode test to detect it. Add it so lowmem mode test can be happy with it. Signed-off-by: Qu Wenruo ---

[PATCH v2 03/12] btrfs-progs: lowmem check: Fix false alert in checking data extent csums

Btrfs lowmem check can report false csum error like: ERROR: root 5 EXTENT_DATA[257 0] datasum missing ERROR: root 5 EXTENT_DATA[257 4096] prealloc shouldn't have datasum This is because lowmem check code always compare the found csum size with the whole extent which data extents points to.

[PATCH v2 05/12] btrfs-progs: lowmem check: Fix false alert on inline compressed extent

Old lowmem check doesn't check if the inline extent is compressed and always check extent numbytes against inline item size. And when it finds the extent numbytes mismatch with inline item size it doesn't output any error message, just return error silently, making it quite hard to debug. Fix it

[PATCH v2 04/12] btrfs-progs: lowmem check: Fix extent item size false alert

If one extent item has no inline ref, btrfs lowmem mode check can give false alert without outputting any error message. The problem is lowmem mode always assume that extent item has inline refs, and when it encounters such case it flags the extent item has wrong size, but doesn't output the

[PATCH v2 08/12] btrfs-progs: fsck-test: Add test image for lowmem mode block group false alert

Add a minimal image which can reproduce the block group used space false alert for lowmem mode fsck. Reported-by: Christoph Anton Mitterer Signed-off-by: Qu Wenruo --- .../block_group_item_false_alert.raw.xz | Bin 0 -> 47792 bytes

[PATCH v2 06/12] btrfs-progs: lowmem check: Fix silent error if first inode item missing

If first inode item is missing, lowmem check will detect it but not output any error message. Add error message for it. Signed-off-by: Qu Wenruo --- cmds-check.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cmds-check.c b/cmds-check.c index cf5a08ce..7d273623

[PATCH v2 01/12] btrfs-progs: lowmem check: Fix several bugs related to afterward search

Since btrfs_search_slot() can points to the slot which is beyond the leaves' capacity, we should pay extra attention when doing afterward search. While for lowmem check, several places uses afterward search: 1) Block group item used space check 2) Device item used space check 3) Data extent

[PATCH v2 07/12] btrfs-progs: tests: Move fsck-tests/015 to fuzz tests

The test case fsck-tests/015-check-bad-memory-access can't be repair by btrfs check, and it's a fortunate bug makes original mode to forget the error code from extent tree, making original mode pass it. So fuzz-tests is more suitable for it. Signed-off-by: Qu Wenruo ---

[PATCH v2 02/12] btrfs-progs: check: Output verbose error when fsck found a bug in any tree

Although we output error like "errors found in extent allocation tree or chunk allocation", but we lacks such output for other trees, but leaving the final "found error is %d" to catch the last return value(and sometime it's cleared) This patch adds extra error message for top level error path,

Re: Is it possible to have metadata-only device with no data?

Hans van Kranenburg posted on Sun, 05 Feb 2017 22:55:42 +0100 as excerpted: > On 02/05/2017 10:42 PM, Alexander Tomokhov wrote: >> Is it possible, having two drives to do raid1 for metadata but keep >> data on a single drive only? > > Nope. > > Would be a really nice feature though... Putting

Re: [PATCH] fstests: btrfs: Use compressible data

On Wed, Feb 01, 2017 at 09:50:28PM +0800, Anand Jain wrote: > /dev/urandom is incompressible and, /dev/zero is highly compressible, > so both are less effective in testing the compress code logic in btrfs. > > This patch introduces a text data generator > cat /dev/urandom | od I noticed that

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On Sat, Feb 04, 2017 at 09:42:17PM +0900, takafumi-sslab wrote: > > > (But it could be changed after subpagesize block patchset, and there is > > more work rather than just adding a end_page_writeback, e.g. writepage > > endio also needs to be updated). > > Ok... the discussion become

Re: Battling an issue with btrfs quota

At 01/31/2017 08:15 AM, Philipp Kern wrote: Hi, my btrfs-based system (~2.5 TiB stored in the filesystem replicated onto on two disks, running kernel 4.9.6-1-ARCH) locked up after I enabled quotas and had a btrfs-size tool running. Now the question is how to recover from that. Whenever I

Re: Very slow balance / btrfs-transaction

At 02/04/2017 09:47 AM, Jorg Bornschein wrote: February 4, 2017 1:07 AM, "Goldwyn Rodrigues" wrote: On 02/03/2017 06:30 PM, Jorg Bornschein wrote: February 3, 2017 11:26 PM, "Goldwyn Rodrigues" wrote: Hi, I'm currently running a balance (without any

Re: [PATCH 0/9] Lowmem mode fsck fixes with fsck-tests framework update

At 02/04/2017 07:01 AM, Christoph Anton Mitterer wrote: Hey Qu On Fri, 2017-02-03 at 14:20 +0800, Qu Wenruo wrote: Great thanks for that! You're welcome. :) I also added missing error message output for other places I found, and updated the branch, the name remains as "lowmem_tests"

Re: Is it possible to have metadata-only device with no data?

On Sun, 5 Feb 2017 22:55:42 +0100 Hans van Kranenburg wrote: > On 02/05/2017 10:42 PM, Alexander Tomokhov wrote: > > Is it possible, having two drives to do raid1 for metadata but keep data on > > a single drive only? > > Nope. > > Would be a really nice

Re: Bug or feature? logical_to_ino skips inodes with offset mismatch

On 02/05/2017 10:54 PM, Hans van Kranenburg wrote: > I was playing around with logical_to_ino and also implemented calling > ino_lookup today to create a program that will print all data extents in > a block group, and their related inodes and at least one filename per inode. > >

Re: Is it possible to have metadata-only device with no data?

Am Mon, 06 Feb 2017 00:42:01 +0300 schrieb Alexander Tomokhov : > Is it possible, having two drives to do raid1 for metadata but keep > data on a single drive only? -- No, but you could take a look into bcache which should get you something similar if used in write-around mode.

Re: Is it possible to have metadata-only device with no data?

On 02/05/2017 10:42 PM, Alexander Tomokhov wrote: > Is it possible, having two drives to do raid1 for metadata but keep data on a > single drive only? Nope. Would be a really nice feature though... Putting metadata on SSD and bulk data on HDD... -- Hans van Kranenburg -- To unsubscribe from

Bug or feature? logical_to_ino skips inodes with offset mismatch

I was playing around with logical_to_ino and also implemented calling ino_lookup today to create a program that will print all data extents in a block group, and their related inodes and at least one filename per inode. https://github.com/knorrie/python-btrfs/commits/develop See "examples: show

Is it possible to have metadata-only device with no data?

Is it possible, having two drives to do raid1 for metadata but keep data on a single drive only? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] btrfs: query for extent compressed size

Simple patch which allows you to query with FIEMAP ioctl for disk blocks allocated per extent. It's done when you set new FIEMAP flag : * FIEMAP_FLAG_ONDISK If this flag is set, fe_length returns size of blocks allocated on the disk, rather than actual data length contained in extent. Here is

Btrfs crash following unhandled kernel paging request

Hello everyone, Apologies if this is the wrong place, this is my first time posting here. I just had a crash on one of my Btrfs filesystems, that happened to prevent it from mounting afterwards. I'd like to help preventing it from occuring again, or at least to write it there so that other

Re: btrfs receive leaves new subvolume modifiable during operation

Am Thu, 2 Feb 2017 10:52:26 + schrieb Graham Cobb : > On 02/02/17 00:02, Duncan wrote: > > If it's a workaround, then many of the Linux procedures we as > > admins and users use every day are equally workarounds. Setting > > 007 perms on a dir that doesn't have anything

Re: btrfs receive leaves new subvolume modifiable during operation

Am Wed, 1 Feb 2017 17:43:32 + schrieb Graham Cobb : > On 01/02/17 12:28, Austin S. Hemmelgarn wrote: > > On 2017-02-01 00:09, Duncan wrote: > >> Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as > >> excerpted: > [...] > >> > >> I'm just a btrfs-using