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:
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,
>
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
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
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
>
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.
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.
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
>
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
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
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
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
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
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
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
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
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
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
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
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
> > >
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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 +++--
35 matches
Mail list logo