All of lore.kernel.org
 help / color / mirror / Atom feed
From: xfs-owner@oss.sgi.com
To: sandeen@sandeen.net
Subject: Re: iomap infrastructure and multipage writes V5
Date: Mon, 13 Feb 2017 16:32:04 -0600	[thread overview]
Message-ID: <mailman.5047.1487025124.4130.xfs@oss.sgi.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

This list has been closed.  Please subscribe to the
linux-xfs@vger.kernel.org mailing list and send any future messages
there. You can subscribe to the linux-xfs list at
http://vger.kernel.org/vger-lists.html#linux-xfs

For any questions please post to the new list.


[-- Attachment #2: Type: message/rfc822, Size: 4391 bytes --]

From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, Christoph Hellwig <hch@lst.de>
Cc: rpeterso@redhat.com, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: iomap infrastructure and multipage writes V5
Date: Mon, 13 Feb 2017 16:31:55 -0600
Message-ID: <75a139c8-5e49-3a89-10d1-20caeef3f69a@sandeen.net>

On 8/2/16 6:42 PM, Dave Chinner wrote:
> On Sun, Jul 31, 2016 at 09:19:00PM +0200, Christoph Hellwig wrote:
>> Now after spending this much time I've started wondering why we even
>> reserve blocks in xfs_iomap_write_allocate - after all we've reserved
>> space for the actual data blocks and the indlen worst case in
>> xfs_bmapi_reserve_delalloc.  And in fact a little hack to drop that
>> reservation seems to solve both the root cause (depleted reserved pool)
>> and the cleanup mess.  I just haven't spend enought time to convince
>> myself that it's actually safe, and in fact looking at the allocator
>> makes me thing it only works by accident currently despite generally
>> postive test results.
>>
>> Here is the quick patch if anyone wants to chime in:
>>
>> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
>> index 620fc91..67c317f 100644
>> --- a/fs/xfs/xfs_iomap.c
>> +++ b/fs/xfs/xfs_iomap.c
>> @@ -717,7 +717,7 @@ xfs_iomap_write_allocate(
>>  
>>  		nimaps = 0;
>>  		while (nimaps == 0) {
>> -			nres = XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK);
>> +			nres = 0; // XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK);
>>  
>>  			error = xfs_trans_alloc(mp, &M_RES(mp)->tr_write, nres,
>>  					0, XFS_TRANS_RESERVE, &tp);
>>
> 
> This solves the problem for me, and from history appears to be the
> right thing to do. Christoph, can you send a proper patch for this?

Did anything ever come of this?  I don't think I saw a patch, and it looks
like it is not upstream.

Thanks,
-Eric

> Cheers,
> 
> Dave.
> 


             reply	other threads:[~2017-02-13 22:32 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 22:32 xfs-owner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-06-01 14:44 iomap infrastructure and multipage writes V5 Christoph Hellwig
2016-06-01 14:44 ` Christoph Hellwig
2016-06-01 14:46 ` Christoph Hellwig
2016-06-01 14:46   ` Christoph Hellwig
2016-06-28  0:26 ` Dave Chinner
2016-06-28  0:26   ` Dave Chinner
2016-06-28 13:28   ` Christoph Hellwig
2016-06-28 13:28     ` Christoph Hellwig
2016-06-28 13:38     ` Christoph Hellwig
2016-06-28 13:38       ` Christoph Hellwig
2016-06-30 17:22   ` Christoph Hellwig
2016-06-30 17:22     ` Christoph Hellwig
2016-06-30 23:16     ` Dave Chinner
2016-06-30 23:16       ` Dave Chinner
2016-07-18 11:14     ` Dave Chinner
2016-07-18 11:14       ` Dave Chinner
2016-07-18 11:18       ` Dave Chinner
2016-07-18 11:18         ` Dave Chinner
2016-07-31 19:19         ` Christoph Hellwig
2016-07-31 19:19           ` Christoph Hellwig
2016-08-01  0:16           ` Dave Chinner
2016-08-01  0:16             ` Dave Chinner
2016-08-02 23:42           ` Dave Chinner
2016-08-02 23:42             ` Dave Chinner
2017-02-13 22:31             ` Eric Sandeen
2017-02-14  6:10               ` Christoph Hellwig
2016-07-19  3:50       ` Christoph Hellwig
2016-07-19  3:50         ` Christoph Hellwig

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=mailman.5047.1487025124.4130.xfs@oss.sgi.com \
    --to=xfs-owner@oss.sgi.com \
    --cc=sandeen@sandeen.net \
    /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.