linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-xfs@vger.kernel.org, Ian Kent <raven@themaw.net>
Subject: Re: [PATCH 3/7] xfs: remove the m_readio_log field from struct xfs_mount
Date: Sat, 26 Oct 2019 07:43:29 +1100	[thread overview]
Message-ID: <20191025204329.GF4614@dread.disaster.area> (raw)
In-Reply-To: <851dcbf3-afbf-77fa-bd6e-3e1a8ccba7c7@sandeen.net>

On Fri, Oct 25, 2019 at 01:26:05PM -0500, Eric Sandeen wrote:
> On 10/25/19 12:40 PM, Christoph Hellwig wrote:
> > The m_readio_log is only used for reporting the blksize (aka preferred
> > I/O size) in struct stat.  For all cases but a file system that does not
> > use stripe alignment, but which has the wsync and largeio mount option
> > set the value is the same as the write I/O size.
> > 
> > Remove the field and report a smaller preferred I/O size for that corner
> > case, which actually is the right thing to do for that case (except for
> > the fact that is probably is entirely unused).
> 
> hm, I wonder what the history of the WSYNC_ sizes are, tbh.  So while I can't
> speak to the need for a separate READIO_LOG or not, this doesn't seem 
> too far fetched...

NFSv2 had a maximum client IO size of 8kB and writes were
synchronous. The Irix NFS server had some magic in it (enabled by
the filesystem wsync mount option) that allowed clients to have two
sequential 8k writes in flight at once, allowing XFS to optimise for
16KB write IOs instead of the normal default of 64kB. This
optimisation was the reason that, at the time (early-mid 90s), SGI
machines had double the NFS write throughput of any other Unix
systems.

I'm surprised we still support NFSv2 at all in this day and age - I
suspect we should just kill NFSv2 altogether. We need to keep the
wsync option around for HA systems serving files to NFS and CIFS
clients, but the 8kB IO size optimisations can certainly die....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2019-10-25 20:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 17:40 decruft misc mount related code Christoph Hellwig
2019-10-25 17:40 ` [PATCH 1/7] xfs: cleanup stat blksize reporting Christoph Hellwig
2019-10-25 17:56   ` Eric Sandeen
2019-10-25 17:40 ` [PATCH 2/7] xfs: remove the unused m_readio_blocks field from struct xfs_mount Christoph Hellwig
2019-10-25 18:02   ` Eric Sandeen
2019-10-25 17:40 ` [PATCH 3/7] xfs: remove the m_readio_log " Christoph Hellwig
2019-10-25 18:26   ` Eric Sandeen
2019-10-25 20:43     ` Dave Chinner [this message]
2019-10-26  5:47       ` Christoph Hellwig
2019-10-25 17:40 ` [PATCH 4/7] xfs: remove the dsunit and dswidth variables in xfs_parseargs Christoph Hellwig
2019-10-25 18:29   ` Eric Sandeen
2019-10-25 17:40 ` [PATCH 5/7] xfs: remove the iosizelog variable " Christoph Hellwig
2019-10-25 18:35   ` Eric Sandeen
2019-10-25 19:03     ` Eric Sandeen
2019-10-26  5:47       ` Christoph Hellwig
2019-10-25 17:40 ` [PATCH 6/7] xfs: clean up setting m_readio_* / m_writeio_* Christoph Hellwig
2019-10-25 19:18   ` Eric Sandeen
2019-10-25 20:53     ` Dave Chinner
2019-10-27  2:23       ` Eric Sandeen
2019-10-25 17:40 ` [PATCH 7/7] xfs: reverse the polarity of XFS_MOUNT_COMPAT_IOSIZE Christoph Hellwig
2019-10-25 19:24   ` Eric Sandeen

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=20191025204329.GF4614@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=sandeen@sandeen.net \
    /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).