From: "hch@infradead.org" <hch@infradead.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "dan.aloni@vastdata.com" <dan.aloni@vastdata.com>,
"hch@infradead.org" <hch@infradead.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfs: add 'noextend' option for lock-less 'lost writes' prevention
Date: Wed, 19 Jun 2024 22:13:16 -0700 [thread overview]
Message-ID: <ZnO6bAJWqqp-ESfY@infradead.org> (raw)
In-Reply-To: <7b0eda741ac6d575db7d69da6b14799686e02c51.camel@hammerspace.com>
On Wed, Jun 19, 2024 at 06:03:02PM +0000, Trond Myklebust wrote:
> > So we end up compressing ~35000 RPC calls into one. Why is that not a
> > good thing?
> >
>
> BTW: this is not just a theoretical thing. Look at the way that glibc
> handles a size-extending fallocate() on filesystems that don't have
> native support, by writing a byte of information on every 4k boundary.
> That's not quite as dramatic as my 10 byte example above, but it still
> does reduce the number of required write RPC calls by a factor of 256.
That's a bit of a weird case to be honest, especially as it is an
invalid implementation of the fallocate semantics. At the same time
this slows down perfectly normal log file workloads that just append
a few bytes in every call as each of them gets blown up to 4k.
Maybe we'll need a heuristic for servers that don't support ALLOCATE
to work around the broken glibc behavior, but in general blowing up
writes to include potentially huge amounts of data seems like a really
bad default.
prev parent reply other threads:[~2024-06-20 5:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 15:33 [PATCH] nfs: add 'noextend' option for lock-less 'lost writes' prevention Dan Aloni
2024-06-18 18:59 ` Trond Myklebust
2024-06-19 8:37 ` Sagi Grimberg
2024-06-19 14:15 ` Trond Myklebust
2024-06-19 14:31 ` Sagi Grimberg
2024-06-20 5:27 ` Christoph Hellwig
2024-06-20 6:41 ` Sagi Grimberg
2024-06-20 5:26 ` Christoph Hellwig
2024-06-19 5:44 ` Christoph Hellwig
2024-06-19 13:33 ` Trond Myklebust
2024-06-19 18:03 ` Trond Myklebust
2024-06-20 5:13 ` hch [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=ZnO6bAJWqqp-ESfY@infradead.org \
--to=hch@infradead.org \
--cc=dan.aloni@vastdata.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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.