From: Neil Brown <neilb@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Suresh Jayaraman <sjayaraman@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org, Miklos Szeredi <mszeredi@suse.cz>,
Wouter Verhelst <w@uter.be>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
trond.myklebust@fys.uio.no
Subject: Re: [PATCH 00/31] Swap over NFS -v20
Date: Fri, 2 Oct 2009 15:52:16 +1000 [thread overview]
Message-ID: <19141.38160.888705.175222@notabene.brown> (raw)
In-Reply-To: message from Christoph Hellwig on Thursday October 1
On Thursday October 1, hch@infradead.org wrote:
>
> The other really big one is adding a proper method for safe, page-backed
> kernelspace I/O on files. That is not something like the grotty
> swap-tied address_space operations in this patch, but more something in
> the direction of the kernel direct I/O patches from Jenx Axboe he did
> for using in the loop driver. But even those aren't complete as they
> don't touch the locking issue yet.
Do you have a problem with the proposed address_space operations apart
from their names including the word "swap"? Would something like:
direct_on, direct_off, direct_read, direct_write
be better.
Semantics being that the read and write:
- bypass the page cache (invalidation is up to caller)
- must not make a blocking non-emergency memory allocation
direct_on does any pre-allocation and pre-reading to ensure those
semantics and be provided.
I have wondered if an extra flag along the lines of "I don't care
about this data after a crash" would be useful.
It would be set for swap, but not set for other users. Thus
e.g. RAID1 could easily avoid resyncing an area that was used only for
swap.
The only thing of Jens' that I could find used bmap - is there
something more recent I should look for?
>
> Especially the latter is an absolutely essential step to make any
> progress here, and an excellent patch series of it's own as there are
> multiple users for this, like making swap safe on btrfs files, making
> the MD bitmap code actually safe or improving the loop driver.
100% agree.
Thanks,
NeilBrown
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-10-02 5:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 14:04 [PATCH 00/31] Swap over NFS -v20 Suresh Jayaraman
2009-10-01 17:42 ` Christoph Hellwig
2009-10-02 5:52 ` Neil Brown [this message]
2009-10-02 8:21 ` Suresh Jayaraman
2009-10-04 21:41 ` Peter Zijlstra
2009-10-10 12:06 ` Pavel Machek
2009-10-10 12:23 ` Peter Zijlstra
2009-10-10 21:10 ` Pavel Machek
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=19141.38160.888705.175222@notabene.brown \
--to=neilb@suse.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mszeredi@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=sjayaraman@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=trond.myklebust@fys.uio.no \
--cc=w@uter.be \
/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).