Re: [PULL] Btrfs for 4.7, part 2

On 05/27/2016 11:42 PM, Chris Mason wrote: On Fri, May 27, 2016 at 10:35:27AM -0400, Chris Mason wrote: On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote: On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote:

Re: [PATCH v3 21/22] btrfs-progs: convert: Strictly avoid meta or system chunk allocation

On Fri, Jan 29, 2016 at 01:03:31PM +0800, Qu Wenruo wrote: > Before this patch, btrfs-convert only rely on large enough initial > system/metadata chunk size to ensure no newer system/meta chunk will be > created. > > But that's not safe enough. So add two new members in fs_info, >

Re: [PATCH v3 16/22] btrfs-progs: convert: Introduce function to migrate reserved ranges

On Fri, Jan 29, 2016 at 01:03:26PM +0800, Qu Wenruo wrote: > Introduce new function, migrate_reserved_ranges() to migrate used fs > data in btrfs reserved space. > > Unlike old implement, which will need to relocate all the complicated > csum and reference relocation, previous patches already

Re: [PATCH v3 15/22] btrfs-progs: convert: Introduce new function to create converted image

On Fri, Jan 29, 2016 at 01:03:25PM +0800, Qu Wenruo wrote: > Use new function, create_convert_image_v2() to create snapshot of old > filesystem. > > Unlike old function which is called after copying all inodes, this > function need to be called before copying inodes. > > Signed-off-by: Qu Wenruo

Re: [PATCH v3 05/22] btrfs-progs: Introduce function to setup temporary superblock

On Fri, Jan 29, 2016 at 01:03:15PM +0800, Qu Wenruo wrote: > Introduce a new function, setup_temp_super(), to setup temporary super > for make_btrfs_v2(). > > Signed-off-by: Qu Wenruo > Signed-off-by: David Sterba > --- > utils.c | 117 >

Re: [PATCH] btrfs,vfs: allow FILE_EXTENT_SAME on a file opened ro

On Thu, May 26, 2016 at 05:04:01PM -0700, Mark Fasheh wrote: > On Fri, May 20, 2016 at 05:45:12AM +0200, Adam Borowski wrote: > > (Only btrfs currently implements dedupe_file_range.) > > > > Instead of checking the mode of the file descriptor, let's check whether > > it could have been opened rw.

Re: RFE: 'btrfs' tools machine readable output

On 16 May 2016 at 08:39, Austin S. Hemmelgarn wrote: > On 2016-05-16 08:14, Richard W.M. Jones wrote: >> >> It would be really helpful if the btrfs tools had a machine-readable >> output. >> With machine-readable output, there'd be a flag which would >> change the output.

Re: [PATCH 3/5] Btrfs: self-tests: Support non-4k page size

On Fri, May 27, 2016 at 03:00:36PM +0800, Feifei Xu wrote: > self-tests code assumes 4k as the sectorsize and nodesize. This commit > enables the self-tests code to be executed on non-4k page sized > systems (e.g. ppc64). > > To test all possible sectorsizes, this commit adds a sectorsize >

Re: [PATCH 5/5] Btrfs: self-test: fix extent buffer bitmap test fail on BE system

On Fri, May 27, 2016 at 03:00:38PM +0800, Feifei Xu wrote: > In __test_eb_bitmaps(), we write random data to a bitmap. Then copy > the bitmap to another bitmap that resides inside an extent buffer. > Later we verify the values of corresponding bits in the bitmap and the > bitmap inside the extent

Re: Scrub aborts on newer kernels

On Thu, May 26, 2016 at 11:55 AM, Tyson Whitehead wrote: > Under the last several kernels versions (4.6 and I believe 4.4 and, 4.5) > btrfs scrub aborts before completing. I can't reproduce this with btrfs-progs 4.5.2 and kernel 4.6.0. I think the bigger issue is the lack

[PATCH 8/7] xfs/122: don't break on old xfsprogs

If we're running against a old version of xfsprogs that lacks some of the structures that the golden output knows about, copy the structure size definition from the golden output to the program output. This way we can check for structure size mutations on old xfsprogs without generating false

[GIT PULL] Btrfs

Hi Linus, We have another round of fixes and a few cleanups in my for-linus-4.7 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7 I have a fix for short returns from btrfs_copy_from_user, which finally nails down a very hard to find regression we added

[PATCH] Btrfs: use FLUSH_LIMIT for relocation in reserve_metadata_bytes

We used to allow you to set FLUSH_ALL and then just wouldn't do things like commit transactions or wait on ordered extents if we noticed you were in a transaction. However now that all the flushing for FLUSH_ALL is asynchronous we've lost the ability to tell, and we could end up deadlocking. So

[PATCH] Btrfs: fill relocation block rsv after allocation

Since we set the reloc control before we've reserved our space for relocation we could race with a root being dirtied and not actually have space to do our init reloc root. So once we've allocated it and set it up go ahead and make our reservation before setting the relocate control, that way

[PATCH] Btrfs: don't BUG_ON() in btrfs_orphan_add

This is just a screwup for developers, so change it to an ASSERT() so developers notice when things go wrong and deal with the error appropriately if ASSERT() isn't enabled. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/inode.c | 11 ++- 1 file changed, 10

[PATCH] Btrfs: always use trans->block_rsv for orphans

This is the case all the time anyway except for relocation which could be doing a reloc root for a non ref counted root, in which case we'd end up with some random block rsv rather than the one we have our reservation in. If there isn't enough space in the block rsv we are trying to steal from

[PATCH V2] Btrfs: change how we calculate the global block rsv

Traditionally we've calculated the global block rsv by guessing how much of the metadata used amount was the extent tree, and then taking the data size and figuring out how large the csum tree would have to be to hold that much data. This is imprecise and falls down on MIXED file systems as we

Re: [PATCH 1/5] Btrfs: test_check_exists: Fix infinite loop when searching for free space entries

On 05/27/2016 03:00 AM, Feifei Xu wrote: On a ppc64 machine using 64K as the block size, assume that the RB tree at btrfs_free_space_ctl->free_space_offset contains following two entries: 1. A bitmap entry having an offset value of 0 and having the bits corresponding to the address range

Re: [PULL] Btrfs for 4.7, part 2

On Fri, May 27, 2016 at 10:35:27AM -0400, Chris Mason wrote: > On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote: > > On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: > > > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > > > > Hi, > > > > > > > > please pull

Re: [PULL] Btrfs for 4.7, part 2

On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote: > On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: > > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > > > Hi, > > > > > > please pull a few more patches that did not go to pull #1 for 4.7, minor > > >

Re: [PULL] Btrfs for 4.7, part 2

On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > > Hi, > > > > please pull a few more patches that did not go to pull #1 for 4.7, minor > > cleanups and fixes. Thanks. > > Thanks Dave! Trying to figure out why we're

Re: [PATCH 1/2] Btrfs-progs: make convert to allocate space from the desired type of block group

On Fri, May 27, 2016 at 07:04:42PM +0800, Qu Wenruo wrote: > > The plan is to release 4.6 with this patchset, I'm still not decided > > about the low-mem mode for checker. > > For low memory mode, at least we're not that eager to see it merged into > 4.6. I still need to test it on some large

Re: [1/1 v2] String and comment review: Fix typos; fix a couple of mandatory grammatical issues for clarity.

On 24 May 2016 at 06:50, David Sterba wrote: > On Mon, May 23, 2016 at 02:26:46PM -0400, Nicholas D Steeves wrote: >> On 23 May 2016 at 13:01, David Sterba wrote: >> > On Thu, May 19, 2016 at 09:30:49PM -0400, Nicholas D Steeves wrote: >> >> Sorry for the noise.

Re: [PATCH 1/2] Btrfs-progs: make convert to allocate space from the desired type of block group

On 05/27/2016 06:55 PM, David Sterba wrote: On Fri, May 27, 2016 at 09:38:09AM +0800, Qu Wenruo wrote: Since btrfs-convert has been reworked to use a completely new method to do such allocation, now it doesn't need any custom_alloc_extent() function. And its new chunk lay out is designed to

Re: [PATCH 1/2] Btrfs-progs: make convert to allocate space from the desired type of block group

On Fri, May 27, 2016 at 09:38:09AM +0800, Qu Wenruo wrote: > Since btrfs-convert has been reworked to use a completely new method to > do such allocation, now it doesn't need any custom_alloc_extent() function. > > And its new chunk lay out is designed to only put metadata chunk into > large

Re: [PATCH v2] btrfs: Add debug warning for new block group reservations

Filipe Manana wrote on 2016/05/27 10:51 +0100: On Thu, May 26, 2016 at 8:06 AM, Qu Wenruo wrote: Since the we are using atomic and wait queue for block group reservations and it's not controlled by lockdep, we need pay much more attention to any modification to write

Re: [PATCH v2] btrfs: Add debug warning for new block group reservations

On Thu, May 26, 2016 at 8:06 AM, Qu Wenruo wrote: > Since the we are using atomic and wait queue for block group > reservations and it's not controlled by lockdep, we need pay much more > attention to any modification to write path. > > Or it's very easy to under flow

Re: Device replace issues and disabling it until they are solved

On Thu, May 26, 2016 at 8:09 PM, Scott Talbert wrote: > On Wed, 11 May 2016, Filipe Manana wrote: > >>> I've noticed some time ago that our device replace implementation is >>> unreliable. Basically under several situations it ends up not copying >>> extents (both data and

Re: Starting btrfs defrag with xargs -P 2 locks

On Fri, May 27, 2016 at 4:58 AM, Jérôme Poulin wrote: > I was de-fragmenting a BTRFS recently and it was quite slow, so I > decided to pipe find output to xargs -P 2 to speed up the file listing > process and found out it breaks BTRFS quite fast. In 2 minutes, I had > this

[PATCH 1/5] Btrfs: test_check_exists: Fix infinite loop when searching for free space entries

On a ppc64 machine using 64K as the block size, assume that the RB tree at btrfs_free_space_ctl->free_space_offset contains following two entries: 1. A bitmap entry having an offset value of 0 and having the bits corresponding to the address range [128M+512K, 128M+768K] set. 2. An extent entry

[PATCH 0/5] Btrfs: enable self-test on ppc64

Hi, Btrfs self-test module assumed that both sectorsize and PAGE_SIZE are 4K. Thus many self-tests fail on non-4K page size systems, like ppc64. This patchset enables self-tests to be executed on non-4k page size systems. This patchset enables us to easily add support for possible sectorsizes

[PATCH 4/5] Btrfs: test_bitmaps: Fix failure on 64k sectorsize

With 64K sectorsize, 1G sized block group cannot span across bitmaps. To execute test_bitmaps() function, this commit allocates "BITS_PER_BITMAP * sectorsize + PAGE_SIZE" sized block group. Reviewed-by: Chandan Rajendra Signed-off-by: Feifei Xu

[PATCH 5/5] Btrfs: self-test: fix extent buffer bitmap test fail on BE system

In __test_eb_bitmaps(), we write random data to a bitmap. Then copy the bitmap to another bitmap that resides inside an extent buffer. Later we verify the values of corresponding bits in the bitmap and the bitmap inside the extent buffer. However, extent_buffer_test_bit() reads in byte granularity

[PATCH 3/5] Btrfs: self-tests: Support non-4k page size

self-tests code assumes 4k as the sectorsize and nodesize. This commit enables the self-tests code to be executed on non-4k page sized systems (e.g. ppc64). To test all possible sectorsizes, this commit adds a sectorsize array. This commit executes the tests for all possible sectorsizes and

[PATCH 2/5] Btrfs: Fix integer overflow when calculating bytes_per_bitmap

On ppc64, bytes_per_bitmap will be (65536*8*65536). Hence append UL to fix integer overflow. Reviewed-by: Chandan Rajendra Signed-off-by: Feifei Xu --- fs/btrfs/free-space-cache.c | 13 +++--