Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

mpage_readpages(9) [suse man page]


mpage_readpages - populate an address space with some pages & start reads against them SYNOPSIS
int mpage_readpages(struct address_space * mapping, struct list_head * pages, unsigned nr_pages, get_block_t get_block); ARGUMENTS
mapping the address_space pages The address of a list_head which contains the target pages. These pages have their ->index populated and are otherwise uninitialised. The page at pages->prev has the lowest file offset, and reads should be issued in pages->prev to pages->next order. nr_pages The number of pages at *pages get_block The filesystem's block mapper function. DESCRIPTION
This function walks the pages and the blocks within each page, building and emitting large BIOs. If anything unusual happens, such as: - encountering a page which has buffers - encountering a page which has a non-hole after a hole - encountering a page with non-contiguous blocks then this code just gives up and calls the buffer_head-based read function. It does handle a page which has holes at the end - that is a common case: the end-of-file on blocksize < PAGE_CACHE_SIZE setups. BH_BOUNDARY EXPLANATION There is a problem. The mpage read code assembles several pages, gets all their disk mappings, and then submits them all. That's fine, but obtaining the disk mappings may require I/O. Reads of indirect blocks, for example. So an mpage read of the first 16 blocks of an ext2 file will cause I/O to be SUBMITTED IN THE FOLLOWING ORDER
12 0 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16 because the indirect block has to be read to get the mappings of blocks 13,14,15,16. Obviously, this impacts performance. So what we do it to allow the filesystem's get_block function to set BH_Boundary when it maps block 11. BH_Boundary says: mapping of the block after this one will require I/O against a block which is probably close to this one. So you should push what I/O you have currently accumulated. This all causes the disk requests to be issued in the correct order. COPYRIGHT
Kernel Hackers Manual 2.6. July 2010 MPAGE_READPAGES(9)

Check Out this Related Man Page

READAHEAD(2)						     Linux Programmer's Manual						      READAHEAD(2)

readahead - perform file readahead into page cache SYNOPSIS
#define _GNU_SOURCE /* See feature_test_macros(7) */ #include <fcntl.h> ssize_t readahead(int fd, off64_t offset, size_t count); DESCRIPTION
readahead() populates the page cache with data from a file so that subsequent reads from that file will not block on disk I/O. The fd argument is a file descriptor identifying the file which is to be read. The offset argument specifies the starting point from which data is to be read and count specifies the number of bytes to be read. I/O is performed in whole pages, so that offset is effectively rounded down to a page boundary and bytes are read up to the next page boundary greater than or equal to (offset+count). readahead() does not read beyond the end of the file. readahead() blocks until the specified data has been read. The current file offset of the open file referred to by fd is left unchanged. RETURN VALUE
On success, readahead() returns 0; on failure, -1 is returned, with errno set to indicate the cause of the error. ERRORS
EBADF fd is not a valid file descriptor or is not open for reading. EINVAL fd does not refer to a file type to which readahead() can be applied. VERSIONS
The readahead() system call appeared in Linux 2.4.13; glibc support has been provided since version 2.3. CONFORMING TO
The readahead() system call is Linux-specific, and its use should be avoided in portable applications. NOTES
On some 32-bit architectures, the calling signature for this system call differs, for the reasons described in syscall(2). SEE ALSO
lseek(2), madvise(2), mmap(2), posix_fadvise(2), read(2) COLOPHON
This page is part of release 3.53 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at Linux 2013-04-01 READAHEAD(2)
Man Page