[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091218125047U.fujita.tomonori@lab.ntt.co.jp>
Date: Fri, 18 Dec 2009 12:51:15 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: david@...morbit.com
Cc: fujita.tomonori@....ntt.co.jp, James.Bottomley@...e.de,
jens.axboe@...cle.com, torvalds@...ux-foundation.org,
tytso@....edu, kyle@...artin.ca, linux-parisc@...r.kernel.org,
linux-kernel@...r.kernel.org, hch@...radead.org,
linux-arch@...r.kernel.org
Subject: Re: [git patches] xfs and block fixes for virtually indexed arches
On Fri, 18 Dec 2009 13:44:40 +1100
Dave Chinner <david@...morbit.com> wrote:
> > > So it sounds like we only need a blk_rq_map_vmalloc() using the same
> > > techniques as the patch set and we're good to go.
> >
> > I'm not sure about it.
> >
> > As I said before (when I was against this 'adding vmalloc support to
> > the block layer' stuff), are there potential users of this except for
> > XFS? Are there anyone who does such a thing now?
>
> As Christoph already mentioned, XFS is not passing the vmalloc'd
> range to the block layer
Oops, I should have said a vmalloc/vmap area.
> > This API might be useful for only journaling file systems using log
> > formats that need large contiguous buffer. Sound like only XFS?
>
> FWIW, mapped buffers larger than PAGE_SIZE are used for more than just log
> recovery in XFS. e.g. filesystems with directory block size larger
> than page size uses mapped buffers.
I see, thanks.
--
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/
Powered by blists - more mailing lists