| To: | Christoph Hellwig <hch@xxxxxx> |
|---|---|
| Subject: | Re: [PATCH 5/6] xfs: move non-inline symlinks to the pagecache |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Fri, 24 Apr 2015 08:29:42 +1000 |
| Cc: | xfs@xxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <1429816064-10033-6-git-send-email-hch@xxxxxx> |
| References: | <1429816064-10033-1-git-send-email-hch@xxxxxx> <1429816064-10033-6-git-send-email-hch@xxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Thu, Apr 23, 2015 at 09:07:43PM +0200, Christoph Hellwig wrote:
> We can use the generic symlink in pagecache code for XFS non-inline
> symlinks. Because links are always shorter than a page we will
> get the zero termination for the link for free.
Doesn't work for v5 filesystems where headers and CRCs are embedded
into the same blocks as the symlink data. i.e. this now falls down
to ->readpage to read the link data into the page cache, and that
just reads the entire blocks into the page cache. So what we can end
up within the page cache is this:
4k block/page
+---|--------------+
hdr symlink data
And for a 1k block size v5 filesystem it could be this within a 4k
page:
1k block 1k block
+---|--------------+----|---------------+
hdr symlink data hdr symlink data
Either way, it will be completely misinterpretted by the generic
symlink code...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|
| Previous by Date: | Re: [PATCH] xfs: call xfs_idestroy_fork() in xfs_ilock() critical section, Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH v2] xfs: always log the inode on unwritten extent conversion, Dave Chinner |
| Previous by Thread: | [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, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |