This fixes btrfs_get_extent to be consistent with our existing
declaration style.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.h | 4 ++--
fs/btrfs/inode.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 1aeed3c0e949..00e506de70ba
Unless it's going to read inline extents from btree leaf to page,
btrfs_get_extent won't sleep during the period of holding path lock.
This sets leave_spinning at first and sets path to blocking mode right
before reading inline extent if that's the case. The benefit is that a
path in spinning
On Fri, Aug 24, 2018 at 04:59:49PM +0200, David Sterba wrote:
> On Thu, Aug 23, 2018 at 07:41:05AM +0800, Liu Bo wrote:
> > Unless it's going to read inline extents from btree leaf to page,
> > btrfs_get_extent won't sleep during the period of holding path lock.
> >
> > This sets leave_spinning
On Thu, Aug 23, 2018 at 07:41:05AM +0800, Liu Bo wrote:
> Unless it's going to read inline extents from btree leaf to page,
> btrfs_get_extent won't sleep during the period of holding path lock.
>
> This sets leave_spinning at first and sets path to blocking mode right
> before reading inline
On 24.08.2018 16:24, Menion wrote:
> Hi all
> I have been experiencing an issue that I believe can be quite easily
> reproduced attempting to recursively rm (mv is also affected) a
> directory containing some subdirectories and files.
> The problem affects my system that run root BTRFS
Hi all
I have been experiencing an issue that I believe can be quite easily
reproduced attempting to recursively rm (mv is also affected) a
directory containing some subdirectories and files.
The problem affects my system that run root BTRFS filesystem created
by Ubuntu server installer (so kernel
On Thu, Aug 23, 2018 at 07:36:17AM +0800, Liu Bo wrote:
> trace_btrfs_get_extent() has nothing to do with path, place
> btrfs_free_path ahead so that we can unlock path on error.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
Misono Tomohiro wrote:
> commit 672d599041c8 ("btrfs: Use wrapper macro for rcu string to remove
> duplicate code") replaces some open coded rcu string handling with macro.
>
> It turns out that btrfs_debug_in_rcu() is used for the first time and
> the macro lacks lock/unlock of rcu string for
On Fri, Aug 24, 2018 at 11:35:28AM +0900, Misono Tomohiro wrote:
> commit 672d599041c8 ("btrfs: Use wrapper macro for rcu string to remove
> duplicate code") replaces some open coded rcu string handling with macro.
>
> It turns out that btrfs_debug_in_rcu() is used for the first time and
> the
On 2018/08/24 16:58, Qu Wenruo wrote:
>
>
> On 2018/8/24 下午3:54, Misono Tomohiro wrote:
>> On 2018/08/24 16:20, Qu Wenruo wrote:
>>>
>>>
>>> On 2018/8/24 下午3:14, Misono Tomohiro wrote:
Hi,
On 2018/08/21 14:40, Qu Wenruo wrote:
> Commit c6887cd11149 ("Btrfs: don't do nocow
On 2018/8/24 下午3:54, Misono Tomohiro wrote:
> On 2018/08/24 16:20, Qu Wenruo wrote:
>>
>>
>> On 2018/8/24 下午3:14, Misono Tomohiro wrote:
>>> Hi,
>>>
>>> On 2018/08/21 14:40, Qu Wenruo wrote:
Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
makes nocow check less
On 2018/08/24 16:20, Qu Wenruo wrote:
>
>
> On 2018/8/24 下午3:14, Misono Tomohiro wrote:
>> Hi,
>>
>> On 2018/08/21 14:40, Qu Wenruo wrote:
>>> Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
>>> makes nocow check less frequent to improve performance.
>>>
>>> However for
On 2018/8/24 下午3:14, Misono Tomohiro wrote:
> Hi,
>
> On 2018/08/21 14:40, Qu Wenruo wrote:
>> Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
>> makes nocow check less frequent to improve performance.
>>
>> However for quota enabled case, such optimization could lead to
Hi,
On 2018/08/21 14:40, Qu Wenruo wrote:
> Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
> makes nocow check less frequent to improve performance.
>
> However for quota enabled case, such optimization could lead to extra
> unnecessary data reservation, which results
14 matches
Mail list logo
