From: David Sterba <dsterba@suse.cz>
To: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Cc: "Holger Hoffstätte" <holger@applied-asynchrony.com>,
linux-btrfs@vger.kernel.org, jbacik@fb.com, dsterba@suse.com
Subject: Re: [PATCH 2/2] btrfs: fix false enospc for compression
Date: Wed, 19 Oct 2016 16:23:44 +0200 [thread overview]
Message-ID: <20161019142344.GR11398@twin.jikos.cz> (raw)
In-Reply-To: <5804937A.2060506@cn.fujitsu.com>
On Mon, Oct 17, 2016 at 05:01:46PM +0800, Wang Xiaoguang wrote:
> > [..]
> >> int btrfs_set_extent_delalloc(struct inode *inode, u64 start, u64 end,
> >> - struct extent_state **cached_state);
> >> + struct extent_state **cached_state, int flag);
> >> int btrfs_set_extent_defrag(struct inode *inode, u64 start, u64 end,
> >> - struct extent_state **cached_state);
> >> + struct extent_state **cached_state, int flag);
> > [..]
> >> int btrfs_dirty_pages(struct btrfs_root *root, struct inode *inode,
> >> struct page **pages, size_t num_pages,
> >> loff_t pos, size_t write_bytes,
> >> - struct extent_state **cached);
> >> + struct extent_state **cached, int flag);
> > Instead of adding "int flag" why not use the already defined
> > btrfs_metadata_reserve_type enum? I know it's just an int at the end of
> > the day, but the dedupe support already added another "int dedupe" argument
> > and it's probably easy to cause confusion.
> > Maybe later it would be beneficial to consolidate the flags into a consistent
> > set of enum values to prevent more "int flag" inflation and better declare the
> > intent of the extent state change. Not sure if that makes sense.
> Yes, agree.
> I'll rebase them later, thanks.
Would be great. I won't manually merge the patch now as it's not a
conflict against the current state, btrfs_set_extent_delalloc has the
extra parameter already. Please consolidate them before this patch is
supposed to be merged. Thanks.
next prev parent reply other threads:[~2016-10-19 14:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 2:51 [PATCH 1/2] btrfs: improve inode's outstanding_extents computation Wang Xiaoguang
2016-10-06 2:51 ` [PATCH 2/2] btrfs: fix false enospc for compression Wang Xiaoguang
2016-10-06 3:51 ` Wang Xiaoguang
2016-10-12 3:12 ` Wang Xiaoguang
2016-10-17 15:05 ` David Sterba
2016-10-14 13:09 ` Stefan Priebe - Profihost AG
2016-10-14 13:59 ` Holger Hoffstätte
2016-10-17 9:01 ` Wang Xiaoguang
2016-10-19 14:23 ` David Sterba [this message]
2016-10-25 10:43 ` Wang Xiaoguang
2016-10-14 13:09 ` [PATCH 1/2] btrfs: improve inode's outstanding_extents computation Stefan Priebe - Profihost AG
2016-10-23 17:45 ` Stefan Priebe - Profihost AG
2016-11-01 10:18 Wang Xiaoguang
2016-11-01 10:18 ` [PATCH 2/2] btrfs: fix false enospc for compression Wang Xiaoguang
2016-11-01 10:28 ` Wang Xiaoguang
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=20161019142344.GR11398@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=dsterba@suse.com \
--cc=holger@applied-asynchrony.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangxg.fnst@cn.fujitsu.com \
/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.