Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience

Sorry I unsubscribed from linux-btrfs@vger.kernel.org since the traffic was a bit too high for me. On Tue, 7 Jun 2016, at 11:42 AM, Chris Murphy wrote: > Your command turned this from a 3 drive volume into a 2 drive volume, > it removed the drive you asked to be removed. I actually had 2 drives

Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience

On Mon, Jun 6, 2016 at 7:19 PM, Kai Hendry wrote: > On Mon, 6 Jun 2016, at 10:16 PM, Austin S. Hemmelgarn wrote: >> Based on the fact that you appear to want to carry a disk to copy data >> more quickly than over then internet, then what you've already done plus >> this is the

Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience

On Sun, Jun 5, 2016 at 11:44 PM, Kai Hendry wrote: > Hi there, > > > I planned to remove one of my disks, so that I can take it from > Singapore to the UK and then re-establish another remote RAID1 store. > > delete is an alias of remove, so I added a new disk (devid 3) and >

Re: [PATCH v2 2/2] Btrfs: add valid checks for chunk loading

On Fri, Jun 03, 2016 at 12:05:15PM -0700, Liu Bo wrote: > To prevent fuzz filesystem images from panic the whole system, > we need various validation checks to refuse to mount such an image > if btrfs finds any invalid value during loading chunks, including > both sys_array and regular chunks. >

Re: [PATCH v2 2/2] btrfs-progs: convert-tests: Add test case for backup superblock migration

On Fri, Jun 03, 2016 at 10:34:26AM +0800, Qu Wenruo wrote: > New convert introduced simpler chunk/extent allocation algorithm, at the > cost of complex backup superblock migration codes. > > Use specially built ext2 images to test if btrfs-convert can convert and > rollback images without

Re: [PATCH] Btrfs: clear uptodate flags of pages in sys_array eb

On Fri, Jun 03, 2016 at 06:16:18PM -0700, Liu Bo wrote: > On Fri, Jun 03, 2016 at 05:41:42PM -0700, Liu Bo wrote: > > We set uptodate flag to pages in the temporary sys_array eb, > > but do not clear the flag after free eb. As the special > > btree inode may still hold a reference on those pages,

Re: [PATCH v2 1/2] Btrfs: add more valid checks for superblock

On Fri, Jun 03, 2016 at 12:05:14PM -0700, Liu Bo wrote: > This adds valid checks for super_total_bytes, super_bytes_used and > super_stripesize, super_num_devices. > > Reported-by: Vegard Nossum > Reported-by: Quentin Casasnovas >

Re: [PATCH v2 1/2] btrfs-progs: convert-tests: Add support for custom test scripts

On Fri, Jun 03, 2016 at 10:34:25AM +0800, Qu Wenruo wrote: > Add support for custom convert test scripts, just like fsck tests. > > Instead of generic convert tests, we need more specifically created images > for new convert tests. > > This patch provide the needed infrastructure for later

Re: [PATCH] btrfs: chunk_width_limit mount option

On Thu, Jun 02, 2016 at 09:50:15PM -0400, Andrew Armenia wrote: > This patch adds mount option 'chunk_width_limit=X', which when set forces > the chunk allocator to use only up to X devices when allocating a chunk. > This may help reduce the seek penalties seen in filesystems with large > numbers

Re: [PATCH 0/4] btrfs: return all mirror whether need_raid_map set or not

On Tue, Dec 15, 2015 at 07:09:48PM +0800, Zhao Lei wrote: > __btrfs_map_block() should return all mirror on WRITE, > REQ_GET_READ_MIRRORS, and RECOVERY case, whether need_raid_map set > or not. > > need_raid_map only used to control is to set bbio->raid_map. > > Current code works right becuase

Re: [PATCH 0/4] btrfs: return all mirror whether need_raid_map set or not

At 06/06/2016 04:21 PM, David Sterba wrote: On Tue, Dec 15, 2015 at 07:09:48PM +0800, Zhao Lei wrote: __btrfs_map_block() should return all mirror on WRITE, REQ_GET_READ_MIRRORS, and RECOVERY case, whether need_raid_map set or not. need_raid_map only used to control is to set bbio->raid_map.

Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience

On Mon, 6 Jun 2016, at 10:16 PM, Austin S. Hemmelgarn wrote: > Based on the fact that you appear to want to carry a disk to copy data > more quickly than over then internet, then what you've already done plus > this is the correct way to do it. The trouble is the way I ended up doing it: 1)

Re: Recommended why to use btrfs for production?

On 2016-06-03 21:48, Chris Murphy wrote: On Fri, Jun 3, 2016 at 6:48 PM, Nicholas D Steeves wrote: On 3 June 2016 at 11:33, Austin S. Hemmelgarn wrote: On 2016-06-03 10:11, Martin wrote: Make certain the kernel command timer value is greater than

Re: Recommended why to use btrfs for production?

On 2016-06-05 22:40, James Johnston wrote: On 06/06/2016 at 01:47, Chris Murphy wrote: On Sun, Jun 5, 2016 at 4:45 AM, Mladen Milinkovic wrote: On 06/03/2016 04:05 PM, Chris Murphy wrote: Make certain the kernel command timer value is greater than the driver error

Re: [PATCH] btrfs: chunk_width_limit mount option

On Mon, Jun 6, 2016 at 5:17 AM, David Sterba wrote: > On Thu, Jun 02, 2016 at 09:50:15PM -0400, Andrew Armenia wrote: >> This patch adds mount option 'chunk_width_limit=X', which when set forces >> the chunk allocator to use only up to X devices when allocating a chunk. >> This

Transaction aborted in btrfs_rename2

Hi! I just got this thrice, in 4.7-rc1 and 4.7-rc2: [ 1836.672368] [ cut here ] [ 1836.672382] WARNING: CPU: 1 PID: 16348 at fs/btrfs/inode.c:9820 btrfs_rename2+0xcd2/0x2a50 [ 1836.672385] BTRFS: Transaction aborted (error -2) [ 1836.672387] Modules linked in: nvidia(PO)

Re: RAID1 vs RAID10 and best way to set up 6 disks

On 2016-06-05 16:31, Christoph Anton Mitterer wrote: On Sun, 2016-06-05 at 09:36 -0600, Chris Murphy wrote: That's ridiculous. It isn't incorrect to refer to only 2 copies as raid1. No, if there are only two devices then not. But obviously we're talking about how btrfs does RAID1, in which

Re: btrfs

On 2016-06-03 21:51, Christoph Anton Mitterer wrote: On Fri, 2016-06-03 at 15:50 -0400, Austin S Hemmelgarn wrote: There's no point in trying to do higher parity levels if we can't get regular parity working correctly. Given the current state of things, it might be better to break even and

What is the worst case scenario of splitting an extent-tree's node or leaf?

Hi all, I have questions on how BTRFS handles the scenario that a split pf extent-tree's node/leaf incurs another splits in the tree's node/leaf. Is that scenario bounded? If it is, how could I calculate the number that the split starts looping. Regards, Kaho Ng -- To unsubscribe from this

Re: [PATCH] btrfs: chunk_width_limit mount option

On Mon, Jun 06, 2016 at 09:43:19AM -0400, Andrew Armenia wrote: > On Mon, Jun 6, 2016 at 5:17 AM, David Sterba wrote: > > On Thu, Jun 02, 2016 at 09:50:15PM -0400, Andrew Armenia wrote: > >> This patch adds mount option 'chunk_width_limit=X', which when set forces > >> the chunk

Re: What is the worst case scenario of splitting an extent-tree's node or leaf?

On Mon, Jun 06, 2016 at 08:17:15PM +0800, Kaho Ng wrote: > Hi all, > > I have questions on how BTRFS handles the scenario that a split pf > extent-tree's node/leaf incurs another splits in the tree's > node/leaf. Is that scenario bounded? If it is, how could I calculate > the number that the

Re: btrfs device delete /dev/sdc1 /mnt/raid1 user experience

On 2016-06-06 01:44, Kai Hendry wrote: Hi there, I planned to remove one of my disks, so that I can take it from Singapore to the UK and then re-establish another remote RAID1 store. delete is an alias of remove, so I added a new disk (devid 3) and proceeded to run: btrfs device delete

Re: Transaction aborted in btrfs_rename2

On 6/6/16 7:47 AM, Adam Borowski wrote: > Hi! > I just got this thrice, in 4.7-rc1 and 4.7-rc2: > > [ 1836.672368] [ cut here ] > [ 1836.672382] WARNING: CPU: 1 PID: 16348 at fs/btrfs/inode.c:9820 > btrfs_rename2+0xcd2/0x2a50 > [ 1836.672385] BTRFS: Transaction aborted

Re: [PATCH 28/45] target: use bio op accessors

On 06/06/2016 01:46 AM, Hannes Reinecke wrote: > On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: >> From: Mike Christie >> >> Separate the op from the rq_flag_bits and have the target layer >> set/get the bio using bio_set_op_attrs/bio_op. >> >> Signed-off-by: Mike

Re: [PATCH 28/45] target: use bio op accessors

On 06/06/2016 05:40 PM, Mike Christie wrote: On 06/06/2016 01:46 AM, Hannes Reinecke wrote: On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: From: Mike Christie Separate the op from the rq_flag_bits and have the target layer set/get the bio using

[PULL] Self-tests updates for non-4k pages, for 4.7-rc3

: Btrfs: fix handling of faults from btrfs_copy_from_user (2016-05-26 13:23:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-chris-4.7-20160606 for you to fetch changes up to 34b3e6c92af1fa3f7067e4fa05ffa9d8bd41c96c

[PATCH v2] Btrfs: check if extent buffer is aligned to sectorsize

Thanks to fuzz testing, we can pass an invalid bytenr to extent buffer via alloc_extent_buffer(). An unaligned eb can have more pages than it should have, which ends up extent buffer's leak or some corrupted content in extent buffer. This adds a warning to let us quickly know what was happening.

Re: [PATCH v10 09/21] btrfs: dedupe: Inband in-memory only de-duplication implement

On Sat, Jun 04, 2016 at 06:26:39PM +0800, Qu Wenruo wrote: > > > On 06/03/2016 10:27 PM, Josef Bacik wrote: > >On 06/01/2016 09:12 PM, Qu Wenruo wrote: > >> > >> > >>At 06/02/2016 06:08 AM, Mark Fasheh wrote: > >>>On Fri, Apr 01, 2016 at 02:35:00PM +0800, Qu Wenruo wrote: > Core implement

Re: [PATCH v10 09/21] btrfs: dedupe: Inband in-memory only de-duplication implement

At 06/07/2016 03:54 AM, Mark Fasheh wrote: On Sat, Jun 04, 2016 at 06:26:39PM +0800, Qu Wenruo wrote: On 06/03/2016 10:27 PM, Josef Bacik wrote: On 06/01/2016 09:12 PM, Qu Wenruo wrote: At 06/02/2016 06:08 AM, Mark Fasheh wrote: On Fri, Apr 01, 2016 at 02:35:00PM +0800, Qu Wenruo

Re: [PATCH 01/45] block/fs/drivers: remove rw argument from submit_bio

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > This has callers of submit_bio/submit_bio_wait set the bio->bi_rw > instead of passing it in. This makes that use the same as > generic_make_request and how we set the other bio fields. > >

Re: [PATCH 05/45] block, drivers, cgroup: use op_is_write helper instead of checking for REQ_WRITE

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > We currently set REQ_WRITE/WRITE for all non READ IOs > like discard, flush, writesame, etc. In the next patches where we > no longer set up the op as a bitmap, we will not be able to > detect a

Re: [PATCH 02/45] block: add REQ_OP definitions and helpers

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > The following patches separate the operation (WRITE, READ, DISCARD, > etc) from the rq_flag_bits flags. This patch adds definitions for > request/bio operations (REQ_OPs) and adds request/bio

Re: [PATCH 06/45] dm: use op_is_write instead of checking for REQ_WRITE

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > We currently set REQ_WRITE/WRITE for all non READ IOs > like discard, flush, writesame, etc. In the next patches where we > no longer set up the op as a bitmap, we will not be able to > detect a

Re: [PATCH 07/45] bcache: use op_is_write instead of checking for REQ_WRITE

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > We currently set REQ_WRITE/WRITE for all non READ IOs > like discard, flush, writesame, etc. In the next patches where we > no longer set up the op as a bitmap, we will not be able to > detect a

Re: [PATCH 08/45] block, fs, mm, drivers: use bio set/get op accessors

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > This patch converts the simple bi_rw use cases in the block, > drivers, mm and fs code to set/get the bio operation using > bio_set_op_attrs/bio_op > > These should be simple one or two liner

Re: [PATCH 09/45] block discard: use bio set op accessor

On 06/05/2016 09:31 PM, mchri...@redhat.com wrote: > From: Mike Christie > > This converts the block issue discard helper and users to use > the bio_set_op_attrs accessor and only pass in the operation flags > like REQ_SEQURE. > > Signed-off-by: Mike Christie

Re: [PATCH 24/45] dm: use bio op accessors

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > Separate the op from the rq_flag_bits and have dm > set/get the bio using bio_set_op_attrs/bio_op. > > Signed-off-by: Mike Christie > Reviewed-by: Hannes Reinecke

Re: [PATCH 25/45] bcache: use bio op accessors

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > Separate the op from the rq_flag_bits and have bcache > set/get the bio using bio_set_op_attrs/bio_op. > > Signed-off-by: Mike Christie > --- > drivers/md/bcache/btree.c

Re: [PATCH 28/45] target: use bio op accessors

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > Separate the op from the rq_flag_bits and have the target layer > set/get the bio using bio_set_op_attrs/bio_op. > > Signed-off-by: Mike Christie > --- >

Re: [PATCH 37/45] drivers: use req op accessor

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > The req operation REQ_OP is separated from the rq_flag_bits > definition. This converts the block layer drivers to > use req_op to get the op from the request struct. > > Signed-off-by: Mike

Re: [PATCH 40/45] block: move bio io prio to a new field

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > In the next patch, we move drop the compat code and make > the op a separate value that is hidden in bi_rw. To give > the op and rq bits flags room to grow this moves prio to > its own field. > >

Re: [PATCH 41/45] block, drivers, fs: shrink bi_rw from long to int

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > We don't need bi_rw to be so large on 64 bit archs, so > reduce it to unsigned int. > > Signed-off-by: Mike Christie > --- > block/blk-core.c | 2 +- >

Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code

On 06/05/2016 09:32 PM, mchri...@redhat.com wrote: > From: Mike Christie > > This patch drops the compat definition of req_op where it matches > the rq_flag_bits definitions, and drops the related old and compat > code that allowed users to set either the op or flags for the