linux-kernel - Re: [PATCH v3 00/22] loop: Issue O_DIRECT aio using bio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20121023130451.GB21594@infradead.org>
Date:	Tue, 23 Oct 2012 09:04:52 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Dave Kleikamp <dave.kleikamp@...cle.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Zach Brown <zab@...bo.net>,
	"Maxim V. Patlasov" <mpatlasov@...allels.com>
Subject: Re: [PATCH v3 00/22] loop: Issue O_DIRECT aio using bio_vec

On Mon, Oct 22, 2012 at 10:15:00AM -0500, Dave Kleikamp wrote:
> This is the current version of the patchset I presented at the LSF-MM
> Summit in San Francisco in April. I apologize for letting it go so
> long before re-submitting.
> 
> This patchset was begun by Zach Brown and was originally submitted for
> review in October, 2009. Feedback was positive, and I have picked up
> where he left off, porting his patches to the latest mainline kernel
> and adding support more file systems.
> 
> This patch series adds a kernel interface to fs/aio.c so that kernel code can
> issue concurrent asynchronous IO to file systems.  It adds an aio command and
> file system methods which specify io memory with pages instead of userspace
> addresses.
> 
> This series was written to reduce the current overhead loop imposes by
> performing synchronus buffered file system IO from a kernel thread.  These
> patches turn loop into a light weight layer that translates bios into iocbs.
> 
> The downside of this is that in its current implementation, performance takes
> a big hit for non-synchonous I/O, since the underlying page cache is bypassed.
> The tradeoff is that all writes to the loop device make it to the underlying
> media, making loop-mounted file systems recoverable.

It also seems to still not fully kill thr old aio_read/write codepath.
At least XFS isn't touched yet.  It also doesn't seem to kill the nasty
hack for in-kernel direct I/O introduced with the swap over nfs code
(grep for REQ_KERNEL / KERNEL_READ / KERNEL_WRITE)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/