cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
* [Cluster-devel] [GFS2 PATCH v2] GFS2: dirty inode correctly in gfs2_iomap_end for jdata
       [not found] <1441162328.47734988.1530629474646.JavaMail.zimbra@redhat.com>
@ 2018-07-03 14:54 ` Bob Peterson
  2018-07-03 18:32   ` Andreas Gruenbacher
  0 siblings, 1 reply; 2+ messages in thread
From: Bob Peterson @ 2018-07-03 14:54 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi,

I posted an equivalent patch on 18 June which was largely ignored.
This is revised for the recent iomap changes.
---
In patch 0c9018097f, function gfs2_write_end was changed so that it
marked inodes dirty if they had new buffers queued to the current
transaction. Unfortunately, it was only done for ordered data files.
The check was never done for jdata files, so the inode was never
properly marked dirty. The affected code has since been moved to
function gfs2_iomap_end. This patch adds the additional check so
that jdata files are also marked dirty.

Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
 fs/gfs2/bmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
index 49a6ab919bd7..afbee7e4ae5b 100644
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -1116,7 +1116,7 @@ static int gfs2_iomap_end(struct inode *inode, loff_t pos, loff_t length,
 	if (iomap->type != IOMAP_INLINE) {
 		gfs2_ordered_add_inode(ip);
 
-		if (tr->tr_num_buf_new)
+		if (tr->tr_num_buf_new || tr->tr_num_databuf_new)
 			__mark_inode_dirty(inode, I_DIRTY_DATASYNC);
 		else
 			gfs2_trans_add_meta(ip->i_gl, dibh);



^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [Cluster-devel] [GFS2 PATCH v2] GFS2: dirty inode correctly in gfs2_iomap_end for jdata
  2018-07-03 14:54 ` [Cluster-devel] [GFS2 PATCH v2] GFS2: dirty inode correctly in gfs2_iomap_end for jdata Bob Peterson
@ 2018-07-03 18:32   ` Andreas Gruenbacher
  0 siblings, 0 replies; 2+ messages in thread
From: Andreas Gruenbacher @ 2018-07-03 18:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On 3 July 2018 at 16:54, Bob Peterson <rpeterso@redhat.com> wrote:
> Hi,
>
> I posted an equivalent patch on 18 June which was largely ignored.
> This is revised for the recent iomap changes.
> ---
> In patch 0c9018097f, function gfs2_write_end was changed so that it
> marked inodes dirty if they had new buffers queued to the current
> transaction. Unfortunately, it was only done for ordered data files.
> The check was never done for jdata files, so the inode was never
> properly marked dirty. The affected code has since been moved to
> function gfs2_iomap_end. This patch adds the additional check so
> that jdata files are also marked dirty.

Like I just said in the previous posting of this fix, I'd be much
happier to have a test case.

> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
> ---
>  fs/gfs2/bmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
> index 49a6ab919bd7..afbee7e4ae5b 100644
> --- a/fs/gfs2/bmap.c
> +++ b/fs/gfs2/bmap.c
> @@ -1116,7 +1116,7 @@ static int gfs2_iomap_end(struct inode *inode, loff_t pos, loff_t length,
>         if (iomap->type != IOMAP_INLINE) {
>                 gfs2_ordered_add_inode(ip);
>
> -               if (tr->tr_num_buf_new)
> +               if (tr->tr_num_buf_new || tr->tr_num_databuf_new)
>                         __mark_inode_dirty(inode, I_DIRTY_DATASYNC);
>                 else
>                         gfs2_trans_add_meta(ip->i_gl, dibh);
>

Thanks,
Andreas



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-07-03 18:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1441162328.47734988.1530629474646.JavaMail.zimbra@redhat.com>
2018-07-03 14:54 ` [Cluster-devel] [GFS2 PATCH v2] GFS2: dirty inode correctly in gfs2_iomap_end for jdata Bob Peterson
2018-07-03 18:32   ` Andreas Gruenbacher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).