From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Fri, 4 Nov 2016 06:44:42 -0700 Subject: [Cluster-devel] [PATCH v2 2/3] GFS2: Implement iomap for block_map In-Reply-To: <581B074B.4000301@redhat.com> References: <1477682971-4517-1-git-send-email-rpeterso@redhat.com> <1477682971-4517-3-git-send-email-rpeterso@redhat.com> <58146ADD.9010702@redhat.com> <20161031200716.GM22126@dastard> <5819B3BC.6080602@redhat.com> <20161102210158.GE14023@dastard> <581B074B.4000301@redhat.com> Message-ID: <20161104134442.GA13429@infradead.org> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > > 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() They actually are the type of operation we perform, so maybe we should rename them to "op" or similar. > For GFS2 then we want to use the IOMAP_* flags as they are at the moment, > but for the function that maps back from iomap to gfs2_block_map() we'd need > to add a IOMAP_F_ZEROED or something like that from which to set the > BH_zeronew() flag, which is used as both a request and result flag for the > zeroing operation. That flag would very likely go away in due course when > the final iomap migration is done for GFS2, so would just be a temporary > thing in the mean time. That would be the existing IOMAP_F_NEW I guess? > I also wondered whether it would be possible to write a generic > implementation of SEEK_HOLE/SEEK_END for iomap supporting filesystems at the > VFS level. That would get GFS2 support for those two operations and be a > nice clean up too. I've added an item on our todo list for that, but it may > be a little while before we get around to it, Yes, that should be doable. Would be great if you could look at it, otherwise I'll add it to my todo list.