[Top] [All Lists]

Re: [RFC] unifying write variants for filesystems

To: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC] unifying write variants for filesystems
From: Zach Brown <zab@xxxxxxxxxx>
Date: Tue, 4 Feb 2014 09:27:23 -0800
Cc: Kent Overstreet <kmo@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Mark Fasheh <mfasheh@xxxxxxxx>, Joel Becker <jlbec@xxxxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Sage Weil <sage@xxxxxxxxxxx>, Steve French <sfrench@xxxxxxxxx>, Anton Altaparmakov <anton@xxxxxxxxxx>, Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140204151728.GH10323@xxxxxxxxxxxxxxxxxx>
References: <CA+55aFzM0N7WjqnLNnuqTkbj3iws9f3bYxei=ZBCM8hvps4zYg@xxxxxxxxxxxxxx> <20140118201031.GI10323@xxxxxxxxxxxxxxxxxx> <20140119051335.GN10323@xxxxxxxxxxxxxxxxxx> <20140120135514.GA21567@xxxxxxxxxxxxx> <CA+55aFzEA-eM9v2PvsWx4v4ANaKXuRGYyGCkegJg++rhtHvnig@xxxxxxxxxxxxxx> <20140201224301.GS10323@xxxxxxxxxxxxxxxxxx> <52EFC271.3090205@xxxxxxxxxx> <20140204124409.GG10323@xxxxxxxxxxxxxxxxxx> <20140204125220.GB12440@kmo-pixel> <20140204151728.GH10323@xxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
> I definitely don't buy "bio is a natural object for carrying an array
> of pieces of pages"; not sure if that's what you implied in earlier
> thread, but it has too much baggage from block subsystem *and* it lacks
> the things we may want to associate with individual elements of such
> array (starting with "how can I steal that page?" method).

I think Kent is talking about what happens after the user addresses are
consumed.  Turning dio into more of a bio mapping and redirection engine
would use more of the bio machinery instead of the bits that dio has
implemented itself with state in struct dio that hangs off the bios.  I
imagine it'd still make sense to clean up the addresses/pages arguments
that feed that engine.  (And give another entry point that already has
bios for callers like loop, etc.)

> BTW, folks, any suggestions about the name of that "memory stream" thing?
> struct iov_iter really implies iterator for iovec and more generic name
> would probably be better...  struct mem_stream would probably do if nobody
> comes up with better variant, but it's long and somewhat clumsy...

I don't like 'stream'.  To me that sounds more strictly advancing than I
think this'd be capable of.  Maybe something dirt simple like 'mem_vec'?
With 'mvec_' call prefixes?

Or kiobuf!  *runs*

- z

<Prev in Thread] Current Thread [Next in Thread>