linux-kernel - Re: Approaches to making io

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Aug 2011 01:32:31 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Daniel Ehrenberg <dehrenberg@...gle.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Approaches to making io_submit not block

On Mon, Aug 29, 2011 at 10:33:24AM -0700, Daniel Ehrenberg wrote:
> - Blocking due to reading metadata.
> Proposed solution:
> Add a per-ioctx work queue to do metadata reads. It will be triggered
> from the dio code: if in async mode, then get_block will be called
> with an additional flag, meaning something like O_NONBLOCK on sockets.
> File systems' get_block functions can implement this flag and return
> -EAGAIN if a read from the underlying device would be necessary. (If
> we're worried that EAGAIN might be used for other purposes in the
> future, we could make a new errno for this purpose.) From a quick
> glance at the code, it looks like this would not be too difficult to
> add to ext4 for extent-based files, and support in other file systems
> could be added gradually. If -EAGAIN is returned, then the struct dio
> will be put on the work queue together with a description of what kind
> of processing it was doing. The work queue only serves the metadata
> request, and the rest of the request is served on the existing path.

Let filesystems handle this.  I've actually prototyped it in XFS,
based on some pending work from Dave but at this point it's still butt
ugly.

> - Blocking for appends and writes to file holes due to the need for a
> metadata write after the data write
> Proposed solution:
> Maintain a work queue for all appends and writes to file holes, which
> executes the current code.

No way.  I've fixed this for XFS, and it's trivial without the need to
queue them up.  The only thing preventing appending writes to work is
a flag to tell the dio layer to just do them, just like it already works
for holes.  (and more QA).

--
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/