cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 1/3] gfs2: Don't write updates to local	statfs file
Date: Wed, 19 Aug 2020 13:07:26 -0400 (EDT)	[thread overview]
Message-ID: <165825613.12780098.1597856846775.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20200813200114.5665-2-adas@redhat.com>

----- Original Message -----
> We store the local statfs info in the journal header now so
> there's no need to write to the local statfs file anymore.
> 
> Signed-off-by: Abhi Das <adas@redhat.com>
> ---
>  fs/gfs2/lops.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
> index cb2a11b458c6..53d2dbf6605e 100644
> --- a/fs/gfs2/lops.c
> +++ b/fs/gfs2/lops.c
> @@ -104,7 +104,15 @@ static void gfs2_unpin(struct gfs2_sbd *sdp, struct
> buffer_head *bh,
>  	BUG_ON(!buffer_pinned(bh));
>  
>  	lock_buffer(bh);
> -	mark_buffer_dirty(bh);
> +	/*
> +	 * We want to eliminate the local statfs file eventually.
> +	 * But, for now, we're simply not going to update it by
> +	 * never marking its buffers dirty
> +	 */
> +	if (!(bd->bd_gl->gl_name.ln_type == LM_TYPE_INODE &&
> +	      bd->bd_gl->gl_object == GFS2_I(sdp->sd_sc_inode)))
> +		mark_buffer_dirty(bh);
> +
>  	clear_buffer_pinned(bh);
>  
>  	if (buffer_is_rgrp(bd))
> --
> 2.20.1

Hi,

This seems dangerous to me. It can only get to gfs2_unpin by trying to
commit buffers for a transaction. If the buffers aren't marked dirty,
that means transactions will be queued to the ail1 list that won't be
fully written. So what happens to them? Do they eventually get freed?

I'm also concerned about a potential impact to performance, since
gfs2_unpin gets called with every metadata buffer that's used.
The additional if checks may not costs us much time-wise, but it's a
pretty hot function.

Can't we accomplish the same thing by making function update_statfs()
never add the buffers to the transaction in the first place?
IOW, by just removing the line:
	gfs2_trans_add_meta(m_ip->i_gl, m_bh);
That way we don't need to worry about its buffer getting pinned,
unpinned and queued to the ail.

Regards,

Bob Peterson



  reply	other threads:[~2020-08-19 17:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 20:01 [Cluster-devel] [PATCH 0/3] local statfs improvements Abhi Das
2020-08-13 20:01 ` [Cluster-devel] [PATCH 1/3] gfs2: Don't write updates to local statfs file Abhi Das
2020-08-19 17:07   ` Bob Peterson [this message]
2020-08-20 11:04     ` Abhijith Das
2020-08-20 11:23       ` Steven Whitehouse
2020-08-13 20:01 ` [Cluster-devel] [PATCH 2/3] gfs2: Add fields for statfs info in struct gfs2_log_header_host Abhi Das
2020-08-13 20:01 ` [Cluster-devel] [PATCH 3/3] gfs2: Recover statfs info in journal head Abhi Das
2020-08-19 17:27   ` Bob Peterson
2020-08-20 11:07     ` Abhijith Das

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=165825613.12780098.1597856846775.JavaMail.zimbra@redhat.com \
    --to=rpeterso@redhat.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 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).