All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	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:47:22 +0200	[thread overview]
Message-ID: <20191026054722.GA14648@lst.de> (raw)
In-Reply-To: <20191025204329.GF4614@dread.disaster.area>

On Sat, Oct 26, 2019 at 07:43:29AM +1100, Dave Chinner wrote:
> 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....

Last time I talked to the NFS folks there still were some very obscure
v2 use cases left (embedded devices that can't be upgraded).

But yeah, I'll add a patch to stop overriding rsize/wsize with the
sync option.

  reply	other threads:[~2019-10-26  5:47 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
2019-10-26  5:47       ` Christoph Hellwig [this message]
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=20191026054722.GA14648@lst.de \
    --to=hch@lst.de \
    --cc=david@fromorbit.com \
    --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 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.