[PATCH v2 2/2] btrfs: test decompression in the middle of large extents

From: Omar Sandoval This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()". It fails for zlib on v4.10-rc[1-7]. Signed-off-by: Omar Sandoval --- Changed from v1: - Remove from quick group - Handle compress features in sysfs generically - Require

[PATCH v2 1/2] common/rc: remove unnecessary cat in _ddt

From: Omar Sandoval Signed-off-by: Omar Sandoval --- Identical to v1 common/rc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/rc b/common/rc index 76515e2b..6304d690 100644 --- a/common/rc +++ b/common/rc @@ -2417,7 +2417,7 @@ _die()

Re: [PATCH 2/2] btrfs: test decompression in the middle of large extents

On Fri, Feb 17, 2017 at 01:58:49PM +0800, Eryu Guan wrote: > On Thu, Feb 16, 2017 at 06:32:49PM -0800, Omar Sandoval wrote: > > From: Omar Sandoval > > > > This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()". > > It fails for zlib on v4.10-rc[1-7]. > > > >

Re: [PATCH 2/2] btrfs: test decompression in the middle of large extents

On Thu, Feb 16, 2017 at 06:32:49PM -0800, Omar Sandoval wrote: > From: Omar Sandoval > > This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()". > It fails for zlib on v4.10-rc[1-7]. > > Signed-off-by: Omar Sandoval > --- > This runs in <60

Re: [PATCH 00/10] Qgroup fixes for kdave/for-next-20161125 branch

At 02/17/2017 09:04 AM, Qu Wenruo wrote: Hi David, Any update about this patchset? As I see a lot of cleanups related to qgroup is submitted to mail list, should I rebase this patchset to handle the conflicts using your latest for-next? Or should I rebase them only after cleanups got merged

[PATCH 2/2] btrfs: test decompression in the middle of large extents

From: Omar Sandoval This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()". It fails for zlib on v4.10-rc[1-7]. Signed-off-by: Omar Sandoval --- This runs in <60 seconds on my test VM, which I think qualifies for the quick group? common/btrfs

[PATCH 1/2] common/rc: remove unnecessary cat in _ddt

From: Omar Sandoval Signed-off-by: Omar Sandoval --- common/rc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/rc b/common/rc index 76515e2b..6304d690 100644 --- a/common/rc +++ b/common/rc @@ -2417,7 +2417,7 @@ _die() # convert

Re: [PATCH 00/10] Qgroup fixes for kdave/for-next-20161125 branch

Hi David, Any update about this patchset? As I see a lot of cleanups related to qgroup is submitted to mail list, should I rebase this patchset to handle the conflicts using your latest for-next? Or should I rebase them only after cleanups got merged into mainline? Thanks, Qu At

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

At 02/16/2017 06:03 PM, Filipe Manana wrote: On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo wrote: At 02/15/2017 11:59 PM, Filipe Manana wrote: On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo wrote: If run btrfs/125 with nospace_cache or

Re: FS gives kernel UPS on attempt to create snapshot and after running balance it's unmountable.

Thanks Qu, Just before I’ll go and accidentally mess up this FS more - I’ve mentioned originally that this problem started with FS not being able to create a snapshot ( it would get remounted RO automatically ) for about a month, and when I’ve realised that there is a problem like that I’ve

[PATCH v2] btrfs-progs: RAID5:Inject data stripe corruption and verify scrub fixes it.

Test script to create file with specific data-stripe layout and pre-computed parity values. Inject corruption into data-stripe and verify scrubbing process fixes corrupted block. It also attempts to validate the corresponding parity block value. Signed-off-by: Lakshmipathi.G

Re: [PATCH v2] btrfs-progs: misc-tests: Superblock corruption and recovery using backup.

On Thu, Feb 16, 2017 at 09:05:02AM +0800, Qu Wenruo wrote: > > > At 02/16/2017 04:50 AM, Lakshmipathi.G wrote: > >Signed-off-by: Lakshmipathi.G > > Looks good to me. > > Reviewed by: Qu Wenruo > > BTW, it would be better to have some

[PATCH v3] btrfs-progs: misc-tests: Superblock corruption and recovery using backup.

Test script to recover damaged primary superblock using backup superblock. Signed-off-by: Lakshmipathi.G --- .../019-fix-superblock-corruption/test.sh | 36 ++ 1 file changed, 36 insertions(+) create mode 100755

Re: man filesystems(5) doesn't contain Btrfs

On 2017-02-16 15:36, Chris Murphy wrote: Hi, This man page contains a list for pretty much every other file system, with a oneliner description: ext4, XFS is in there, and even NTFS, but not Btrfs. Also, /etc/filesystems doesn't contain Btrfs. Anyone know if either, or both, ought to contain

Re: Way to force allocation of more metadata?

On 2017-02-16 15:13, E V wrote: It would be nice if there was an easy way to tell btrfs to allocate another metadata chunk. For example, the below fs is full due to exhausted metadata: Device size:1013.28GiB Device allocated: 1013.28GiB Device unallocated:

man filesystems(5) doesn't contain Btrfs

Hi, This man page contains a list for pretty much every other file system, with a oneliner description: ext4, XFS is in there, and even NTFS, but not Btrfs. Also, /etc/filesystems doesn't contain Btrfs. Anyone know if either, or both, ought to contain an entry for Btrfs? -- Chris Murphy -- To

Way to force allocation of more metadata?

It would be nice if there was an easy way to tell btrfs to allocate another metadata chunk. For example, the below fs is full due to exhausted metadata: Device size:1013.28GiB Device allocated: 1013.28GiB Device unallocated:2.00MiB Device

Re: Device ID issue on btrfs

On 2/16/17 1:23 PM, Goffredo Baroncelli wrote: > On 2017-02-16 14:00, Ilan Schwarts wrote: >> Hi, >> Found the solution at: https://patchwork.kernel.org/patch/2825842/ > > The patches below provided by suse seem more general > > >

Re: Device ID issue on btrfs

On 2017-02-16 14:00, Ilan Schwarts wrote: > Hi, > Found the solution at: https://patchwork.kernel.org/patch/2825842/ The patches below provided by suse seem more general http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/vfs-add-super_operations-get_inode_dev

Re: [PATCH 0/8] btrfs: cleanup patches

On Wed, Feb 15, 2017 at 04:28:26PM -0500, je...@suse.com wrote: > From: Jeff Mahoney > > Hi all - > > Here's another around of cleanup patches. The first 7 cleanup API > blemishes with unused arguments and/or root -> fs_info conversion. The > last converts the pr_debug in

Re: [PATCH] btrfs-progs: RAID5:Inject data stripe corruption and verify scrub fixes it.

On Thu, Feb 16, 2017 at 09:12:31AM +0800, Qu Wenruo wrote: > > > At 02/16/2017 04:56 AM, Lakshmipathi.G wrote: > >On Wed, Feb 15, 2017 at 05:29:33PM +0800, Qu Wenruo wrote: > >> > >> > >>At 02/15/2017 05:03 PM, Lakshmipathi.G wrote: > >>>Signed-off-by: Lakshmipathi.G

Re: How to dump/find parity of RAID-5 file?

On Wed, Feb 15, 2017 at 07:24:55PM +0100, Goffredo Baroncelli wrote: > The chunk-tree maps the logical address [145096704...145096704+134217728) > [size=128MB] to the physical ones > devid3 : [6368..6368+67108864) [size=64MB] > devid1 : [6368..6368+67108864)

Re: 4.9/4.10 Experiences

On Thu, Feb 16, 2017 at 01:37:53PM +0200, Imran Geriskovan wrote: > What are your experiences for btrfs regarding 4.10 and 4.11 kernels? > I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for > a very typical single disk setup. Are they reasonably stable/good > enough for this case?

Opps.. Should be 4.9/4.10 Experiences

Opps.. I mean 4.9/4.10 Experiences On 2/16/17, Imran Geriskovan wrote: > What are your experiences for btrfs regarding 4.10 and 4.11 kernels? > I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for > a very typical single disk setup. Are they reasonably

Re: 4.10/4.11 Experiences

What are your experiences for btrfs regarding 4.10 and 4.11 kernels? I'm still on 4.8.x. I'd be happy to hear from anyone using 4.1x for a very typical single disk setup. Are they reasonably stable/good enough for this case? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs"

4.10/4.11 Experiences

-- 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

[GIT PULL] Btrfs fixes and improvements for 4.11

From: Filipe Manana Hi Chris. Please consider the following changes for the 4.11 merge window. This time there is nothing particularly outstanding when compared to the usual set of bug fixes. These are mostly fixes for send and the no-holes feature introduced in 3.14. Test

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

On Wed, Feb 15, 2017 at 2:43 AM, Qu Wenruo wrote: > Just as Filipe pointed out, the most time consuming parts of qgroup are > btrfs_qgroup_account_extents() and > btrfs_qgroup_prepare_account_extents(). > Which both call btrfs_find_all_roots() to get old_roots and

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Thu, Feb 16, 2017 at 12:39 AM, Qu Wenruo wrote: > > > At 02/15/2017 11:59 PM, Filipe Manana wrote: >> >> On Wed, Feb 15, 2017 at 8:49 AM, Qu Wenruo >> wrote: >>> >>> If run btrfs/125 with nospace_cache or space_cache=v2 mount option, >>> btrfs

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

At 02/16/2017 04:56 PM, Nikolay Borisov wrote: On 16.02.2017 10:50, Qu Wenruo wrote: At 02/16/2017 04:45 PM, Nikolay Borisov wrote: Just a minor nit. On 15.02.2017 04:43, Qu Wenruo wrote: Just as Filipe pointed out, the most time consuming parts of qgroup are

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

On 16.02.2017 10:50, Qu Wenruo wrote: > > > At 02/16/2017 04:45 PM, Nikolay Borisov wrote: >> Just a minor nit. >> >> On 15.02.2017 04:43, Qu Wenruo wrote: >>> Just as Filipe pointed out, the most time consuming parts of qgroup are >>> btrfs_qgroup_account_extents() and >>>

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

At 02/16/2017 04:45 PM, Nikolay Borisov wrote: Just a minor nit. On 15.02.2017 04:43, Qu Wenruo wrote: Just as Filipe pointed out, the most time consuming parts of qgroup are btrfs_qgroup_account_extents() and btrfs_qgroup_prepare_account_extents(). Which both call btrfs_find_all_roots() to

Re: [PATCH v2] btrfs: qgroup: Move half of the qgroup accounting time out of commit trans

Just a minor nit. On 15.02.2017 04:43, Qu Wenruo wrote: > Just as Filipe pointed out, the most time consuming parts of qgroup are > btrfs_qgroup_account_extents() and > btrfs_qgroup_prepare_account_extents(). > Which both call btrfs_find_all_roots() to get old_roots and new_roots > ulist. > >