diff options
| author | Matthew Wilcox (Oracle) <willy@infradead.org> | 2022-04-29 11:12:16 -0400 |
|---|---|---|
| committer | Matthew Wilcox (Oracle) <willy@infradead.org> | 2022-05-09 16:21:45 -0400 |
| commit | 5aab331ad68f7cad432f350c6b28f0b5a9c777fc (patch) | |
| tree | 8c0854c2733a4b6ef160d0b1f02d42b3f9f99686 /fs/cramfs | |
| parent | 65c0d259cb1721c49387f1db97245d5228616a16 (diff) | |
cramfs: Convert cramfs to read_folio
This is a "weak" conversion which converts straight back to using pages.
A full conversion should be performed at some point, hopefully by
someone familiar with the filesystem.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Diffstat (limited to 'fs/cramfs')
| -rw-r--r-- | fs/cramfs/README | 8 | ||||
| -rw-r--r-- | fs/cramfs/inode.c | 7 |
2 files changed, 8 insertions, 7 deletions
diff --git a/fs/cramfs/README b/fs/cramfs/README index d71b27e0ff15..778df5c4d70b 100644 --- a/fs/cramfs/README +++ b/fs/cramfs/README @@ -115,7 +115,7 @@ Block Size (Block size in cramfs refers to the size of input data that is compressed at a time. It's intended to be somewhere around -PAGE_SIZE for cramfs_readpage's convenience.) +PAGE_SIZE for cramfs_read_folio's convenience.) The superblock ought to indicate the block size that the fs was written for, since comments in <linux/pagemap.h> indicate that @@ -161,7 +161,7 @@ size. The options are: PAGE_SIZE. It's easy enough to change the kernel to use a smaller value than -PAGE_SIZE: just make cramfs_readpage read multiple blocks. +PAGE_SIZE: just make cramfs_read_folio read multiple blocks. The cost of option 1 is that kernels with a larger PAGE_SIZE value don't get as good compression as they can. @@ -173,9 +173,9 @@ they don't mind their cramfs being inaccessible to kernels with smaller PAGE_SIZE values. Option 3 is easy to implement if we don't mind being CPU-inefficient: -e.g. get readpage to decompress to a buffer of size MAX_BLKSIZE (which +e.g. get read_folio to decompress to a buffer of size MAX_BLKSIZE (which must be no larger than 32KB) and discard what it doesn't need. -Getting readpage to read into all the covered pages is harder. +Getting read_folio to read into all the covered pages is harder. The main advantage of option 3 over 1, 2, is better compression. The cost is greater complexity. Probably not worth it, but I hope someone diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c index 666aa380011e..7ae59a6afc5c 100644 --- a/fs/cramfs/inode.c +++ b/fs/cramfs/inode.c @@ -414,7 +414,7 @@ static int cramfs_physmem_mmap(struct file *file, struct vm_area_struct *vma) /* * Let's create a mixed map if we can't map it all. * The normal paging machinery will take care of the - * unpopulated ptes via cramfs_readpage(). + * unpopulated ptes via cramfs_read_folio(). */ int i; vma->vm_flags |= VM_MIXEDMAP; @@ -814,8 +814,9 @@ out: return d_splice_alias(inode, dentry); } -static int cramfs_readpage(struct file *file, struct page *page) +static int cramfs_read_folio(struct file *file, struct folio *folio) { + struct page *page = &folio->page; struct inode *inode = page->mapping->host; u32 maxblock; int bytes_filled; @@ -925,7 +926,7 @@ err: } static const struct address_space_operations cramfs_aops = { - .readpage = cramfs_readpage + .read_folio = cramfs_read_folio }; /* |