xfs
[Top] [All Lists]

Re: [RFC] unifying write variants for filesystems

To: Zach Brown <zab@xxxxxxxxxx>
Subject: Re: [RFC] unifying write variants for filesystems
From: Kent Overstreet <kmo@xxxxxxxxxxxxx>
Date: Tue, 4 Feb 2014 09:35:06 -0800
Cc: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>, Steve French <sfrench@xxxxxxxxx>, Sage Weil <sage@xxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, Anton Altaparmakov <anton@xxxxxxxxxx>, Al Viro <viro@xxxxxxxxxxxxxxxxxx>, Mark Fasheh <mfasheh@xxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, Joel Becker <jlbec@xxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140204172723.GA11325@xxxxxxxxxxxxxxxxxxxx>
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> <20140204172723.GA11325@xxxxxxxxxxxxxxxxxxxx>


On Feb 4, 2014 6:27 PM, "Zach Brown" <zab@xxxxxxxxxx> wrote:
>
> > 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.)

Yeah, precisely. I think we can push the point at which pages are pinned at least a fair but higher than it is now, and if we can do that we definitely should be working with a generic "bag of pinned pages" struct - and much better to use struct bio than add another one. Bios may not be perfect but at least some of the block layer specific cruft can be gotten rid of (and is on my todo list)

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

*cuts you*

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