From: Alex Elder <aelder@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: fix buffer flushing during unmount
Date: Tue, 4 Oct 2011 22:55:42 -0500 [thread overview]
Message-ID: <1317786942.2270.8.camel@doink> (raw)
In-Reply-To: <20110928163437.GA1530@infradead.org>
On Wed, 2011-09-28 at 12:34 -0400, Christoph Hellwig wrote:
> On Mon, Sep 19, 2011 at 12:33:20PM -0500, Alex Elder wrote:
> > On Wed, 2011-09-14 at 10:08 -0400, Christoph Hellwig wrote:
> > > The code to flush buffers in the umount code is a bit iffy: we first flush
> > > all delwri buffers out, but then might be able to queue up a new one when
> > > logging the sb counts. On a normal shutdown that one would get flushed
> > > out when doing the synchronous superblock write in xfs_unmountfs_writesb,
> > > but we skip that one if the filesystem has been shut down.
> > >
> > > Fix this by moving the delwri list flushing until just before unmounting
> > > the log, and while we're at it also remove the superflous delwri list
> > > and buffer lru flusing for the rt and log device that can never have
> > > cached or delwri buffers.
> >
> > What prevents blocks on a realtime device from being cached?
>
> Note that cached here means using buffers that end up in the rbtree
> and/or on the lru. We simply never do that for the rt and log device,
> as that would mean complicating the code for no reason - the only
> time we ever use buffer on the rt device is for the size check during
> mount and the _uncached variant where we free the buffer after the
> refcount hits zero is just fine for that, and xfs_zero_remaining_bytes,
> which actually operates on a regular file and thus must not use the
> rbtree or the lru (and should eventually stop using buffer routines at
> all). All actual metadata which the buffer cache is used for resides
> on the main device. Log buffers stay alive from mount to unmount so
> we're fine with that interface as well.
And now that you've said that I see that there are in fact
no calls to xfs_buf_get() that specify anything other than
the data device.
> >
> > I haven't looked exhaustively, but it looks like the summary
> > and bitmap data are operated on without caching, but the
> > realtime data itself is treated no different from "normal"
> > data blocks.
>
> The buffer cache is never used for actual file data.
OK, I get it. Your original patch looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-10-05 3:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-14 14:08 [PATCH] xfs: fix buffer flushing during unmount Christoph Hellwig
2011-09-19 17:33 ` Alex Elder
2011-09-28 16:34 ` Christoph Hellwig
2011-10-05 3:55 ` Alex Elder [this message]
2011-10-12 4:45 ` Amit Sahrawat
2011-10-16 12:38 ` Christoph Hellwig
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=1317786942.2270.8.camel@doink \
--to=aelder@sgi.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.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.