Re: [PATCH v11 00/13] Btrfs dedupe framework

On Saturday, June 25, 2016 09:22:44 AM Qu Wenruo wrote: > > On 06/24/2016 05:29 PM, Chandan Rajendra wrote: > > On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote: > >> Hi Chandan, David, > >> > >> When I'm trying to rebase dedupe patchset on top of Chadan's sub page > >> size patchset (using

Re: Trying to rescue my data :(

On 25/06/2016 3:50 AM, Austin S. Hemmelgarn wrote: > On 2016-06-24 13:43, Steven Haigh wrote: >> On 25/06/16 03:40, Austin S. Hemmelgarn wrote: >>> On 2016-06-24 13:05, Steven Haigh wrote: On 25/06/16 02:59, ronnie sahlberg wrote: What I have in mind here is that a file seems to get

Re: [PATCH v11 00/13] Btrfs dedupe framework

On 06/24/2016 05:29 PM, Chandan Rajendra wrote: On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote: Hi Chandan, David, When I'm trying to rebase dedupe patchset on top of Chadan's sub page size patchset (using David's for-next-test-20160620), although the rebase itself is quite simple, but

[PATCH] btrfs-progs: tests: 001-simple-unmounted: fix test failure due to bashism

The usage of 'source' is a bashism, and '.' should be used instead. This is causing fuzz-tests/001-simple-unmounted to fail in systems where /bin/sh isn't bash: [TEST/fuzz] 001-simple-unmounted ./test.sh: 5: ./test.sh: source: not found ./test.sh: 7: ./test.sh: setup_root_helper: not found

Re: Bad hard drive - checksum verify failure forces readonly mount

Citando Chris Murphy : On Fri, Jun 24, 2016 at 9:52 AM, Vasco Almeida wrote: From the pasted kernel messages: > Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version 4.8.5 > (Gentoo 4.8.5 p1.3, pie-0.6.2) ) #2 SMP Tue May 24

noholes and incremental send streamsize

Hi, the virtual machine images files I create and use are mostly sparse, so that not too much space on a filesystem with snapshots and on filesystems that are receive targets is used. But I noticed that with just starting up and shutting down a virtual machine, the difference between 2 nightly

[PATCH 08/31] btrfs: copy_to_sk drop unused root parameter

From: Jeff Mahoney The root parameter for copy_to_sk is not used at all. Signed-off-by: Jeff Mahoney --- fs/btrfs/ioctl.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index ffb1628..81413e6 100644

[PATCH 24/31] btrfs: root->fs_info cleanup, btrfs_calc_{trans,trunc}_metadata_size

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 8 fs/btrfs/delayed-inode.c| 4 ++-- fs/btrfs/extent-tree.c | 29 - fs/btrfs/file.c | 4 ++--

[PATCH 21/31] btrfs: root->fs_info cleanup, use fs_info->dev_root everywhere

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/check-integrity.c | 2 +- fs/btrfs/disk-io.c | 4 +-- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/scrub.c | 87 +++--- fs/btrfs/volumes.c

[PATCH 04/31] btrfs: tests, move initialization into tests/

From: Jeff Mahoney We have all these stubs that only exist because they're called from btrfs_run_sanity_tests, which is a static inside super.c. Let's just move it all into tests/btrfs-tests.c and only have one stub. Signed-off-by: Jeff Mahoney ---

[PATCH 22/31] btrfs: root->fs_info cleanup, io_ctl_init

From: Jeff Mahoney The io_ctl->root member was only being used to access root->fs_info. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 2 +- fs/btrfs/free-space-cache.c | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff

[PATCH 30/31] btrfs: root->fs_info cleanup, btrfs_commit_transaction already has root

From: Jeff Mahoney btrfs_commit_transaction is always called using the root that was used to create the transaction handle. Passing it separately is unnecessary. Signed-off-by: Jeff Mahoney --- fs/btrfs/dev-replace.c | 10 +- fs/btrfs/disk-io.c

[PATCH 28/31] btrfs: root->fs_info cleanup, access fs_info->delayed_root directly

From: Jeff Mahoney This results in btrfs_assert_delayed_root_empty and btrfs_destroy_delayed_inode taking an fs_info instead of a root. Signed-off-by: Jeff Mahoney --- fs/btrfs/delayed-inode.c | 23 ++- fs/btrfs/delayed-inode.h | 4 ++--

[PATCH 03/31] btrfs: btrfs_test_opt and friends should take a btrfs_fs_info

From: Jeff Mahoney btrfs_test_opt and friends only use the root pointer to access the fs_info. Let's pass the fs_info directly in preparation to eliminate similar patterns all over btrfs. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 22

[PATCH 02/31] btrfs: prefix fsid to all trace events

From: Jeff Mahoney When using trace events to debug a problem, it's impossible to determine which file system generated a particular event. This patch adds a macro to prefix standard information to the head of a trace event. The extent_state alloc/free events are all that's

[PATCH 15/31] btrfs: call functions that overwrite their root parameter with fs_info

From: Jeff Mahoney There are 11 functions that accept a root parameter and immediately overwrite it. We can pass those an fs_info pointer instead. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h| 4 ++-- fs/btrfs/disk-io.c | 4 ++--

[PATCH 17/31] btrfs: btrfs_init_new_device should use fs_info->dev_root

From: Jeff Mahoney btrfs_init_new_device only uses the root passed in via the ioctl to start the transaction. Nothing else that happens is related to whatever root the user used to initiate the ioctl. We can drop the root requirement and just use fs_info->dev_root instead.

[PATCH 05/31] btrfs: tests, require fs_info for root

From: Jeff Mahoney This allows the upcoming patchset to push nodesize and sectorsize into fs_info. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h | 1 + fs/btrfs/disk-io.c | 15 +++ fs/btrfs/disk-io.h

[PATCH 20/31] btrfs: struct reada_control.root -> reada_control.fs_info

From: Jeff Mahoney The root is never used. We substitute extent_root in for the reada_find_extent call, since it's only ever used to obtain the node size. This call site will be changed to use fs_info in a later patch. Signed-off-by: Jeff Mahoney ---

[PATCH 11/31] btrfs: convert nodesize macros to static inlines

From: Jeff Mahoney This patch converts the macros used to calculate various node size limits to static inlines. That way we get type checking for free. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h | 48 +--- 1

[PATCH 07/31] btrfs: simpilify btrfs_subvol_inherit_props

From: Jeff Mahoney We just need a superblock, but we look it up using two different roots depending on the call site. Let's just use a superblock pointer initialized at the outset. This is mostly for Coccinelle not to choke on my root push up set. Signed-off-by: Jeff Mahoney

[PATCH 19/31] btrfs: struct btrfsic_state->root should be an fs_info

From: Jeff Mahoney The root member is never used except for obtaining an fs_info pointer. Signed-off-by: Jeff Mahoney --- fs/btrfs/check-integrity.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH 09/31] btrfs: cleanup, remove prototype for btrfs_find_root_ref

From: Jeff Mahoney The function isn't implemented anywhere. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 0b107d1..bff6ce6 100644 --- a/fs/btrfs/ctree.h +++

[PATCH 25/31] btrfs: root->fs_info cleanup, lock/unlock_chunks

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/disk-io.c | 4 +-- fs/btrfs/extent-tree.c | 8 +++--- fs/btrfs/free-space-cache.c | 4 +-- fs/btrfs/volumes.c | 70 ++---

[PATCH 12/31] btrfs: btrfs_relocate_chunk pass extent_root to btrfs_end_transaction

From: Jeff Mahoney In btrfs_relocate_chunk, we get a transaction handle via btrfs_start_trans_remove_block_group, which starts the transaction using the extent root. When we call btrfs_end_transaction, we're calling it using the chunk root. Signed-off-by: Jeff Mahoney

[PATCH 10/31] btrfs: introduce BTRFS_MAX_ITEM_SIZE

From: Jeff Mahoney We use BTRFS_LEAF_DATA_SIZE - sizeof(struct btrfs_item) in several places. This introduces a BTRFS_MAX_ITEM_SIZE macro to do the same. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.h | 8 fs/btrfs/extent-tree.c | 2 +-

[PATCH 14/31] btrfs: btrfs_abort_transaction, drop root parameter

From: Jeff Mahoney __btrfs_abort_transaction doesn't use its root parameter except to obtain an fs_info pointer. We can obtain that from trans->root->fs_info for now and from trans->fs_info in a later patch. Signed-off-by: Jeff Mahoney --- fs/btrfs/ctree.c

[PATCH 13/31] btrfs: add btrfs_trans_handle->fs_info pointer

From: Jeff Mahoney btrfs_trans_handle->root is documented as for use for confirming that the root passed in to start the transaction is the same as the one ending it. It's used in several places when an fs_info pointer is needed, so let's just add an fs_info pointer directly.

[PATCH 26/31] btrfs: root->fs_info cleanup, update_block_group{,flags}

From: Jeff Mahoney Signed-off-by: Jeff Mahoney --- fs/btrfs/extent-tree.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 14f4d05..bc56e04 100644 ---

[PATCH 00/31] btrfs: simplify use of struct btrfs_root pointers

From: Jeff Mahoney One of the common complaints I've heard from new and experienced developers alike about the btrfs code is the ubiquity of struct btrfs_root. There is one for every tree on disk and it's not always obvious which root is needed in a particular call path. It can

[PATCH 18/31] btrfs: alloc_reserved_file_extent trace point should use extent_root

From: Jeff Mahoney Even though a separate root is passed in, we're still operating on the extent root. Let's use that for the trace point. Signed-off-by: Jeff Mahoney --- fs/btrfs/extent-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH 16/31] btrfs: call functions that always use the same root with fs_info instead

From: Jeff Mahoney There are many functions that are always called with the same root argument. Rather than passing the same root every time, we can pass an fs_info pointer instead and have the function get the root pointer itself. Signed-off-by: Jeff Mahoney

[PATCH 06/31] btrfs: tests, use BTRFS_FS_STATE_DUMMY_FS_INFO instead of dummy root

From: Jeff Mahoney Now that we have a dummy fs_info associated with each test that uses a root, we don't need the DUMMY_ROOT bit anymore. This lets us make choices without needing an actual root like in e.g. btrfs_find_create_tree_block. Signed-off-by: Jeff Mahoney

[PATCH 31/31] btrfs: root->fs_info cleanup, btrfs_end_transaction{,_throttle} use trans->fs_info instead of parameter

From: Jeff Mahoney Without btrfs_commit_transaction accepting a root parameter, __btrfs_end_transaction doesn't consume one anymore. In theory, we still accept it to compare that the root we used to start the transaction is the same one we used to end it. In practice, the check

[PATCH 01/31] btrfs: plumb fs_info into btrfs_work

From: Jeff Mahoney In order to provide an fsid for trace events, we'll need a btrfs_fs_info pointer. The most lightweight way to do that for btrfs_work structures is to associate it with the __btrfs_workqueue structure. Each queued btrfs_work structure has a workqueue

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-24 13:52, Chris Murphy wrote: On Fri, Jun 24, 2016 at 11:21 AM, Andrei Borzenkov wrote: 24.06.2016 20:06, Chris Murphy пишет: On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov wrote: On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 11:40:56AM -0600, Chris Murphy wrote: > On Fri, Jun 24, 2016 at 4:16 AM, Hugo Mills wrote: > > On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: > >For data, say you have n-1 good devices, with n-1 blocks on them. > > Each block has

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 11:21 AM, Andrei Borzenkov wrote: > 24.06.2016 20:06, Chris Murphy пишет: >> On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov >> wrote: >>> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: >>> eta)data

Re: Trying to rescue my data :(

On 2016-06-24 13:43, Steven Haigh wrote: On 25/06/16 03:40, Austin S. Hemmelgarn wrote: On 2016-06-24 13:05, Steven Haigh wrote: On 25/06/16 02:59, ronnie sahlberg wrote: What I have in mind here is that a file seems to get CREATED when I copy the file that crashes the system in the target

Re: Trying to rescue my data :(

On 25/06/16 03:40, Austin S. Hemmelgarn wrote: > On 2016-06-24 13:05, Steven Haigh wrote: >> On 25/06/16 02:59, ronnie sahlberg wrote: >> What I have in mind here is that a file seems to get CREATED when I copy >> the file that crashes the system in the target directory. I'm thinking >> if I 'cp

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 4:16 AM, Hugo Mills wrote: > On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: >> Yes, that is what I wrote below. But that means that RAID5 with one >> degraded disk won't be able to reconstruct data on this degraded disk >> because

Re: Trying to rescue my data :(

On 2016-06-24 13:05, Steven Haigh wrote: On 25/06/16 02:59, ronnie sahlberg wrote: What I have in mind here is that a file seems to get CREATED when I copy the file that crashes the system in the target directory. I'm thinking if I 'cp -an source/ target/' that it will make this somewhat easier

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 4:16 AM, Andrei Borzenkov wrote: > On Fri, Jun 24, 2016 at 8:20 AM, Chris Murphy wrote: > >> [root@f24s ~]# filefrag -v /mnt/5/* >> Filesystem type is: 9123683e >> File size of /mnt/5/a.txt is 16383 (4 blocks of 4096 bytes) >>

Re: Adventures in btrfs raid5 disk recovery

24.06.2016 20:06, Chris Murphy пишет: > On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov wrote: >> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: >> eta)data and RAID56 parity is not data. >>> >>>Checksums are not parity, correct. However, every

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov wrote: > On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: >eta)data and RAID56 parity is not data. >> >>Checksums are not parity, correct. However, every data block >> (including, I think, the

Re: Trying to rescue my data :(

On 25/06/16 02:59, ronnie sahlberg wrote: > What I would do in this situation : > > 1, Immediately stop writing to these disks/filesystem. ONLY access it > in read-only mode until you have salvaged what can be salvaged. That's ok - I can't even mount it in RW mode :) > 2, get a new 5T UDB drive

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 2:50 AM, Hugo Mills wrote: >Checksums are not parity, correct. However, every data block > (including, I think, the parity) is checksummed and put into the csum > tree. I don't see how parity is checksummed. It definitely is not in the csum tree.

Re: Trying to rescue my data :(

What I would do in this situation : 1, Immediately stop writing to these disks/filesystem. ONLY access it in read-only mode until you have salvaged what can be salvaged. 2, get a new 5T UDB drive (they are cheap) and copy file by file off the array. 3, when you hit files that cause panics, make a

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 10:52:53AM -0600, Chris Murphy wrote: > On Fri, Jun 24, 2016 at 2:50 AM, Hugo Mills wrote: > > >Checksums are not parity, correct. However, every data block > > (including, I think, the parity) is checksummed and put into the csum > > tree. > > I

Re: Bad hard drive - checksum verify failure forces readonly mount

On Fri, Jun 24, 2016 at 9:52 AM, Vasco Almeida wrote: >> >> From the pasted kernel messages: >> > Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version 4.8.5 >> > (Gentoo 4.8.5 p1.3, pie-0.6.2) ) #2 SMP Tue May 24 20:34:19 UTC 2016 >> 3.18.34 is ancient.

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 07:02:34AM +0300, Andrei Borzenkov wrote: > >> I don't read code well enough, but I'd be surprised if Btrfs > >> reconstructs from parity and doesn't then check the resulting > >> reconstructed data to its EXTENT_CSUM. > > > > I wouldn't be surprised if both things happen

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 11:20:40PM -0600, Chris Murphy wrote: > [root@f24s ~]# filefrag -v /mnt/5/* > Filesystem type is: 9123683e > File size of /mnt/5/a.txt is 16383 (4 blocks of 4096 bytes) > ext: logical_offset:physical_offset: length: expected: flags: >0:0..

Re: Trying to rescue my data :(

On 25/06/16 00:52, Steven Haigh wrote: > Ok, so I figured that despite what the BTRFS wiki seems to imply, the > 'multi parity' support just isn't stable enough to be used. So, I'm > trying to revert to what I had before. > > My setup consist of: > * 2 x 3Tb drives + > * 3 x 2Tb

[PATCH 4/4] fstests: btrfs/126,127,128: test feature ioctl and sysfs interfaces

From: Jeff Mahoney This tests the exporting of feature information from the kernel via sysfs and ioctl. The first test works whether the sysfs permissions are correct, if the information exported via sysfs matches what the ioctls are reporting, and if they both match the on-disk

[PATCH 2/4] fstests: btrfs/124: test global metadata reservation reporting

From: Jeff Mahoney Btrfs can now report the size of the global metadata reservation via ioctl and sysfs. This test confirms that we get sane results on an empty file system. ENOTTY and missing /sys/fs/btrfs//allocation are not considered failures. Signed-off-by: Jeff Mahoney

[PATCH 3/4] fstests: btrfs/125: test sysfs exports of allocation and device membership info

From: Jeff Mahoney This tests the sysfs publishing for btrfs allocation and device membership info under a number of different layouts, similar to the btrfs replace test. We test the allocation files only for existence and that they contain numerical values. We test the device

[PATCH 1/4] fstests: btrfs/048: extend _filter_btrfs_prop_error to handle additional errors

From: Jeff Mahoney btrfsprogs v4.5.3 changed the formatting of some error messages. This patch extends the filter for btrfs prop to handle those. Signed-off-by: Jeff Mahoney --- common/filter.btrfs | 10 +++--- tests/btrfs/048 | 6 --

Trying to rescue my data :(

Ok, so I figured that despite what the BTRFS wiki seems to imply, the 'multi parity' support just isn't stable enough to be used. So, I'm trying to revert to what I had before. My setup consist of: * 2 x 3Tb drives + * 3 x 2Tb drives. I've got (had?) about 4.9Tb of data. My idea

Btrfs progs release 4.6.1

Hi, btrfs-progs 4.6.1 have been released. A bugfix release. Changes: * fi resize: negative resize argument accepted again (broken * qgroup rescan: fix skipping when rescan is in progress * mkfs: initialize stripesize to correct value * testsuite updates, mostly convert tests * documentation

Re: [PATCH] btrfs-progs: fi show: print error message if no valid Btrfs is specified

On Fri, Jun 24, 2016 at 05:24:47PM +0900, Satoru Takeuchi wrote: > * Before this patch > > === > # ./btrfs fi show foo # "foo" doesn't mean any valid Btrfs > # # no error message > # echo $? > 1 > === > >

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-24 06:59, Hugo Mills wrote: On Fri, Jun 24, 2016 at 01:19:30PM +0300, Andrei Borzenkov wrote: On Fri, Jun 24, 2016 at 1:16 PM, Hugo Mills wrote: On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-24 01:20, Chris Murphy wrote: On Thu, Jun 23, 2016 at 8:07 PM, Zygo Blaxell wrote: With simple files changing one character with vi and gedit, I get completely different logical and physical numbers with each change, so it's clearly cowing the entire

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 01:19:30PM +0300, Andrei Borzenkov wrote: > On Fri, Jun 24, 2016 at 1:16 PM, Hugo Mills wrote: > > On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: > >> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: > >> > On

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 1:16 PM, Hugo Mills wrote: > On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: >> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: >> > On Fri, Jun 24, 2016 at 07:02:34AM +0300, Andrei Borzenkov wrote: >> >>

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 12:52:21PM +0300, Andrei Borzenkov wrote: > On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: > > On Fri, Jun 24, 2016 at 07:02:34AM +0300, Andrei Borzenkov wrote: > >> 24.06.2016 04:47, Zygo Blaxell пишет: > >> > On Thu, Jun 23, 2016 at 06:26:22PM

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 8:20 AM, Chris Murphy wrote: > [root@f24s ~]# filefrag -v /mnt/5/* > Filesystem type is: 9123683e > File size of /mnt/5/a.txt is 16383 (4 blocks of 4096 bytes) > ext: logical_offset:physical_offset: length: expected: flags: >0:

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills wrote: > On Fri, Jun 24, 2016 at 07:02:34AM +0300, Andrei Borzenkov wrote: >> 24.06.2016 04:47, Zygo Blaxell пишет: >> > On Thu, Jun 23, 2016 at 06:26:22PM -0600, Chris Murphy wrote: >> >> On Thu, Jun 23, 2016 at 1:32 PM, Goffredo

btrfs-convert: Unable to find block group for 0

While trying to convert a ext4 filesystem to btrfs with the new btrfs-convert from btrfs-progs-4.6 I got the following error: create btrfs filesystem: blocksize: 4096 nodesize: 16384 features: extref, skinny-metadata (default) creating ext2 image file. Unable to find

Re: [PATCH v11 00/13] Btrfs dedupe framework

On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote: > Hi Chandan, David, > > When I'm trying to rebase dedupe patchset on top of Chadan's sub page > size patchset (using David's for-next-test-20160620), although the > rebase itself is quite simple, but I'm afraid that I found some bugs for >

Re: Adventures in btrfs raid5 disk recovery

On Fri, Jun 24, 2016 at 07:02:34AM +0300, Andrei Borzenkov wrote: > 24.06.2016 04:47, Zygo Blaxell пишет: > > On Thu, Jun 23, 2016 at 06:26:22PM -0600, Chris Murphy wrote: > >> On Thu, Jun 23, 2016 at 1:32 PM, Goffredo Baroncelli > >> wrote: > >>> The raid5 write hole is

Re: [PATCH v11 00/13] Btrfs dedupe framework

On 06/24/2016 02:54 PM, Satoru Takeuchi wrote: On 2016/06/22 10:48, Qu Wenruo wrote: Here is the long-waited (simple and theoretical) performance test for dedupe. Such result may be added to btrfs wiki page, as an advice for dedupe use case. The full result can be check from google drive:

[PATCH] btrfs-progs: fi show: print error message if no valid Btrfs is specified

* Before this patch === # ./btrfs fi show foo # "foo" doesn't mean any valid Btrfs # # no error message # echo $? 1 === * After this patch === # ./btrfs fi show foo ERROR:

Re: [PATCH v11 00/13] Btrfs dedupe framework

On 2016/06/22 10:48, Qu Wenruo wrote: > Here is the long-waited (simple and theoretical) performance test for dedupe. > > Such result may be added to btrfs wiki page, as an advice for dedupe use case. > > The full result can be check from google drive: >