linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Bob Peterson <rpeterso-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	osd-dev-yNzVSZO3znNg9hUCZPvPmw@public.gmane.org,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	ross zwisler
	<ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org,
	jack-IBi9RG/b67k@public.gmane.org,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
	corbet-T1hC0tSOHrs@public.gmane.org,
	neilb-l3A5Bk7waGM@public.gmane.org,
	clm-b10kYP2dOMg@public.gmane.org,
	tytso-3s7WtUTddSA@public.gmane.org,
	axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org
Subject: Re: [PATCH v3 20/20] gfs2: clean up some filemap_* calls
Date: Mon, 24 Apr 2017 13:52:36 -0400	[thread overview]
Message-ID: <1493056356.2895.19.camel@redhat.com> (raw)
In-Reply-To: <2092108386.509535.1493055674293.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Mon, 2017-04-24 at 13:41 -0400, Bob Peterson wrote:
> Hi,
> 
> ----- Original Message -----
> > On Mon, 2017-04-24 at 10:12 -0400, Bob Peterson wrote:
> > > > +	filemap_write_and_wait_range(mapping, gl->gl_vm.start, gl->gl_vm.end);
> > > 
> > > This should probably have "error = ", no?
> > > 
> > 
> > This error is discarded in the current code after resetting the error in
> > the mapping. With the earlier patches in this set we don't need to reset
> > the error like this anymore.
> > 
> > Now, if this code should doing something else with those errors, then
> > that's a separate problem.
> 
> Okay, I see. My bad.
>  
> > > >  	gfs2_ail_empty_gl(gl);
> > > >  
> > > >  	spin_lock(&gl->gl_lockref.lock);
> > > > @@ -225,12 +223,10 @@ static void inode_go_sync(struct gfs2_glock *gl)
> > > >  	filemap_fdatawrite(metamapping);
> > > >  	if (ip) {
> > > >  		struct address_space *mapping = ip->i_inode.i_mapping;
> > > > -		filemap_fdatawrite(mapping);
> > > > -		error = filemap_fdatawait(mapping);
> > > > -		mapping_set_error(mapping, error);
> > > > +		filemap_write_and_wait(mapping);
> > > > +	} else {
> > > > +		filemap_fdatawait(metamapping);
> > > >  	}
> > > > -	error = filemap_fdatawait(metamapping);
> > > > -	mapping_set_error(metamapping, error);
> > > 
> > > This part doesn't look right at all. There's a big difference in gfs2
> > > between
> > > mapping and metamapping. We need to wait for metamapping regardless.
> > > 
> > 
> > ...and this should wait. Basically, filemap_write_and_wait does
> > filemap_fdatawrite and then filemap_fdatawait. This is mostly just
> > replacing the existing code with a more concise helper.
> 
> But this isn't a simple replacement with a helper. This is two different
> address spaces (mapping and metamapping) and you added an else in there.
> 
> So with this patch metamapping gets written, and if there's an ip,
> mapping gets written but it doesn't wait for metamapping. Unless
> I'm missing something.
> 
> You could replace both filemap_fdatawrites with the helper instead.
> Today's code is structured as:
> 
> (a) write metamapping
> if (ip)
>     (b) write mapping
>     (c) wait for mapping
> (d) wait for metamapping
> 
> If you use the helper for both, it becomes, (a & d)(b & c) which is probably
> acceptable. (I think we just tried to optimize what the elevator was doing).
> 
> But the way you've got it coded here still looks wrong. It looks like:
> (a)
> if (ip)
>    (b & c)
> ELSE -
>    (d)
> 
> So (d) (metamapping) isn't guaranteed to be synced at the end of the function.
> Of course, you know the modified helper functions better than I do.
> What am I missing?
> 
> 

<facepalm>
You're right of course. I'll fix that up in my tree.

Thanks!
-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      parent reply	other threads:[~2017-04-24 17:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 13:22 [PATCH v3 00/20] fs: introduce new writeback error reporting and convert existing API as a wrapper around it Jeff Layton
2017-04-24 13:22 ` [PATCH v3 01/20] mm: drop "wait" parameter from write_one_page Jeff Layton
2017-04-24 15:22   ` Christoph Hellwig
2017-04-24 13:22 ` [PATCH v3 02/20] mm: fix mapping_set_error call in me_pagecache_dirty Jeff Layton
2017-04-24 15:22   ` Christoph Hellwig
2017-04-24 13:22 ` [PATCH v3 03/20] buffer: use mapping_set_error instead of setting the flag Jeff Layton
2017-04-24 15:22   ` Christoph Hellwig
2017-04-24 13:22 ` [PATCH v3 04/20] fs: check for writeback errors after syncing out buffers in generic_file_fsync Jeff Layton
2017-04-24 15:23   ` Christoph Hellwig
2017-04-24 15:46   ` Jan Kara
2017-04-24 13:22 ` [PATCH v3 05/20] orangefs: don't call filemap_write_and_wait from fsync Jeff Layton
2017-04-24 15:23   ` Christoph Hellwig
2017-04-24 18:18     ` Mike Marshall
2017-04-24 13:22 ` [PATCH v3 06/20] dax: set errors in mapping when writeback fails Jeff Layton
2017-04-24 15:24   ` Christoph Hellwig
2017-04-24 15:54   ` Jan Kara
2017-04-24 19:16   ` Ross Zwisler
2017-04-24 13:22 ` [PATCH v3 07/20] nilfs2: set the mapping error when calling SetPageError on writeback Jeff Layton
2017-04-24 15:24   ` Christoph Hellwig
2017-04-24 13:22 ` [PATCH v3 08/20] mm: ensure that we set mapping error if writeout() fails Jeff Layton
2017-04-24 15:24   ` Christoph Hellwig
2017-04-24 15:56   ` Jan Kara
2017-04-24 13:22 ` [PATCH v3 09/20] 9p: set mapping error when writeback fails in launder_page Jeff Layton
2017-04-24 15:24   ` Christoph Hellwig
2017-04-24 15:57   ` Jan Kara
2017-04-24 13:22 ` [PATCH v3 10/20] fuse: set mapping error in writepage_locked when it fails Jeff Layton
2017-04-24 15:25   ` Christoph Hellwig
2017-04-24 16:04   ` Jan Kara
2017-04-24 17:14     ` Jeff Layton
2017-04-25  8:17       ` Jan Kara
2017-04-25 10:35         ` Jeff Layton
2017-04-25 11:19           ` Jan Kara
2017-04-25 16:43             ` Jeff Layton
2017-04-24 13:22 ` [PATCH v3 11/20] cifs: set mapping error when page writeback fails in writepage or launder_pages Jeff Layton
2017-04-24 15:27   ` Christoph Hellwig
2017-04-24 17:16     ` Jeff Layton
2017-04-24 13:22 ` [PATCH v3 12/20] lib: add errseq_t type and infrastructure for handling it Jeff Layton
2017-04-24 13:22 ` [PATCH v3 13/20] fs: new infrastructure for writeback error handling and reporting Jeff Layton
2017-04-24 13:22 ` [PATCH v3 14/20] fs: retrofit old error reporting API onto new infrastructure Jeff Layton
2017-04-24 13:22 ` [PATCH v3 15/20] mm: remove AS_EIO and AS_ENOSPC flags Jeff Layton
2017-04-24 13:22 ` [PATCH v3 16/20] mm: don't TestClearPageError in __filemap_fdatawait_range Jeff Layton
2017-04-24 13:22 ` [PATCH v3 17/20] cifs: cleanup writeback handling errors and comments Jeff Layton
2017-04-24 13:22 ` [PATCH v3 18/20] mm: clean up error handling in write_one_page Jeff Layton
2017-04-24 13:22 ` [PATCH v3 19/20] jbd2: don't reset error in journal_finish_inode_data_buffers Jeff Layton
2017-04-24 13:22 ` [PATCH v3 20/20] gfs2: clean up some filemap_* calls Jeff Layton
2017-04-24 14:12   ` Bob Peterson
2017-04-24 16:59     ` Jeff Layton
2017-04-24 17:41       ` Bob Peterson
     [not found]         ` <2092108386.509535.1493055674293.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-24 17:52           ` Jeff Layton [this message]

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=1493056356.2895.19.camel@redhat.com \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
    --cc=clm-b10kYP2dOMg@public.gmane.org \
    --cc=cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=corbet-T1hC0tSOHrs@public.gmane.org \
    --cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=jack-IBi9RG/b67k@public.gmane.org \
    --cc=jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org \
    --cc=neilb-l3A5Bk7waGM@public.gmane.org \
    --cc=osd-dev-yNzVSZO3znNg9hUCZPvPmw@public.gmane.org \
    --cc=ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=rpeterso-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=tytso-3s7WtUTddSA@public.gmane.org \
    --cc=v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /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).