Messages in this thread | | | Date | Fri, 18 Dec 2009 19:24:12 +0900 | Subject | Re: [git patches] xfs and block fixes for virtually indexed arches | From | FUJITA Tomonori <> |
| |
On Fri, 18 Dec 2009 11:01:29 +0100 James Bottomley <James.Bottomley@suse.de> wrote:
> > Yeah, but now only XFS passes vmap'ed pages to the block layer. Isn't > > it better to wait until we have real users of the API? > > XFS is a real user ... the XFS filesystem is our most trusted code base > that can break the 8TB limit, which hard disks are already at. Ext4 may > be ready, but it's not universally present in enterprise distros like > XFS.
XFS already has the own code to handle that, which works fine (with your patchset except for 5/6 for the block layer). Not much motivation for XFS to move to the generic API?
> > > That would ensure the architecturally > > > correct flushing of the aliases, and would satisfy the expectations of > > > blk_rq_map_kern(). The down side is that vmap/vmalloc set up and clear > > > page tables, which isn't necessary and might impact performance (xfs > > > people?) > > > > btw, I'm not sure that the existing blk_rq_map_* API isn't fit well to > > file systems since blk_rq_map_user and blk_rq_map_kern takes a request > > structure. > > OK, so that was illustrative. The meat of the change is at the bio > layer anyway (fss tend to speak bios).
Yeah, I think so, it's up to Jens to add new APIs for vmap there.
| |