Chris Mason 於 2018-12-12 22:47 寫到:
On 28 May 2018, at 1:48, Ethan Lien wrote:
It took me a while to trigger, but this actually deadlocks ;) More
below.
[Problem description and how we fix it]
We should balance dirty metadata pages at the end of
btrfs_finish_ordered_io, since a small, unmergea
On 2018-12-13 02:29 AM, Adam Borowski wrote:
>
> For btrfs, a block device is a block device, it's not "racist".
> You can freely mix and/or replace. If you want to, say, extend a SD
> card with NBD to remote spinning rust, it works well -- tested :p
>
The possibility ff NBD certainly intrigue
On 12.12.18 г. 20:05 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> This is a follow up to the recent change that makes btrfs use the generic
> helper for cloning and deduplication [1]. It contains a mix of cleanups
> and fixes, which existed before that change.
>
> [1] Btrfs: use g
On 12.12.18 г. 20:05 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Comparing the content of the pages in the range to deduplicate is now done
> by the generic helper generic_remap_file_range_prep(), which takes care of
very minor nit: the checks are performed in generic_remap_check
On 2018-12-13 05:39, Remi Gauvin wrote:
On 2018-12-13 02:29 AM, Adam Borowski wrote:
For btrfs, a block device is a block device, it's not "racist".
You can freely mix and/or replace. If you want to, say, extend a SD
card with NBD to remote spinning rust, it works well -- tested :p
The pos
On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
> v1->v2:
> - addressed comments from reviewers.
> - fixed a bug in patch 6 that was introduced because of changes to upstream.
>
> -- Original message --
>
> The delayed refs rsv patches exposed a bunch of issues in our enospc
> infras
--
Hallo
Groeten van Funding Trusts Finance, we zijn gevestigde en
goedgekeurde Britse leningmaatschappijen, door de jaren heen hebben we
een goed begrip ontwikkeld van uw behoeften en individuele behoeften. we
hebben ons gecommitteerd om onze klanten eerlijk te behandelen en een
servi
On 13.12.18 г. 16:11 ч., David Sterba wrote:
> On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
>> v1->v2:
>> - addressed comments from reviewers.
>> - fixed a bug in patch 6 that was introduced because of changes to upstream.
>>
>> -- Original message --
>>
>> The delayed refs rsv p
On Thu, Dec 13, 2018 at 03:11:11PM +0100, David Sterba wrote:
> On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
> > v1->v2:
> > - addressed comments from reviewers.
> > - fixed a bug in patch 6 that was introduced because of changes to upstream.
> >
> > -- Original message --
> >
> >
On Wed, Dec 12, 2018 at 06:05:57PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> There is no reason why this check was performed for clone operations but
> not for deduplication operations, after all deduplication is a special
> case of cloning. So make the check happen for deduplic
On Wed, Dec 12, 2018 at 06:05:58PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Checking if the destination root is read-only was being performed only for
> clone operations. Make deduplication check it as well, as it does not make
> sense to not do it, even if it is an operation t
On Wed, Dec 12, 2018 at 03:14:17PM +0100, Johannes Thumshirn wrote:
> err holds the return value of either btrfs_del_root_ref() or
> btrfs_del_inode_ref() but it hasn't been checked since it's
> introduction with commit fe66a05a0679 (Btrfs: improve error handling
> for btrfs_insert_dir_item callers
On Fri, Dec 07, 2018 at 03:01:45PM +0200, Nikolay Borisov wrote:
>
>
> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> > From: Josef Bacik
> >
> > We use this number to figure out how many delayed refs to run, but
> > __btrfs_run_delayed_refs really only checks every time we need a new
> > delayed
On Fri, Dec 07, 2018 at 09:09:28AM +0200, Nikolay Borisov wrote:
>
>
> On 6.12.18 г. 19:54 ч., David Sterba wrote:
> > On Thu, Dec 06, 2018 at 06:52:21PM +0200, Nikolay Borisov wrote:
> >>
> >>
> >> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
> >>> Now with the delayed_refs_rsv we can now know exa
On Fri, Dec 07, 2018 at 04:45:37PM +0200, Nikolay Borisov wrote:
> > @@ -5819,9 +5953,10 @@ static void init_global_block_rsv(struct
> > btrfs_fs_info *fs_info)
> > fs_info->trans_block_rsv.space_info = space_info;
> > fs_info->empty_block_rsv.space_info = space_info;
> > fs_info->dela
On Thu, Dec 13, 2018 at 09:45:55AM -0500, Josef Bacik wrote:
> On Thu, Dec 13, 2018 at 03:11:11PM +0100, David Sterba wrote:
> > On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
> > > v1->v2:
> > > - addressed comments from reviewers.
> > > - fixed a bug in patch 6 that was introduced b
On Thu, Dec 13, 2018 at 07:17:41PM +0100, David Sterba wrote:
> On Thu, Dec 13, 2018 at 09:45:55AM -0500, Josef Bacik wrote:
> > On Thu, Dec 13, 2018 at 03:11:11PM +0100, David Sterba wrote:
> > > On Mon, Dec 03, 2018 at 10:24:51AM -0500, Josef Bacik wrote:
> > > > v1->v2:
> > > > - addressed comme
On Thu, Dec 13, 2018 at 01:28:52PM -0500, Josef Bacik wrote:
> I mean I hit this ASSERT() in testing, and this patch series has the fixed
> patch
>
> https://patchwork.kernel.org/patch/10709829/
>
> this is what fixes the problem that is causing the ASSERT(), it appears your
> next branch doesn'
On Wed, Dec 05, 2018 at 02:40:09PM +0800, Qu Wenruo wrote:
> messages.h:49:24: warning: suggest braces around empty body in an 'if'
> statement [-Wempty-body]
> PRINT_TRACE_ON_ERROR;\
>
> Just extra braces would solve the problem.
>
> Signed-off-by: Qu Wenruo
> Reviewed-by: Nikolay Bori
On Thu, Oct 11, 2018 at 06:03:56PM +0300, Nikolay Borisov wrote:
> Here is the second posting of the FSID change support for user space. For
> background information refer to the the initial posting [0]. The major changes
> in this version are:
> - Modified the sequence of operations when changi
From: Filipe Manana
We are holding a transaction handle when creating a tree, therefore we can
not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is
triggered by the allocation, therefore setup a nofs context.
Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pas
From: Filipe Manana
We are holding a transaction handle when setting an acl, therefore we can
not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
if reclaim is triggered by the allocation, therefore setup a nofs context.
Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xat
From: Filipe Manana
Several places allocate a device while holding the device list mutex. This
can result in a deadlock if reclaim happens because the device, and its
flush bio, are allocated using GFP_KERNEL mode (by __alloc_device() which
is used by btrfs_alloc_device()). A transaction commit,
On Wed, Nov 28, 2018 at 06:12:41PM +0100, Andrea Gelmini wrote:
> On Wed, Nov 28, 2018 at 06:02:47PM +0100, David Sterba wrote:
> > You've put your time to find and fix the typos so you deserve the
> > credit. Because you sent them with the signed-off-by line I will use
>
> Ok, David, thanks a lot
On 2018/12/14 上午2:59, David Sterba wrote:
> On Wed, Dec 05, 2018 at 02:40:09PM +0800, Qu Wenruo wrote:
>> messages.h:49:24: warning: suggest braces around empty body in an 'if'
>> statement [-Wempty-body]
>> PRINT_TRACE_ON_ERROR;\
>>
>> Just extra braces would solve the problem.
>>
>> Si
Adam Borowski posted on Thu, 13 Dec 2018 08:29:05 +0100 as excerpted:
> On Wed, Dec 12, 2018 at 09:31:02PM -0600, Nathan Dehnel wrote:
>> Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool with
>> an SAS drive?
>
> For btrfs, a block device is a block device, it's not "racist".
>
On 13.12.18 г. 23:17 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Several places allocate a device while holding the device list mutex. This
> can result in a deadlock if reclaim happens because the device, and its
> flush bio, are allocated using GFP_KERNEL mode (by __alloc_device
On 13.12.18 г. 23:16 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We are holding a transaction handle when creating a tree, therefore we can
> not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is
> triggered by the allocation, therefore setup a nofs context.
>
On 13.12.18 г. 23:16 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> We are holding a transaction handle when setting an acl, therefore we can
> not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
> if reclaim is triggered by the allocation, therefore setup a no
29 matches
Mail list logo
