From: Dave Chinner <david@fromorbit.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v2 2/3] GFS2: Implement iomap for block_map
Date: Thu, 3 Nov 2016 08:01:58 +1100 [thread overview]
Message-ID: <20161102210158.GE14023@dastard> (raw)
In-Reply-To: <5819B3BC.6080602@redhat.com>
On Wed, Nov 02, 2016 at 09:37:00AM +0000, Steven Whitehouse wrote:
> Hi,
>
> On 31/10/16 20:07, Dave Chinner wrote:
> >On Sat, Oct 29, 2016 at 10:24:45AM +0100, Steven Whitehouse wrote:
> >>On 28/10/16 20:29, Bob Peterson wrote:
> >>>+ if (create)
> >>>+ flags |= IOMAP_WRITE;
> >>Hmm, I wonder why IOMAP_WRITE and IOMAP_ZERO are separate flags from
> >>the iomap.flags field... Christoph, was there a specific reason for
> >>that?
> >They are different actions. IOMAP_WRITE requires allocation over
> >holes and conversion of unwritten extents to allow writing of
> >user data into the range. IOMAP_ZERO is for zeroing a range of a
> >file via iomap_zero_range() and it does not require allocation - it
> >skips holes and unwritten regions as they are already guaranteed to
> >contain zeros.
> >
> >One *could* allocate blocks with IOMAP_ZERO if desired (i.e.
> >implement IOMAP_ZERO as though it implied IOMAP_WRITE) and
> >iomap_zero_range_actor() will zero the allocated regions
> >appropriately, but it's not necessary to do if it is already known
> >what ranges of the file contain zeros...
> >
> >Cheers,
> >
> >Dave.
> That wasn't quite what I was getting at... we have two sets of
> flags. IOMAP_ZERO, IOMAP_WRITE and IOMAP_REPORT form one set that
> are passed as an argument to ->iomap_begin() and ->iomap_end()
Yes, those are mapping operation control flags that determine the
mapping operation to be done.
> whereas we also have IOMAP_F_* which are set in the iomap.flags
And those are per-map state flags that apply to the extent being
returned.
> field. I guess perhaps the former is intended as the input flags to
> the functions, where as the latter are output flags from
> ->iomap_begin()?
Yes, I thought that was obvious - it didn't occur to me that there'd
be any confusion there. What can we add to the iomap.h definitions
to make this clearer?
> In that case I would expect that ->iomap_end()
> would view the iomap.flags as read only.
iomap.flags, like the rest of the struct iomap that is returned from
->iomap_begin(), is readonly for all users. Only the filesystem
itself can change extent mappings or state.....
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
next prev parent reply other threads:[~2016-11-02 21:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 19:29 [Cluster-devel] [PATCH v2 0/3] Implement iomap for fiemap in GFS2 Bob Peterson
2016-10-28 19:29 ` [Cluster-devel] [PATCH v2 1/3] GFS2: Make height info part of metapath Bob Peterson
2016-10-28 19:29 ` [Cluster-devel] [PATCH v2 2/3] GFS2: Implement iomap for block_map Bob Peterson
2016-10-29 9:24 ` Steven Whitehouse
2016-10-31 12:07 ` Bob Peterson
2016-10-31 20:07 ` Dave Chinner
2016-11-02 9:37 ` Steven Whitehouse
2016-11-02 21:01 ` Dave Chinner [this message]
2016-11-03 9:45 ` Steven Whitehouse
2016-11-04 13:44 ` Christoph Hellwig
2016-11-07 12:03 ` Steven Whitehouse
2016-10-28 19:29 ` [Cluster-devel] [PATCH v2 3/3] GFS2: Switch fiemap implementation to use iomap Bob Peterson
2016-10-29 9:33 ` Steven Whitehouse
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=20161102210158.GE14023@dastard \
--to=david@fromorbit.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.