Re: [RFC] unifying write variants for filesystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 04, 2014 at 09:35:06AM -0800, Kent Overstreet wrote:
> > 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)

How far up?  I've no problem with having that done in ->direct_IO()
(especially if it would take this mem_vec/mem_stream/whatever and
keep the code doing actual pinning and building an array of pages
outside of direct-io.c, allowing it to do different things for iovec-backed
and page-array-backed variants), but I really don't like the idea of
lifting that to callers of ->direct_IO(), let alone past them.

If nothing else, we do *not* want to pin the entire write request, so
lifting that to e.g. generic_file_aio_write() (or, worse, its callers)
wouldn't make sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux