Re: [PATCH v2 1/4] btrfs-progs: rename raid6.c to raid56.c

Hi, 1-4 applied, thanks. -- 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

Re: [PATCH] btrfs-progs: Fix stack overflow for checking qgroup on tree reloc tree

On Thu, Oct 06, 2016 at 05:13:32PM +0800, Qu Wenruo wrote: > For tree reloc tree whose level is >= 2, the root node's parent will > point to itself. > In this case it will make btrfsck overflow its stack and cause segfault. > > While for tree reloc tree, it doesn't affect qgroup and kernel can >

Re: [PATCH 2/2] btrfs-progs: fsck-test: Add image for quota verify stack overflow

On Fri, Oct 07, 2016 at 03:23:00PM +0800, Qu Wenruo wrote: > +for img in $(find . \( -iname '*.img' -o \ > + -iname '*.img.xz' -o\ > + -iname '*.raw' -o \ > + -iname '*.raw.xz' \) | sort) > +do > + image=$(extract_image

Re: [PATCH v2 0/4] Btrfs-convert: Add support to copy common inode flags

Hi, patches merged to devel, thanks. I made a few minor adjustments, not bothering you with them. On Tue, Oct 11, 2016 at 10:44:42AM +0800, Qu Wenruo wrote: > Branch can be fetched from: > https://github.com/adam900710/btrfs-progs/tree/convert_inode_flags I can pull the branches from you,

[PATCH] btrfs-progs: fix build for programs including ioctl.h

This was reported when docker failed to build against btrfs-progs v4.8.1. It includes ioctl.h which now calls BUILD_ASSERT(), which is defined in kerncompat.h, which was not included in the ioctl.h header file. Signed-off-by: Eric Sandeen --- diff --git a/ioctl.h b/ioctl.h

Re: [PATCH 1/2] btrfs-progs: fsck: Add support to clear v1 free space cache.

On Thu, Oct 13, 2016 at 05:22:26PM +0800, Qu Wenruo wrote: > Kernel clear_cache mount option will only rebuilt free space cache if > used space of that chunk has changed. > > So it won't ensure any corrupted free space cache get cleared. > > So add a new option "--clear-space-cache v1|v2" to

Re: btrfs bio linked list corruption.

On Wed, Oct 12, 2016 at 10:42:46AM -0400, Chris Mason wrote: > On 10/12/2016 10:40 AM, Dave Jones wrote: > > On Wed, Oct 12, 2016 at 09:47:17AM -0400, Dave Jones wrote: > > > On Tue, Oct 11, 2016 at 11:54:09AM -0400, Chris Mason wrote: > > > > > > > > > > > > On 10/11/2016 10:45 AM,

Re: btrfs bio linked list corruption.

On 10/13/2016 02:16 PM, Dave Jones wrote: On Wed, Oct 12, 2016 at 10:42:46AM -0400, Chris Mason wrote: > On 10/12/2016 10:40 AM, Dave Jones wrote: > > On Wed, Oct 12, 2016 at 09:47:17AM -0400, Dave Jones wrote: > > > On Tue, Oct 11, 2016 at 11:54:09AM -0400, Chris Mason wrote: > > > > >

Re: RAID system with adaption to changed number of disks

On Thu, Oct 13, 2016 at 08:35:02AM +0800, Qu Wenruo wrote: > At 10/13/2016 01:19 AM, Zygo Blaxell wrote: > >On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote: > >>True, but if we ignore parity, we'd find that, RAID5 is just RAID0. > > > >Degraded RAID5 is not RAID0. RAID5 has strict

Re: btrfs bio linked list corruption.

On Thu, Oct 13, 2016 at 05:18:46PM -0400, Chris Mason wrote: > > > > WARNING: CPU: 1 PID: 21706 at fs/btrfs/transaction.c:489 > > start_transaction+0x40a/0x440 [btrfs] > > > > CPU: 1 PID: 21706 Comm: trinity-c16 Not tainted 4.8.0-think+ #14 > > > > c900019076a8 b731ff3c

Copy BTRFS volume to another BTRFS volume including subvolumes and snapshots

Hi, I'm using OpenSUSE on a btrfs volume spanning 2 disks (set as raid1 for both metadata and data), no separate /home partition. The distro loves to create dozens of subvolumes for various things and makes snapshots, see: alby@openSUSE-xeon:~> sudo btrfs subvolume list / ID 257 gen 394 top

Re: Incremental send robustness question

Sean Greenslade posted on Wed, 12 Oct 2016 18:29:55 -0400 as excerpted: > Hi, all. I have a question about a backup plan I have involving > send/receive. As far as I can tell, there's no way to to resume a send > that has been interrupted. In this case, my interruption comes from an > overbearing

Re: [PATCH v2 0/4] Btrfs-convert: Add support to copy common inode flags

At 10/13/2016 10:15 PM, David Sterba wrote: Hi, patches merged to devel, thanks. I made a few minor adjustments, not bothering you with them. Thanks for all your work. Now I can just rebase my scrub work to devel branch. On Tue, Oct 11, 2016 at 10:44:42AM +0800, Qu Wenruo wrote: Branch

Re: RAID system with adaption to changed number of disks

At 10/14/2016 05:03 AM, Zygo Blaxell wrote: On Thu, Oct 13, 2016 at 08:35:02AM +0800, Qu Wenruo wrote: At 10/13/2016 01:19 AM, Zygo Blaxell wrote: On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote: True, but if we ignore parity, we'd find that, RAID5 is just RAID0. Degraded RAID5

Re: [PATCH 2/2] btrfs-progs: fsck-test: Add image for quota verify stack overflow

At 10/13/2016 10:29 PM, David Sterba wrote: On Fri, Oct 07, 2016 at 03:23:00PM +0800, Qu Wenruo wrote: +for img in $(find . \( -iname '*.img' -o \ + -iname '*.img.xz' -o\ + -iname '*.raw' -o \ + -iname

Re: [PATCH 1/2] btrfs-progs: fsck: Add support to clear v1 free space cache.

At 10/14/2016 01:44 AM, Omar Sandoval wrote: On Thu, Oct 13, 2016 at 05:22:26PM +0800, Qu Wenruo wrote: Kernel clear_cache mount option will only rebuilt free space cache if used space of that chunk has changed. So it won't ensure any corrupted free space cache get cleared. So add a new

Mein lieber Freund,

Mein lieber Freund, Ich moechte mich erstmals gerne vorstellen. Mein Name ist Herr Ortega Navas die persoenliche Investment Berater und Vermoegensverwalterin meines verstorbenen Mandanten, der ihre familienname tragt. Er war als privater Geschaeftsmann im internationalen Bereich taetig. Im

Re: Unable to rescue RAID5

Hiroshi Honda posted on Thu, 13 Oct 2016 10:28:19 +0900 as excerpted: > I am using Btrfs RAID5 with 10x4T disks. > Around 2 weeks ago, one disk of it was taking long time when read and > write. > So, I tried replace the disk with new disk by replace command ( btrfs > replace ... ). > But, it

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On Thu, Oct 13, 2016 at 1:37 AM, Liu Bo wrote: > On Wed, Oct 12, 2016 at 10:23:52PM +0100, Filipe Manana wrote: >> On Tue, Sep 6, 2016 at 10:51 PM, Liu Bo wrote: >> > Hi Filipe, >> > >> > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote:

[PATCH 1/2] btrfs-progs: fsck: Add support to clear v1 free space cache.

Kernel clear_cache mount option will only rebuilt free space cache if used space of that chunk has changed. So it won't ensure any corrupted free space cache get cleared. So add a new option "--clear-space-cache v1|v2" to btrfsck, to completely wipe out free space cache. So kernel won't complain

Re: Btrfs progs build fails for 4.8

At 10/13/2016 01:26 AM, David Sterba wrote: On Wed, Oct 12, 2016 at 10:01:27PM +0800, Qu Wenruo wrote: On 10/12/2016 09:58 PM, Abhay Sachan wrote: Hi, I tried building latest btrfs progs on CentOS 6, "./configure" failed with the error: checking for FIEMAP_EXTENT_SHARED defined in

[PATCH 2/2] btrfs-progs: fsck-tests: Check if clear space cache works

Add test case to check the basic function of --clear-space-cache. Signed-off-by: Qu Wenruo --- tests/fsck-tests/024-clear-space-cache/test.sh | 55 ++ 1 file changed, 55 insertions(+) create mode 100755

Re: [PATCH v2 2/3] btrfs-progs: receive: Introduce option to exam and dump send stream

Hi David, Any updates? If you're busy on these fix, I could fix these problem and send a new version. Thanks, Qu At 09/08/2016 05:56 PM, David Sterba wrote: On Thu, Sep 08, 2016 at 11:42:29AM +0200, David Sterba wrote: On Wed, Sep 07, 2016 at 08:29:34AM +0800, Qu Wenruo wrote: @@

Re: [PATCH v1] btrfs: Avoid reading out unnecessary extent tree blocks when mounting

At 10/12/2016 10:55 PM, David Sterba wrote: On Thu, Jul 07, 2016 at 10:11:59AM +0800, Qu Wenruo wrote: Btrfs_read_block_groups() function is the most time consuming function if the fs is large and filled with small extents. For a btrfs filled with 100,000,000 16K sized files, mount the fs

Re: [PATCH 1/4] btrfs: add test for an incremental send don't skip overwrite ref for inode 256

On Thu, Oct 13, 2016 at 12:04 PM, robbieko wrote: > From: Robbie Ko > > Test that an incremental send operation does not skip overwrite ref > for inode 256, it's always exist. Tests should have a description that non-developers can understand (like

[PATCH v2] btrfs: introduce priority based delalloc shrink mechanism

Since commit b02441999efcc6152b87cd58e7970bb7843f76cf, we don't wait all ordered extents, but I run into some enospc errors when doing large file create and delete tests, it's because shrink_delalloc() does not write enough delalloc bytes and wait them finished: From: Miao Xie

Re: Incremental send robustness question

On 13/10/16 00:47, Sean Greenslade wrote: > I may just end up doing that. Hugo's responce gave me some crazy ideas > involving a custom build of split that waits for a command after each > output file fills, which would of course require an equally weird build > of cat that would stall the pipe

[PATCH 3/4] btrfs: add test for an incremental send add gen check in did_overwrite_ref

From: Robbie Ko There a some case, the old gen directory can not have new data to write, can not cause overwitre ref, except inode 256. This test exercises scenarios used to fail in btrfs and are fixed by the following patches for the linux kernel: "Btrfs: incremental

[PATCH 0/4] Btrfs: add serval test case for incremental send

From: Robbie Ko Patch for test btrfs incremental send. Robbie Ko (4): btrfs: add test for an incremental send don't skip overwrite ref for inode 256 btrfs: add test for an incremental send add gen for is_waiting_for_rm when some corner case btrfs: add test

[PATCH 2/4] btrfs: add test for an incremental send add gen for is_waiting_for_rm when some corner case

From: Robbie Ko There a one case for old_gen waiting_for_rm, but new_gen use get_cur_path with the same inode. This test exercises scenarios used to fail in btrfs and are fixed by the following patches for the linux kernel: "Btrfs: incremental send, add gen for

[PATCH 1/2] btrfs-progs: check: skip keys prior to drop key in deleted subvolume correctly

In processing deleted subvolume, we would skip keys based on subvolume drop key. The condition only checks the keys at same level. This is not correct. Consider the following situation of one deleted subvolume. This is a node of subvolume root: node 13459456000 level 3 items 9 free 484 generation

[PATCH 0/2] btrfs-progs: check: Handle drop_progress correctly for deleted subvolume

The patchsets fixes 2 problems in checking deleted subvolume. First, there are cases missing in checking drop_key, this add up the missing cases, so the skipping flow could work correctly. Second, the drop key is only applied to subvolume tree. This should be applied to the corresponding

[PATCH 2/2] btrfs-progs: check: add drop key to relocation tree

If subvolume is deleted, we add drop_key into the corresponding root item, so we know where to start processing the deleted subvolume. However, we don't skip the keys prior to the drop_key in corresponding relocation tree of the deleted subvolume. As a result, we might run into block that is freed

[PATCH 4/4] btrfs: add test for an incremental send add gen check in will_overwrite_ref

From: Robbie Ko There a some case for overwrite ref, because when new gen is waiting, and old name conflict, but old name has been deleted. This test exercises scenarios used to fail in btrfs and are fixed by the following patches for the linux kernel: "Btrfs:

[PATCH 1/4] btrfs: add test for an incremental send don't skip overwrite ref for inode 256

From: Robbie Ko Test that an incremental send operation does not skip overwrite ref for inode 256, it's always exist. This test exercises scenarios used to fail in btrfs and are fixed by the following patches for the linux kernel: "Btrfs: incremental send, fix don't skip

Re: [PATCH 0/4] Btrfs: add serval test case for incremental send

On Thu, Oct 13, 2016 at 12:04 PM, robbieko wrote: > From: Robbie Ko > > Patch for test btrfs incremental send. > > Robbie Ko (4): > btrfs: add test for an incremental send don't skip overwrite ref for > inode 256 > btrfs: add test for an