On 2018/9/21 下午2:53, Nikolay Borisov wrote:
>
>
> On 21.09.2018 09:45, Qu Wenruo wrote:
>> And add one line comment explaining what we're doing for each loop.
>>
>> Signed-off-by: Qu Wenruo
>> ---
>> fs/btrfs/relocation.c | 15 ++-
>> 1 file changed, 6 insertions(+), 9 deletions(
On 21.09.2018 09:45, Qu Wenruo wrote:
> Commit 581c1760415c ("btrfs: Validate child tree block's level and first
> key") has made tree block level check mandatory.
>
> So if tree block level doesn't match, we won't get a valid extent
> buffer.
> The extra WARN_ON() check can be removed complete
On 21.09.2018 09:45, Qu Wenruo wrote:
> And add one line comment explaining what we're doing for each loop.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/relocation.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/rel
Commit 581c1760415c ("btrfs: Validate child tree block's level and first
key") has made tree block level check mandatory.
So if tree block level doesn't match, we won't get a valid extent
buffer.
The extra WARN_ON() check can be removed completely.
Signed-off-by: Qu Wenruo
---
fs/btrfs/relocati
And add one line comment explaining what we're doing for each loop.
Signed-off-by: Qu Wenruo
---
fs/btrfs/relocation.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 8783a1776540..d7f5a11dde20 100644
--- a/f
On Fri, Sep 21, 2018 at 12:59:31PM +1000, Dave Chinner wrote:
> On Wed, Sep 19, 2018 at 12:12:03AM -0400, Zygo Blaxell wrote:
[...]
> With no DMAPI in the future, people with custom HSM-like interfaces
> based on dmapi are starting to turn to fanotify and friends to
> provide them with the change n
On Wed, Sep 19, 2018 at 12:12:03AM -0400, Zygo Blaxell wrote:
> On Mon, Sep 10, 2018 at 07:06:46PM +1000, Dave Chinner wrote:
> > On Thu, Sep 06, 2018 at 11:53:06PM -0400, Zygo Blaxell wrote:
> > > On Thu, Sep 06, 2018 at 06:38:09PM +1000, Dave Chinner wrote:
> > > > On Fri, Aug 31, 2018 at 01:10:4
On 2018-09-20 05:35 PM, Adrian Bastholm wrote:
> Thanks a lot for the detailed explanation.
> Aabout "stable hardware/no lying hardware". I'm not running any raid
> hardware, was planning on just software raid. three drives glued
> together with "mkfs.btrfs -d raid5 /dev/sdb /dev/sdc /dev/sdd". Wou
On Thu, Sep 20, 2018 at 3:36 PM Adrian Bastholm wrote:
>
> Thanks a lot for the detailed explanation.
> Aabout "stable hardware/no lying hardware". I'm not running any raid
> hardware, was planning on just software raid.
Yep. I'm referring to the drives, their firmware, cables, logic board,
its f
Thanks a lot for the detailed explanation.
Aabout "stable hardware/no lying hardware". I'm not running any raid
hardware, was planning on just software raid. three drives glued
together with "mkfs.btrfs -d raid5 /dev/sdb /dev/sdc /dev/sdd". Would
this be a safer bet, or would You recommend running
On Thu, Sep 20, 2018 at 11:23 AM, Adrian Bastholm wrote:
> On Mon, Sep 17, 2018 at 2:44 PM Qu Wenruo wrote:
>
>>
>> Then I strongly recommend to use the latest upstream kernel and progs
>> for btrfs. (thus using Debian Testing)
>>
>> And if anything went wrong, please report asap to the mail list
On Wed, Sep 19, 2018 at 09:18:16PM -0600, Chris Murphy wrote:
> > ext4 has inline data, too, so there's every chance grub will corrupt
> > ext4 filesystems with tit's wonderful new feature. I'm not sure if
> > the ext4 metadata cksums cover the entire inode and inline data, but
> > if they do it's
On Thu, Sep 20, 2018 at 07:22:55PM +0200, David Sterba wrote:
> On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> > Changes from v7 [1]:
> >
> > - Expanded a few commit messages
> > - Added Johannes' acked-by on patches 1 and 2
> > - Rebased on v4.19-rc4
>
On Thu, Sep 20, 2018 at 06:49:59PM +0200, David Sterba wrote:
> On Thu, Aug 23, 2018 at 03:51:48AM +0800, Liu Bo wrote:
> > Several structs in btrfs are using rb_first() in a while loop, it'd be
> > more efficient to do this with rb_first_cached() which has the O(1)
> > complexity.
> >
> > This pa
On Wed, Sep 19, 2018 at 1:41 PM, Jürgen Herrmann wrote:
> Am 13.9.2018 14:35, schrieb Nikolay Borisov:
>>
>> On 13.09.2018 15:30, Jürgen Herrmann wrote:
>>>
>>> OK, I will install kdump later and perform a dump after the hang.
>>>
>>> One more noob question beforehand: does this dump contain sensi
On Mon, Sep 17, 2018 at 2:44 PM Qu Wenruo wrote:
>
> Then I strongly recommend to use the latest upstream kernel and progs
> for btrfs. (thus using Debian Testing)
>
> And if anything went wrong, please report asap to the mail list.
>
> Especially for fs corruption, that's the ghost I'm always ch
On Thu, Sep 20, 2018 at 07:15:41PM +0200, David Sterba wrote:
> On Wed, Sep 19, 2018 at 10:02:17PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > Btrfs has not allowed swap files since commit 35054394c4b3 ("Btrfs: stop
> > providing a bmap operation to avoid swapfile corruptions"). H
On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
> Changes from v7 [1]:
>
> - Expanded a few commit messages
> - Added Johannes' acked-by on patches 1 and 2
> - Rebased on v4.19-rc4
I've sent my comments, it's mostly about the usability or small
enhancements.
On Wed, Sep 19, 2018 at 10:02:17PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Btrfs has not allowed swap files since commit 35054394c4b3 ("Btrfs: stop
> providing a bmap operation to avoid swapfile corruptions"). However, now
> that the proper restrictions are in place, Btrfs can suppo
On Wed, Sep 19, 2018 at 10:02:16PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> The Btrfs swap code is going to need it, so give it a btrfs_ prefix and
> make it non-static.
>
> Reviewed-by: Nikolay Borisov
> Signed-off-by: Omar Sandoval
> ---
> fs/btrfs/volumes.c | 29 ++
On Wed, Sep 19, 2018 at 10:02:15PM -0700, Omar Sandoval wrote:
> --- a/fs/btrfs/dev-replace.c
> +++ b/fs/btrfs/dev-replace.c
> @@ -414,6 +414,14 @@ int btrfs_dev_replace_start(struct btrfs_fs_info
> *fs_info,
> if (ret)
> return ret;
>
> + if (btrfs_pinned_by_swapfile(fs_
On Thu, Aug 23, 2018 at 03:51:48AM +0800, Liu Bo wrote:
> Several structs in btrfs are using rb_first() in a while loop, it'd be
> more efficient to do this with rb_first_cached() which has the O(1)
> complexity.
>
> This patch set updates five structs which may have a large rb tree in
> practice
On 20 September 2018 at 08:20, Zbigniew 'zibi' Jarosik wrote:
> On 19 September 2018 at 15:54, Qu Wenruo wrote:
>>
>> Does the iniramfs do a "btrfs dev scan" to make populate btrfs devices
>> lists?
>
> This solved problem. Looks like btrfs scans disks to early, before
> bcache initializes. I nee
On Fri, Sep 14, 2018 at 12:14:57PM -0700, Liu Bo wrote:
> On Fri, Sep 14, 2018 at 05:11:02PM +0200, David Sterba wrote:
> > On Tue, Sep 11, 2018 at 11:31:49AM -0700, Liu Bo wrote:
> > > On Tue, Sep 11, 2018 at 05:34:03PM +0200, David Sterba wrote:
> > > > On Thu, Aug 23, 2018 at 03:51:48AM +0800, L
On 2018-09-20 15:10, David Sterba wrote:
> On Thu, Sep 20, 2018 at 12:04:36AM +0200, Rasmus Villemoes wrote:
>> First, the btrfs_debug macros open-code (one possible definition of)
>> DYNAMIC_DEBUG_BRANCH, so they don't benefit from the HAVE_JUMP_LABEL
>> optimization.
>>
>> Second, changes on x86-
On Thu, Sep 20, 2018 at 12:04:36AM +0200, Rasmus Villemoes wrote:
> First, the btrfs_debug macros open-code (one possible definition of)
> DYNAMIC_DEBUG_BRANCH, so they don't benefit from the HAVE_JUMP_LABEL
> optimization.
>
> Second, changes on x86-64 later in this series require that all struct
On 2018/9/20 下午5:04, Anand Jain wrote:
>
>
> On 09/20/2018 04:45 PM, Qu Wenruo wrote:
>>
>>
>> On 2018/9/20 下午1:26, anand.j...@oracle.com wrote:
>>>
>>>
>>> Test script [1] tries to punch hole on a full FS and it works fine as
>>> long as the hole size and the offset is aligned with the sectors
чт, 20 сент. 2018 г. в 12:05, Peter Becker :
>
> i like the idea.
> do you have any benchmarks for this change?
>
> the general logic looks good for me.
https://patchwork.kernel.org/patch/10137909/
>
> Tested-by: Dmitrii Tcvetkov
>
> Benchmark summary (arithmetic mean of 3 runs):
> Mainline Patc
On 2018/9/20 下午5:04, Anand Jain wrote:
>
>
> On 09/20/2018 04:45 PM, Qu Wenruo wrote:
>>
>>
>> On 2018/9/20 下午1:26, anand.j...@oracle.com wrote:
>>>
>>>
>>> Test script [1] tries to punch hole on a full FS and it works fine as
>>> long as the hole size and the offset is aligned with the sectors
i like the idea.
do you have any benchmarks for this change?
the general logic looks good for me.
On 09/20/2018 04:45 PM, Qu Wenruo wrote:
On 2018/9/20 下午1:26, anand.j...@oracle.com wrote:
Test script [1] tries to punch hole on a full FS and it works fine as
long as the hole size and the offset is aligned with the sectorsize and
the extent, so that it could just drop the relevant exte
On 2018/9/20 下午1:26, anand.j...@oracle.com wrote:
>
>
> Test script [1] tries to punch hole on a full FS and it works fine as
> long as the hole size and the offset is aligned with the sectorsize and
> the extent, so that it could just drop the relevant extent to create the
> hole.
>
> The rea
Axel Burri posted on Thu, 20 Sep 2018 00:02:22 +0200 as excerpted:
> Now not everybody wants to install these with fscaps or setuid, but it
> might also make sense to provide "/usr/bin/btrfs-subvolume-{show,list}",
> as they now work for a regular user. Having both root/user binaries
> concurrentl
On Thursday, September 20, 2018 12:04:22 AM CEST Rasmus Villemoes wrote:
> This started as an experiment to see how hard it would be to change
> the four pointers in struct _ddebug into relative offsets, a la
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS, thus saving 16 bytes per
> pr_debug site (and thus
Tomasz Chmielewski posted on Wed, 19 Sep 2018 10:43:18 +0200 as excerpted:
> I have a mysql slave which writes to a RAID-1 btrfs filesystem (with
> 4.17.14 kernel) on 3 x ~1.9 TB SSD disks; filesystem is around 40% full.
>
> The slave receives around 0.5-1 MB/s of data from the master over the
>
35 matches
Mail list logo
