From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
Liu Bo <bo.li.liu@oracle.com>,
linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.cz>
Subject: Re: resend: Re: Btrfs: adjust len of writes if following a preallocated extent
Date: Wed, 23 Nov 2016 19:23:38 +0100 [thread overview]
Message-ID: <5835DEAA.8020602@applied-asynchrony.com> (raw)
In-Reply-To: <b600e06c-f946-853a-d868-eed429f9097b@profihost.ag>
On 11/23/16 18:21, Stefan Priebe - Profihost AG wrote:
> Am 04.11.2016 um 20:20 schrieb Liu Bo:
>> If we have
>>
>> |0--hole--4095||4096--preallocate--12287|
>>
>> instead of using preallocated space, a 8K direct write will just
>> create a new 8K extent and it'll end up with
>>
>> |0--new extent--8191||8192--preallocate--12287|
>>
>> It's because we find a hole em and then go to create a new 8K
>> extent directly without adjusting @len.
>
> after applying that one on top of my 4.4 btrfs branch (includes patches
> up to 4.10 / next). i'm getting deadlocks in btrfs.
*ctrl+f sectorsize* ..
That's not surprising if you did what I suspect. If your tree is based
on my - now really very retired - 4.4.x queue, then you are likely missing
_all the other blocksize/sectorsize patches_ that came in from Chandra
Seetharaman et al., which I _really_ carefully patched around, for many
good reasons.
-h
next prev parent reply other threads:[~2016-11-23 18:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 19:20 [PATCH] Btrfs: adjust len of writes if following a preallocated extent Liu Bo
2016-11-22 19:59 ` Chris Mason
2016-11-23 15:54 ` NOC - Profihost AG
2016-11-23 17:21 ` resend: " Stefan Priebe - Profihost AG
2016-11-23 18:23 ` Holger Hoffstätte [this message]
2016-11-23 18:58 ` Stefan Priebe - Profihost AG
2016-11-23 21:22 ` Liu Bo
2016-11-24 11:13 ` Filipe Manana
2016-12-02 1:41 ` Liu Bo
2016-12-02 12:25 ` Filipe Manana
2016-12-16 22:37 ` Liu Bo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5835DEAA.8020602@applied-asynchrony.com \
--to=holger@applied-asynchrony.com \
--cc=bo.li.liu@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=s.priebe@profihost.ag \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.