Incompat features: raid56 ... when creating a RAID6?

Hello everyone! I just wanted to create a RAID6 and got the following output: > # mkfs.btrfs -d raid6 -m raid6 -L slowPool /dev/sd[cdefgh] > btrfs-progs v4.4.1 > See http://btrfs.wiki.kernel.org for more information. > > Label: slowPool > UUID:

Re: Incompat features: raid56 ... when creating a RAID6?

On 03/16/2016 05:42 AM, Andreas Grosse wrote: Hello everyone! I just wanted to create a RAID6 and got the following output: # mkfs.btrfs -d raid6 -m raid6 -L slowPool /dev/sd[cdefgh] btrfs-progs v4.4.1 See http://btrfs.wiki.kernel.org for more information. Label: slowPool

Re: Incompat features: raid56 ... when creating a RAID6?

On Tue, Mar 15, 2016 at 10:42:29PM +0100, Andreas Grosse wrote: > Hello everyone! > > I just wanted to create a RAID6 and got the following output: > > > # mkfs.btrfs -d raid6 -m raid6 -L slowPool /dev/sd[cdefgh] [snip] > > Incompat features: extref, raid56, skinny-metadata [snip] > And then

Re: Snapshots slowing system

On 03/15/2016 03:52 PM, Duncan wrote: > Meanwhile, FWIW, some months ago I finally got tired of having to specify > noatime on all my mounts, expanding my fstab width by 8 chars (including > the ,) and the total fstab character count by several multiples of that > as I added it to all

Re: [PATCH v7 01/20] btrfs: dedup: Introduce dedup framework and its header

On 13 March 2016 at 12:55, Duncan <1i5t5.dun...@cox.net> wrote: > NeilBrown posted on Sun, 13 Mar 2016 22:33:22 +1100 as excerpted: > >> On Sun, Mar 13 2016, Qu Wenruo wrote: >> >>> BTW, I am always interested in, why de-duplication can be shorted as >>> 'dedupe'. > >>> I didn't see any 'e' in the

[Hit return to continue]

For the matter of completeness we need to check if the device being scanned has features that are known to the kernel. As of now if it doesn't - the mount will fails, then what is the point in having those devices added to the btrfs_fs_devices list at device_list_add(). So block those devices at

[PATCH v2 12/12] block: test fallocate for block devices

Now that we're wiring up fallocate's PUNCH_HOLE and ZERO_RANGE features for block devices, add some tests to make sure they work correctly. v2: Update tests to reflect EOD clamping suggested by Linus. Signed-off-by: Darrick J. Wong --- common/scsi_debug |6 ++

Re: [PATCH 2/4] btrfs-progs: fix a reression that "property" with -t option doesn't work

On 2016/03/14 21:23, David Sterba wrote: On Mon, Mar 14, 2016 at 09:12:36AM +0900, Satoru Takeuchi wrote: --- a/cmds-property.c +++ b/cmds-property.c @@ -379,9 +379,7 @@ static int cmd_property_get(int argc, char **argv) char *name = NULL; int types = 0; -

Re: [Hit return to continue]

Uh! Where that title came from. Sorry about the title. I am resending. -Anand On 03/16/2016 07:13 AM, Anand Jain wrote: For the matter of completeness we need to check if the device being scanned has features that are known to the kernel. As of now if it doesn't - the mount will fails, then

[PATCH v2] btrfs: block incompatible optional features at scan

For the matter of completeness we need to check if the device being scanned has features that are known to the kernel. As of now if it doesn't - the mount will fails, then what is the point in having those devices added to the btrfs_fs_devices list at device_list_add(). So block those devices at

Re: Incompat features: raid56 ... when creating a RAID6?

One more question: Any idea what happened here? Did I send this garbage? This was at the very end of your response mail... Yes looks like. As it was there when I read your posting. AndiN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±nÚß²)í…æèw*jg¬±¨¶‰šŽŠÝ¢j/êäz ¹Þ–Šà2ŠÞ™¨è­Ú&¢)ß¡«a¶Úþø

Re: Major HDD performance degradation on btrfs receive

On Tue, Mar 15, 2016 at 1:47 AM, Nazar Mokrynskyi wrote: > Some update since last time (few weeks ago). > > All filesystems are mounted with noatime, I've also added mounting > optimization - so there is no problem with remounting filesystem every time, > it is done only

[PATCH] btrfs: btrfs_assert fix coding style

Signed-off-by: Anand Jain --- fs/btrfs/ctree.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index c9fb7b9ca8a4..5b5002a242e4 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -4283,8 +4283,8 @@ static

[PATCH 1/2] btrfs-progs: Describe optarg of -m option in the manpage of receive

Signed-off-by: Satoru Takeuchi --- This patch can be applied to devel branch (commit: 4685a560811a) --- Documentation/btrfs-receive.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/btrfs-receive.asciidoc

Re: [PATCH v7 01/20] btrfs: dedup: Introduce dedup framework and its header

Nicholas D Steeves posted on Tue, 15 Mar 2016 18:08:41 -0400 as excerpted: > I'm not sure to what degree the following is a relevant concern, and I'm > guessing it's not, other than for laughs, but to me "dedupe" reads as > "de-dupe" or "undupe". While it functions as the inverse of the verb >

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Mon, Mar 14, 2016 at 01:00:13AM +0100, Henk Slager wrote: > On Sun, Mar 13, 2016 at 9:56 PM, Marc Haber > wrote: > > Yes, I want to keep the possibility to remove huge files from > > snapshots that shouldnt have been on a snapshotted volume in the first > > place

Re: [PATCH v2] btrfs: move btrfs_compression_type to compression.h

On 03/12/2016 12:11 AM, David Sterba wrote: On Thu, Mar 10, 2016 at 05:26:59PM +0800, Anand Jain wrote: So that its better organized. Signed-off-by: Anand Jain Reviewed-by: David Sterba Thanks. -- To unsubscribe from this list: send the line

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote: > The other question is: What is mounted on /media/tempdisk/ ? The "old" btrfs filesystem "ofanbtr", formerly 417 GB in size, now resized to 300 GB. Does it need to be umounted to be checked? > At least I think a check of the current

[PATCH 1/2] btrfs: cleaner_kthread() doesn't need explicit freeze

cleaner_kthread() is not marked freezable, and therefore calling try_to_freeze() in its context is a pointless no-op. In addition to that, as has been clearly demonstrated by 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly valid / legal for

[PATCH 2/2] btrfs: transaction_kthread() is not freezable

transaction_kthread() is calling try_to_freeze(), but that's just an expeinsive no-op given the fact that the thread is not marked freezable. After removing this, disk-io.c is now independent on freezer API. Signed-off-by: Jiri Kosina --- fs/btrfs/disk-io.c | 15

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Mon, Mar 14, 2016 at 09:39:51PM +0100, Henk Slager wrote: > >> BTW, I restored and mounted your 20160307-fanbtr-image: > >> > >> [266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732 > >> /dev/loop0 > >> [266203.734804] BTRFS info (device loop0): disk space caching is enabled >

[PATCH] btrfs/059: add a filter for btrfs compression property

From: Wang Xiaoguang btrfs/059.out should not be hardcoded to zlib, if compression method is lzo, this case will fail wrongly, so here add a filter. Signed-off-by: Wang Xiaoguang --- common/filter.btrfs | 4 tests/btrfs/059 |

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Mon, Mar 14, 2016 at 09:05:46PM +0100, Marc Haber wrote: > [10/509]mh@fan:~$ sudo btrfs check /media/tempdisk/ > Superblock bytenr is larger than device size > Couldn't open file system > [11/509]mh@fan:~$ After umounting and btrfs check the block device, things seem to be fine now:

Re: [PATCH 1/2] btrfs: cleaner_kthread() doesn't need explicit freeze

On Tue, 15 Mar 2016, Jiri Kosina wrote: > cleaner_kthread() is not marked freezable, and therefore calling > try_to_freeze() in its context is a pointless no-op. > > In addition to that, as has been clearly demonstrated by 80ad623edd2d > ("Revert "btrfs: clear PF_NOFREEZE in

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Tue, Mar 15, 2016 at 01:15:33PM +0100, Henk Slager wrote: > On Tue, Mar 15, 2016 at 8:16 AM, Marc Haber > wrote: > > On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote: > >> The other question is: What is mounted on /media/tempdisk/ ? > > > > The "old"

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Tue, Mar 15, 2016 at 8:16 AM, Marc Haber wrote: > On Tue, Mar 15, 2016 at 12:22:00AM +0100, Henk Slager wrote: >> The other question is: What is mounted on /media/tempdisk/ ? > > The "old" btrfs filesystem "ofanbtr", formerly 417 GB in size, now > resized to 300

Re: New file system with same issue

On 03/14/16 21:13, Marc Haber wrote: > On Mon, Mar 14, 2016 at 01:48:18PM +0100, Holger Hoffstätte wrote: >> did you ever try to clear the free-space cache via -o clear_cache >> on mount? > > This was not asked, and I didn't try. Since this is an encrypted root > filesystem, is it a workable way

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Tue, Mar 15, 2016 at 02:29:32PM +0100, Marc Haber wrote: > After umounting and btrfs check the block device, things seem to be > fine now But, umounting the btrfs seemed to trigger the following kernel traces: Mar 15 14:21:30 fan kernel: [92308.377104] [ cut here ] Mar

Re: New file system with same issue

On Tue, Mar 15, 2016 at 09:54:06AM -0400, Austin S. Hemmelgarn wrote: > On 2016-03-15 09:46, Marc Haber wrote: > >On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote: > >>On 03/14/16 21:13, Marc Haber wrote: > >>>Do I need to wait for clear_cache to finish, like until I see disk >

raid 10 recovery

Hey List, I have a raid10 on a rockstor machine (centOS based "4.3.3-1.el7.elrepo.x86_64“) where one drive threw SMART errors. So I tried to replace them. 1. mount in degraded worked 2. start replace with the new drive (btrfs replace start 4 /dev/sdf /mnt2/pool_name) worked fine first too 3.

Re: New file system with same issue

On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote: > On 03/14/16 21:13, Marc Haber wrote: > > Do I need to wait for clear_cache to finish, like until I see disk > > usage dropping? > > The cache isn't that big, so you won't see a huge drop. Just use the > disk normally for a few

[PULL] Btrfs cleanups for 4.6, part 2

Hi, a few more cleanups sent recently and some that I found in my inbox marked but not processed. Based on top of current integration. Please pull, thanks. The following changes since commit

Re: New file system with same issue

On 2016-03-15 09:46, Marc Haber wrote: On Tue, Mar 15, 2016 at 11:52:30AM +0100, Holger Hoffstätte wrote: On 03/14/16 21:13, Marc Haber wrote: Do I need to wait for clear_cache to finish, like until I see disk usage dropping? The cache isn't that big, so you won't see a huge drop. Just use

Re: [PULL] Btrfs cleanups for 4.6, part 2

On Tue, Mar 15, 2016 at 07:24:48AM -0700, Chris Mason wrote: > On Tue, Mar 15, 2016 at 02:50:14PM +0100, David Sterba wrote: > > Hi, > > > > a few more cleanups sent recently and some that I found in my inbox marked > > but > > not processed. Based on top of current integration. Please pull,

Re: [PULL] Btrfs cleanups for 4.6, part 2

On Tue, Mar 15, 2016 at 02:50:14PM +0100, David Sterba wrote: > Hi, > > a few more cleanups sent recently and some that I found in my inbox marked but > not processed. Based on top of current integration. Please pull, thanks. Thanks Dave, I'll get these pulled in and restart my long stress run.

Re: [PATCH 12/12] block: test fallocate for block devices

On Tue, Mar 15, 2016 at 02:41:48PM +1100, Dave Chinner wrote: > I think it's the right place to test it - we have all the > infrastructure available to do it (i.e. xfs_io and various block > devices) and we really need to make sure this stuff works, > especially if we start to write filesystem

Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

On Tue, Mar 15, 2016 at 2:42 PM, Marc Haber wrote: > On Tue, Mar 15, 2016 at 02:29:32PM +0100, Marc Haber wrote: >> After umounting and btrfs check the block device, things seem to be >> fine now > > But, umounting the btrfs seemed to trigger the following kernel

Re: Snapshots slowing system

pete posted on Mon, 14 Mar 2016 23:03:52 + as excerpted: > [Duncan wrote...] >>pete posted on Sat, 12 Mar 2016 13:01:17 + as excerpted: >>> >>> Subvolumes are mounted with the following options: >>> autodefrag,relatime,compress=lzo,subvol=> > >>That relatime (which is the default),

btrfs error

Hi all, I'm new to btrfs, and have just taken over management of this system; can anyone point me in the right direction with regard to the following error: BTRFS error (device sda3): unable to find ref byte nr 402100224 parent 0 root 256 owner 1 offset btrfs: Transaction aborted (error -2)

Re: raid 10 recovery

On Tue, Mar 15, 2016 at 3:40 PM, Marius Räsener wrote: > Hey List, > > I have a raid10 on a rockstor machine (centOS based > "4.3.3-1.el7.elrepo.x86_64“) where one drive threw SMART errors. > > So I tried to replace them. > > 1. mount in degraded worked > 2. start replace

[PATCH 2/2 v2] fix a regression that "property" with -t option doesn't work

"property" is considered as working without any options from the following commit. commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed") However, we can pass -t option to this command. * actual result == $ ./btrfs prop list -t f

Re: Major HDD performance degradation on btrfs receive

Maybe a starting point. https://oss.oracle.com/~mason/seekwatcher/ This shows write patterns, not current state fragmentation. So it's less useful for what you're asking, and more useful for what I was suggesting as a batched snapshot delete strategy. Chris Murphy -- To unsubscribe from this

Re: Major HDD performance degradation on btrfs receive

Sounds like a really good idea! I'll try to implement in in my backup tool, but it might take some time to see real benefit from it (or no benefit:)). Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora:naza...@diaspora.mokrynskyi.com Tox:

[PATCH 2/2 v2] btrfs-progs: Fix a regression that "property" with -t option doesn't work

Sorry, I forgot to add "btrfs-progs: " in the subject line. --- "property" is considered as working without any options from the following commit. commit 176aeca9a148 ("btrfs-progs: add getopt stubs where needed") However, we can pass -t option to this command. * actual result

Re: Major HDD performance degradation on btrfs receive

It could also be that the disk is bit older and has or is starting to use its spare sectors. I do not really think HDD is that old. I've got it brand new less than year ago. Here is smartctl output: nazar-pc@nazar-pc ~> sudo smartctl -a /dev/sda smartctl 6.5 2016-01-24 r4214

Re: [PATCH] btrfs: btrfs_assert fix coding style

Ignore. NACK. Thanks, Anand On 03/16/2016 08:55 AM, Anand Jain wrote: Signed-off-by: Anand Jain --- fs/btrfs/ctree.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index c9fb7b9ca8a4..5b5002a242e4 100644

Why we always balance system chunk alone with metadata?

Hi, During debugging a bug related to balancing metadata chunk, we found that if we specify -m option for "btrfs balance", it will always balance system chunk too. cmds-balance.c: --- /* * allow -s only under --force, otherwise do with system chunks * the same thing

bad metadata [125501440, 125517824) crossing stripe boundary

I was running btrfsck today and got many of such errors: bad metadata [125501440, 125517824) crossing stripe boundary bad metadata [131334144, 131350528) crossing stripe boundary bad metadata [142999552, 143015936) crossing stripe boundary bad metadata [153944064, 153960448) crossing stripe

Re: Major HDD performance degradation on btrfs receive

Very simplistically: visualizing Btrfs writes without file deletion, it's a contiguous write. There isn't much scatter, even accounting for metadata and data chunk writes happening in slightly different regions of platter space. (I'm thinking this slow down happens overwhelmingly on HDDs.) If