From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: [PATCH 00/31] Swap over NFS -v20 Date: Fri, 2 Oct 2009 15:52:16 +1000 Message-ID: <19141.38160.888705.175222@notabene.brown> References: <1254405858-15651-1-git-send-email-sjayaraman@suse.de> <20091001174201.GA30068@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Suresh Jayaraman , Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Miklos Szeredi , Wouter Verhelst , Peter Zijlstra , trond.myklebust@fys.uio.no To: Christoph Hellwig Return-path: In-Reply-To: message from Christoph Hellwig on Thursday October 1 Sender: owner-linux-mm@kvack.org List-Id: netdev.vger.kernel.org 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: email@kvack.org