Re: [PATCH 2/2] btrfs: Simplify btrfs_alloc_dev_extent

On 27.07.2017 20:57, Filipe Manana wrote: > On Thu, Jul 27, 2017 at 6:36 PM, Nikolay Borisov wrote: >> Currently btrfs_alloc_dev_extent essentially open codes btrfs_insert_item. So >> let's remove the superfluous code, leaving only the important bits, namely >> initialising

Re: [PATCH 2/5] btrfs-progs: convert: add missing newlines for printfs

On 2017年07月27日 23:47, je...@suse.com wrote: From: Jeff Mahoney There are two printfs with missing newlines that end up making the output wonky. Signed-off-by: Jeff Mahoney Those are the only two missing newline in convert/. No missing. Reviewed-by: Qu

Re: [PATCH 4/5] btrfs-progs: tests: fix typo in convert-tests/008-readonly-image

On 2017年07月27日 23:47, je...@suse.com wrote: From: Jeff Mahoney The dd in convert-tests/008-readonly-image is expected to fail, so there being a typo in the file name has gone unnoticed. Thanks for catching this. This is very embarrassing. Signed-off-by: Jeff Mahoney

Re: [PATCH 3/5] btrfs-progs: convert: use search_cache_extent in migrate_one_reserved_range

On 2017年07月27日 23:47, je...@suse.com wrote: From: Jeff Mahoney When we are looking for extents in migrate_one_reserved_range, it's likely that there will be multiple extents that fall into the 0-1MB range. If lookup_cache_extent is called with a range that covers multiple

Re: [PATCH 1/5] btrfs-progs: convert: properly handle reserved ranges while iterating files

On 2017年07月27日 23:47, je...@suse.com wrote: From: Jeff Mahoney Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate the available space) changed how we handle migrating file data so that we never have btrfs space associated with the reserved ranges. This

Re: [PATCH 1/3] btrfs-progs: convert: properly handle reserved ranges while iterating files

On 2017年07月28日 05:29, Jeff Mahoney wrote: On 7/27/17 12:38 PM, Jeff Mahoney wrote: On 7/26/17 9:35 PM, Qu Wenruo wrote: On 2017年07月26日 04:54, je...@suse.com wrote: From: Jeff Mahoney Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate the available

Re: Raid0 rescue

On Thu, Jul 27, 2017 at 08:25:19PM +, Duncan wrote: > >Welcome to RAID-0... > > As Hugo implies, RAID-0 mode, not just for btrfs but in general, is well > known among admins for being "garbage data not worth trying to recover" > mode. Not only is there no redundancy, but with raid0

[PATCH v2] btrfs: Remove extra parentheses from condition in copy_items()

There is no need for the extra pair of parentheses, remove it. This fixes the following warning when building with clang: fs/btrfs/tree-log.c:3694:10: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] if ((i == (nr - 1)))

Re: [PATCH 1/3] btrfs-progs: convert: properly handle reserved ranges while iterating files

On 7/27/17 12:38 PM, Jeff Mahoney wrote: > On 7/26/17 9:35 PM, Qu Wenruo wrote: >> >> >> On 2017年07月26日 04:54, je...@suse.com wrote: >>> From: Jeff Mahoney >>> >>> Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate >>> the available space) changed how we

Re: [PATCH 2/2] btrfs-progs: Use named constants for common sizes

Nikolay Borisov posted on Thu, 27 Jul 2017 11:17:00 +0300 as excerpted: > diff --git a/convert/main.c b/convert/main.c > index c56382e915fd..49ab829b5641 100644 > --- a/convert/main.c > +++ b/convert/main.c > @@ -1586,7 +1586,7 @@ next: > * | RSV 1 | | Old | |RSV 2 | | Old | |

Re: write corruption due to bio cloning on raid5/6

Janos Toth F. posted on Thu, 27 Jul 2017 16:14:47 +0200 as excerpted: > * This is off-topic but raid5 scrub is painful. The disks run at > constant ~100% utilization while performing at ~1/5 of their sequential > read speeds. And despite explicitly asking idle IO priority when > launching scrub,

Re: Raid0 rescue

Hugo Mills posted on Thu, 27 Jul 2017 15:10:38 + as excerpted: > On Thu, Jul 27, 2017 at 10:49:37AM -0400, Alan Brand wrote: >> I know I am screwed but hope someone here can point at a possible >> solution. >> >> I had a pair of btrfs drives in a raid0 configuration. One of the >> drives

Re: Raid0 rescue

> > Correct, I should have said 'superblock'. > > It is/was raid0. Funny thing is that this all happened when I was > > prepping to convert to raid1. >If youre metadata was also RAID-0, then your filesystem is almost > certainly toast. If any part of the btrfs metadata was overwritten by >

Re: Raid0 rescue

On Thu, Jul 27, 2017 at 03:43:37PM -0400, Alan Brand wrote: > Correct, I should have said 'superblock'. > It is/was raid0. Funny thing is that this all happened when I was > prepping to convert to raid1. If youre metadata was also RAID-0, then your filesystem is almost certainly toast. If any

Re: Raid0 rescue

Correct, I should have said 'superblock'. It is/was raid0. Funny thing is that this all happened when I was prepping to convert to raid1. running a btrfs-find-root shows this (which gives me hope) Well block 4871870791680(gen: 73257 level: 1) seems good, but generation/level doesn't match, want

Re: [PATCH v2] Btrfs: Do not use data_alloc_cluster in ssd mode

On 07/27/2017 09:11 PM, Duncan wrote: > Hans van Kranenburg posted on Wed, 26 Jul 2017 21:59:25 +0200 as > excerpted: > >> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h >> index 4f8f75d9e839..b091dd3f5b38 100644 >> --- a/fs/btrfs/ctree.h >> +++ b/fs/btrfs/ctree.h >> @@ -472,7 +472,7 @@ struct

[PATCH] btrfs-progs: eliminate bogus IOC_DEV_INFO call

Device ID numbers always start at 1, not at 0. The first IOC_DEV_INFO call does not make sense, since it will always return ENODEV. ioctl(3, BTRFS_IOC_DEV_INFO, {devid=0}) = -1 ENODEV (No such device) Signed-off-by: Hans van Kranenburg --- cmds-fi-usage.c | 2 +-

Re: [PATCH v2] Btrfs: Do not use data_alloc_cluster in ssd mode

Hans van Kranenburg posted on Wed, 26 Jul 2017 21:59:25 +0200 as excerpted: > diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h > index 4f8f75d9e839..b091dd3f5b38 100644 > --- a/fs/btrfs/ctree.h > +++ b/fs/btrfs/ctree.h > @@ -472,7 +472,7 @@ struct btrfs_block_rsv { > /* > * free clusters are

[PATCH] Btrfs: avoid unnecessarily locking inode when clearing a range

From: Filipe Manana If the range being cleared was not marked for defrag and we are not about to clear the range from the defrag status, we don't need to lock and unlock the inode. Signed-off-by: Filipe Manana --- fs/btrfs/inode.c | 7 --- 1 file

Re: [PATCH 2/2] btrfs: Simplify btrfs_alloc_dev_extent

On Thu, Jul 27, 2017 at 6:36 PM, Nikolay Borisov wrote: > Currently btrfs_alloc_dev_extent essentially open codes btrfs_insert_item. So > let's remove the superfluous code, leaving only the important bits, namely > initialising the device extent and just calling

[PATCH 1/2] btrfs: remove superfluous chunk_tree argument from btrfs_alloc_dev_extent

Currently this function is always called with the object id of the root key of the chunk_tree, which is always BTRFS_CHUNK_TREE_OBJECTID. So let's subsume it straight into the function itself. No functional change. Signed-off-by: Nikolay Borisov --- fs/btrfs/volumes.c | 12

[PATCH 2/2] btrfs: Simplify btrfs_alloc_dev_extent

Currently btrfs_alloc_dev_extent essentially open codes btrfs_insert_item. So let's remove the superfluous code, leaving only the important bits, namely initialising the device extent and just calling btrfs_insert_item. So first add definition for the stack-based set/get function. And then use

Re: [PATCH preview] btrfs: allow to set compression level for zlib

On Thu, Jul 27, 2017 at 03:52:56PM +0800, Anand Jain wrote: > > --- a/fs/btrfs/zlib.c > > +++ b/fs/btrfs/zlib.c > > @@ -37,6 +37,7 @@ struct workspace { > > z_stream strm; > > char *buf; > > struct list_head list; > > + int level; > > }; > > No need to set it for the workspace.

Re: [PATCH 1/3] btrfs-progs: convert: properly handle reserved ranges while iterating files

On 7/26/17 9:35 PM, Qu Wenruo wrote: > > > On 2017年07月26日 04:54, je...@suse.com wrote: >> From: Jeff Mahoney >> >> Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate >> the available space) changed how we handle migrating file data so that >> we never have

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

Small clarification after reading journal: errors stats weren't changed on sda since December, but READ error count was increased on sdc (especially in May, when I first noticed problems) and sdb. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

[PATCH 0/5 v2] btrfs-progs: convert fixes + reiserfs support

From: Jeff Mahoney Changes since v1: - reiserfs conversion: - use bool instead of int - catch 'impossible' condition of multiple discontiguous tails - properly handle hole followed by tail - add testing for combinations of real blocks, tails, and holes - print error

[PATCH 4/5] btrfs-progs: tests: fix typo in convert-tests/008-readonly-image

From: Jeff Mahoney The dd in convert-tests/008-readonly-image is expected to fail, so there being a typo in the file name has gone unnoticed. Signed-off-by: Jeff Mahoney --- tests/convert-tests/008-readonly-image/test.sh | 4 +++- 1 file changed, 3

[PATCH 5/5] btrfs-progs: convert: add support for converting reiserfs

From: Jeff Mahoney This patch adds support to convert reiserfs file systems in-place to btrfs. It will convert extended attribute files to btrfs extended attributes, translate ACLs, coalesce tails that consist of multiple items into one item, and convert tails that are too big

[PATCH 3/5] btrfs-progs: convert: use search_cache_extent in migrate_one_reserved_range

From: Jeff Mahoney When we are looking for extents in migrate_one_reserved_range, it's likely that there will be multiple extents that fall into the 0-1MB range. If lookup_cache_extent is called with a range that covers multiple cache entries, it will return the first entry it

[PATCH 1/5] btrfs-progs: convert: properly handle reserved ranges while iterating files

From: Jeff Mahoney Commit 522ef705e38 (btrfs-progs: convert: Introduce function to calculate the available space) changed how we handle migrating file data so that we never have btrfs space associated with the reserved ranges. This works pretty well and when we iterate over the

[PATCH 2/5] btrfs-progs: convert: add missing newlines for printfs

From: Jeff Mahoney There are two printfs with missing newlines that end up making the output wonky. Signed-off-by: Jeff Mahoney --- convert/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/convert/main.c b/convert/main.c index

Re: [PATCH v3] Btrfs: add skeleton code for compression heuristic

On Mon, Jul 24, 2017 at 11:40:17PM +0800, Anand Jain wrote: > > > Eg. files that are already compressed would increase the cpu consumption > > with compress-force, while they'd be hopefully detected as > > incompressible with 'compress' and clever heuristics. So the NOCOMPRESS > > bit would

Re: What are the typical usecase of "btrfs check --init-extent-tree"?

I've just noticed a huge number of errors on one of the RAID's disks. "btrfs dev stats" gives: [/dev/sdc1].write_io_errs0 [/dev/sdc1].read_io_errs 305 [/dev/sdc1].flush_io_errs0 [/dev/sdc1].corruption_errs 429 [/dev/sdc1].generation_errs 0 [/dev/sda1].write_io_errs58331

Re: [PATCH] btrfs: prepare for extensions in compression options

On Thu, Jul 27, 2017 at 03:25:37PM +0800, Anand Jain wrote: > On 07/18/2017 12:22 AM, David Sterba wrote: > > This is a minimal patch intended to be backported to older kernels. > > We're going to extend the string specifying the compression method and > > this would fail on kernels before that

Re: [PATCH] btrfs: use appropriate define for the fsid

On Thu, Jul 27, 2017 at 07:02:36PM +0800, Anand Jain wrote: > Though BTRFS_FSID_SIZE and BTRFS_UUID_SIZE or of same size, > for the purpose of doing it correctly use BTRFS_FSID_SIZE instead. There are many more uses of fs_info::fsid and BTRFS_UUID_SIZE, can you please fix them all in one go? --

Re: Raid0 rescue

On Thu, Jul 27, 2017 at 10:49:37AM -0400, Alan Brand wrote: > I know I am screwed but hope someone here can point at a possible solution. > > I had a pair of btrfs drives in a raid0 configuration. One of the > drives was pulled by mistake, put in a windows box, and a quick NTFS > format was

Raid0 rescue

I know I am screwed but hope someone here can point at a possible solution. I had a pair of btrfs drives in a raid0 configuration. One of the drives was pulled by mistake, put in a windows box, and a quick NTFS format was done. Then much screaming occurred. I know the data is still there. Is

Re: write corruption due to bio cloning on raid5/6

> It should only affect the dio-written files, the mentioned bug makes > btrfs write garbage into those files, so checksum fails when reading > files, nothing else from this bug. Thanks for confirming that. I thought so but I removed the affected temporary files even before I knew they were

What are the typical usecase of "btrfs check --init-extent-tree"?

My RAID-1 FS have multiple "backpointer mismatch" errors. "btrfs check --repair" doesn't help but only increases the number of errors. Initially, only 2 roots were affected (uncleanly deleted snapshots I suppose). But after I ran "check --repair" new "check --readonly" returns such errors on

[PATCH] btrfs: Remove extraneous chunk_objectid variable

BTRFS_FIRST_CHUNK_TREE_OBJECTIS id the only objectid being used in the chunk_tree. So remove a variable which is always set to that value and collapse its usage in callees which are passed this variable. No functional changes Signed-off-by: Nikolay Borisov ---

[PATCH] btrfs: Remove chunk_objectid argument from btrfs_make_block_group

btrfs_make_block_group is always called with chunk_objectid set to BTRFS_FIRST_CHUNK_TREE_OBJECTID. There's no reason why this behavior will change anytime soon, so let's remove the argument and decrease the cognitive load when reading the code path. No functional change Signed-off-by: Nikolay

[no subject]

subscribe linux-btrfs -- 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: use appropriate define for the fsid

Though BTRFS_FSID_SIZE and BTRFS_UUID_SIZE or of same size, for the purpose of doing it correctly use BTRFS_FSID_SIZE instead. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/disk-io.c

[PATCH] btrfs-progs: check: check tree blocks using walking tree down and up

This patch prepares for extent-tree repair in lowmem mode. In the lowmem mode, checking tree blocks of various tree is in recursive way. But if during repair, add or delete of item(s) may modify upper nodes which will cause the repair to be complicated and dangerous. Changing the way of traversal

Re: [PATCH] btrfs: Remove extra parentheses from condition in copy_items()

> - if ((i == (nr - 1))) > + if (i == (nr - 1)) Please remove the other set of redundant parentheses as well if you change that line. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More

[PATCH 1/2] btrfs-progs: Use already defined BTRFS_BLOCK_GROUP_PROFILE_MASK

Instead of opencoding it. No functional changes. Signed-off-by: Nikolay Borisov --- volumes.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/volumes.c b/volumes.c index b350e259dded..e60dc0e0dd93 100644 --- a/volumes.c +++ b/volumes.c @@ -869,10

[PATCH 2/2] btrfs-progs: Use named constants for common sizes

There multiple places where we use well-known sizes - 1,8,16,32 megabytes. We also have them defined as constants in the sizes.h header. So let's use them. No functional changes. Signed-off-by: Nikolay Borisov --- convert/main.c | 8 mkfs/common.c | 2 +-

Re: [PATCH preview] btrfs: allow to set compression level for zlib

On 07/25/2017 01:29 AM, David Sterba wrote: Preliminary support for setting compression level for zlib, the following works: I got too busy with stuff outside of btrfs, though I agreed to work on this, sorry that I couldn't prioritize ahead of yours. Now deleted this from my list. $

Re: [PATCH] btrfs: prepare for extensions in compression options

On 07/18/2017 12:22 AM, David Sterba wrote: This is a minimal patch intended to be backported to older kernels. We're going to extend the string specifying the compression method and this would fail on kernels before that change (the string is compared exactly). Relax the string matching only