| To: | Christoph Hellwig <hch@xxxxxx> |
|---|---|
| Subject: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache |
| From: | Al Viro <viro@xxxxxxxxxxxxxxxxxx> |
| Date: | Sat, 25 Apr 2015 15:57:28 +0100 |
| Cc: | Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20150425141612.GA4153@xxxxxx> |
| References: | <1429816064-10033-1-git-send-email-hch@xxxxxx> <1429816064-10033-6-git-send-email-hch@xxxxxx> <20150423222942.GK15810@dastard> <20150425141612.GA4153@xxxxxx> |
| Sender: | Al Viro <viro@xxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Sat, Apr 25, 2015 at 04:16:12PM +0200, Christoph Hellwig wrote: > Al, what do you think about adding a new > > i_link member to the union of i_pipe, i_bdev and i_cdev. That we > we can cache a link acquired by any way for direct use in the VFS. > > This has a few use cases: inline links can be set up directly > when reading the inode, and we never need to call into ->follow_link. > > Formats like the XFS v5 symlinks can be read in once by whatever > way we want, and following accesses can be done RCU safe and > without calling into the filesystem. > > Note that caching the symlink in a kmalloc'ed buffer might be > more efficient than the pagecache for most cases anyway. Hmm... When would you free the sucker? |
| Previous by Date: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache, Al Viro |
| Previous by Thread: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache, Al Viro |
| Indexes: | [Date] [Thread] [Top] [All Lists] |