Re: [Bug] btrfs-progs v4.3.1, mkfs.btrfs manpage, profiles table missing raid1

On Fri, Nov 20, 2015 at 11:05:44AM +, Duncan wrote: > As in the title... > > The btrfs-progs v4.3.1 mkfs.btrfs manpage has a quite nice profiles table > listing the various profiles, single/dup/raid0/raid10/raid5/raid6. > > It's missing raid1. =:^( Oh, that's not intentional, I'll fix it.

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Mon, 2015-11-23 at 09:10 +0800, Qu Wenruo wrote: > Also, you won't want compiler to do extra optimization I did the following: $ export CFLAGS="-g -O0 -Wall -D_FORTIFY_SOURCE=2" $ ./configure --disable-convert --disable-documentation So if you want me to get rid of _FORTIFY_SOURCE, please

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On 2015-11-23 12:56, David Sterba wrote: On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs be compatible w any set of older/newer kernels. So far mkfs.btrfs and btrfs-convert sets the default features, for eg,

Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors

On 2015-11-22 16:59, Nils Steinger wrote: Hi, I recently ran into a problem while trying to back up some of my btrfs subvolumes over the network: `btrfs send` works flawlessly on snapshots of most subvolumes, but keeps failing on snapshots of a certain subvolume — always after sending 15 GiB:

Re: btrfs: poor performance on deleting many large files

On 2015-11-22 20:43, Mitch Fossen wrote: Hi all, I have a btrfs setup of 4x2TB HDDs for /home in btrfs RAID0 on Ubuntu 15.10 (kernel 4.2) and btrfs-progs 4.3.1. Root is on a separate SSD also running btrfs. About 6 people use it via ssh and run simulations. One of these simulations generates a

[PATCH v2 2/5] btrfs-progs: add framework to check features supported by sysfs

This adds a framework to check the /sys/fs/btrfs/features for the list of supported features by the btrfs kernel. Which I hope by using it the mkfs and btrfs-convert could tune to set features as supported by the running kernel. Signed-off-by: Anand Jain --- utils.c | 66

[PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs be compatible w any set of older/newer kernels. So far mkfs.btrfs and btrfs-convert sets the default features, for eg, skinny-metadata even if the running kernel does not supports it, and so the mount fails on the running.

[PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

Mkfs from latest btrfs-progs will enable latest default features, and if the kernel is down-rev and does not support a latest default feature then mount fails, as expected. This patch disables default features based on the running kernel. Signed-off-by: Anand Jain --- v2:

[PATCH 5/5] btrfs-progs: add warning when we fail to read sysfs or version

Signed-off-by: Anand Jain --- btrfs-convert.c | 10 +- mkfs.c | 8 +++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/btrfs-convert.c b/btrfs-convert.c index 52ea12a..b0a998b 100644 --- a/btrfs-convert.c +++ b/btrfs-convert.c @@

[PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features

In the newer kernel, supported kernel features can be known from /sys/fs/btrfs/features however this interface was introduced only after 3.14, and most the incompatible FS features were introduce before 3.14. This patch proposes to maintain kernel version against the feature list, and so that

[PATCH v2 4/5] btrfs-progs: kernel based default features for btrfs-convert

btrfs-convert convert FS with latest default features enabled, and if the kernel is down-rev and does not support a latest feature then mount fails, as expected. This patch disables default features based on the running kernel. Signed-off-by: Anand Jain --- v2: Check if

Re: shall distros run btrfsck on boot?

On Tue, Nov 24, 2015 at 12:02 PM, Christoph Anton Mitterer wrote: > Hey. > > Short question since that came up on debian-devel. > > Now that btrfs check get's more and more useful, are the developers > going to recommend running it periodically on boot (of course that >

Re: shall distros run btrfsck on boot?

On 11/23/15 10:35 PM, Duncan wrote: > Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as > excerpted: > >> Hey. >> >> Short question since that came up on debian-devel. >> >> Now that btrfs check get's more and more useful, are the developers >> going to recommend running it

Re: shall distros run btrfsck on boot?

On Tue, 2015-11-24 at 04:35 +, Duncan wrote: > I'm a list regular and btrfs user, not a dev, but all the indications > continue to point to _not_ running it automatically at boot, nobody > even > _suggesting_ otherwise. Sure, I just asked because maybe that would have just been an

[PATCH] btrfs-progs: fsck: Fix a false alert where extent record has wrong metadata flag

In process_extent_item(), it gives 'metadata' initial value 0, but for non-skinny-metadata case, metadata extent can't be judged just from key type and it forgot that case. This causes a lot of false alert in non-skinny-metadata filesystem. Fix it by set correct metadata value before calling

Re: shall distros run btrfsck on boot?

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as excerpted: > Hey. > > Short question since that came up on debian-devel. > > Now that btrfs check get's more and more useful, are the developers > going to recommend running it periodically on boot (of course that > wouldn't

subvols and parents - how?

Hey. I'd have a, mainly administrative, question. When I use subvolumes than these have always a parent subvolume (except ID5), so I can basically decide between two ways: a) make child subvolumes, e.g. 5 | +-root   (=subvol, mountpoint /)   +-boot/   +-root/   +-lib/   +-home/ (=subvolume) and

Re: Weird space issues (with more than plenty left; over 100GiB free on 465.63GiB RAID partition)

Steven Hoff posted on Mon, 23 Nov 2015 19:31:43 -0700 as excerpted: > BTRFS Community, > > I seem to be having a bit of an issue. A comment on > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22 No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space > suggested

Re: shall distros run btrfsck on boot?

Christoph Anton Mitterer wrote on 2015/11/24 05:43 +0100: On Tue, 2015-11-24 at 04:35 +, Duncan wrote: I'm a list regular and btrfs user, not a dev, but all the indications continue to point to _not_ running it automatically at boot, nobody even _suggesting_ otherwise. Sure, I just

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/24 04:02 +0100: On Tue, 2015-11-24 at 10:54 +0800, Qu Wenruo wrote: And it would be even better if you want to be a lab mouse for incoming fixing patches. Sure,.. if I get some cheese... and it would be great if you could give me patches that apply

Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors

Nils Steinger posted on Mon, 23 Nov 2015 22:10:12 +0100 as excerpted: > Do we anything about what might cause a filesystem to enter a state > which `send` chokes on? > I've only seen a small sample of the corrupted files before growing > tired of the process and just recreating the whole thing,

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

Austin S Hemmelgarn posted on Mon, 23 Nov 2015 15:14:44 -0500 as excerpted: >> A remaining option should override the 'running' behaviour and pick the >> latest mkfs options. Naming it 'defaults' sounds a bit ambiguous so the >> name is yet to be determined. > Maybe something like 'recommended'

Re: shall distros run btrfsck on boot?

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:43:31 +0100 as excerpted: [Duncan wrote...] >> The btrfs kernel code itself detects and often >> corrects many problems, and btrfs check is simply not recommended for >> automatic at-boot scheduling -- if the kernel code can't fix it without

Re: shall distros run btrfsck on boot?

Duncan posted on Tue, 24 Nov 2015 06:46:18 + as excerpted: > That wouldn't be entirely uncommon, because as Eric mentions, btrfs > check is intended to be thorough, where the kernel mount-time check is > intended to be fast. > > But of course, as Eric also mentions, that's yet another reason

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/23 19:12 +0100: On Mon, 2015-11-23 at 09:10 +0800, Qu Wenruo wrote: Also, you won't want compiler to do extra optimization I did the following: $ export CFLAGS="-g -O0 -Wall -D_FORTIFY_SOURCE=2" Wow, I didn't ever know it's possible to override

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

David Sterba wrote on 2015/11/23 18:33 +0100: On Fri, Nov 20, 2015 at 11:24:04AM +0800, Qu Wenruo wrote: Here comes the 1st version of btrfs-convert rework. Any test is welcomed, and it can already pass the convert test from btrfs-progs. (Since the test doesn't test rollback function) I

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/24 02:53 +0100: On Tue, 2015-11-24 at 08:46 +0800, Qu Wenruo wrote: But there are also some other places like line 4411, 4394 and 4387. Ah of course, I didn't have a look for further places $ grep -n "rec->wrong_chunk_type = 1" cmds-check.c

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Tue, 2015-11-24 at 08:46 +0800, Qu Wenruo wrote: > But there are also some other places like line 4411, 4394 and 4387. Ah of course, I didn't have a look for further places $ grep -n "rec->wrong_chunk_type = 1" cmds-check.c 4387: rec->wrong_chunk_type = 1; 4394:

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Christoph Anton Mitterer wrote on 2015/11/24 03:48 +0100: On Tue, 2015-11-24 at 10:09 +0800, Qu Wenruo wrote: I'll dig further to see what's causing the problem. I guess you'd prefer if I keep the fs for later verification? That would be the best. And it would be even better if you want

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Tue, 2015-11-24 at 10:54 +0800, Qu Wenruo wrote: > And it would be even better if you want to be a lab mouse for > incoming fixing patches. Sure,.. if I get some cheese... and it would be great if you could give me patches that apply to 4.3. > (It won't hurt nor destroy your data) wouldn't  

Weird space issues (with more than plenty left; over 100GiB free on 465.63GiB RAID partition)

BTRFS Community, I seem to be having a bit of an issue. A comment on https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space suggested reporting this to the mailing list. Issue: BTRFS claims to be running out of

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Tue, 2015-11-24 at 10:09 +0800, Qu Wenruo wrote: > I'll dig further to see what's causing the problem. I guess you'd prefer if I keep the fs for later verification? > Thanks for all the debug info, it really helps a lot! Well thanks for your efforts as well :) Chris. smime.p7s Description:

shall distros run btrfsck on boot?

Hey. Short question since that came up on debian-devel. Now that btrfs check get's more and more useful, are the developers going to recommend running it periodically on boot (of course that wouldn't work right now, as it would *always* check)? Plus... is btrfs check (without any arguments)

Re: [PATCH 2/2] generic/15[78]: fix error messages in the golden output

On Mon, Nov 23, 2015 at 01:25:33PM -0800, Darrick J. Wong wrote: > > Shouldn't these be Invalid argument just like the > > to a device case above or the clone case? > > I was trying to mirror the behavior of reflink, which spits out > EOPNOTSUPP when the destination isn't a regular file and

[PATCH] Btrfs: fix race between cleaner kthread and space cache writeout

From: Filipe Manana When a block group becomes unused and the cleaner kthread is currently running, we can end up getting the current transaction aborted with error -ENOENT when we try to commit the transaction, leading to the following trace: [59779.258768] WARNING: CPU: 3

Re: [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

On 2015-11-23 10:57, Christoph Anton Mitterer wrote: Hey. On Mon, 2015-11-23 at 20:56 +0800, Anand Jain wrote: This patch disables default features based on the running kernel. Not sure if that's very realistic in practise (most people will have some distro, whose btrfsprogs version probably

Re: [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

On Mon, 2015-11-23 at 11:05 -0500, Austin S Hemmelgarn wrote: > I would find it useful if btrfs gives a warning if it creates a > > filesystem which (because unsupported in the current kernel) lacks > > features which are considered default by then. > It should give a warning if the user requests

Re: [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

On 2015-11-23 11:14, Christoph Anton Mitterer wrote: On Mon, 2015-11-23 at 11:05 -0500, Austin S Hemmelgarn wrote: I would find it useful if btrfs gives a warning if it creates a filesystem which (because unsupported in the current kernel) lacks features which are considered default by then.

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: > Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs > be compatible w any set of older/newer kernels. > > So far mkfs.btrfs and btrfs-convert sets the default features, for eg, > skinny-metadata even if the

Re: [PATCH 00/25] Btrfs-convert rework to support native separate

On Fri, Nov 20, 2015 at 11:24:04AM +0800, Qu Wenruo wrote: > Here comes the 1st version of btrfs-convert rework. > Any test is welcomed, and it can already pass the convert test from > btrfs-progs. (Since the test doesn't test rollback function) I went through the patches, looks mostly ok akin to

Re: [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

Hey. On Mon, 2015-11-23 at 20:56 +0800, Anand Jain wrote: > This patch disables default features based on the running kernel. Not sure if that's very realistic in practise (most people will have some distro, whose btrfsprogs version probably matches the kernel), but purely from the end-user PoV:

Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors

On Mon, Nov 23, 2015 at 05:49:05AM +, Duncan wrote: > Btrfs scrub? Why do you believe it will detect/fix the problem? I was under the impression that btrfs scrub would detect all kinds of inconsistencies (not just data-checksum mismatches), including whatever caused btrfs send to fail.

Re: [PATCH 2/2] generic/15[78]: fix error messages in the golden output

On Sat, Nov 21, 2015 at 10:06:44AM -0800, Christoph Hellwig wrote: > > --- a/tests/generic/158.out > > +++ b/tests/generic/158.out > > Try to dedupe a device > > -XFS_IOC_FILE_EXTENT_SAME: Permission denied > > +XFS_IOC_FILE_EXTENT_SAME: Invalid argument > > Try to dedupe to a dir > >