page_cache_next_hole(9) [centos man page]

PAGE_CACHE_NEXT_HOLE(9) 				    Memory Management in Linux					   PAGE_CACHE_NEXT_HOLE(9)

NAME

       page_cache_next_hole - find the next hole (not-present entry)

SYNOPSIS

       pgoff_t page_cache_next_hole(struct address_space * mapping, pgoff_t index, unsigned long max_scan);

ARGUMENTS

       mapping
	   mapping

       index
	   index

       max_scan
	   maximum range to search

DESCRIPTION

       Search the set [index, min(index+max_scan-1, MAX_INDEX)] for the lowest indexed hole.

RETURNS

       the index of the hole if found, otherwise returns an index outside of the set specified (in which case 'return - index >= max_scan' will be
       true). In rare cases of index wrap-around, 0 will be returned.

       page_cache_next_hole may be called under rcu_read_lock. However, like radix_tree_gang_lookup, this will not atomically search a snapshot of
       the tree at a single point in time. For example, if a hole is created at index 5, then subsequently a hole is created at index 10,
       page_cache_next_hole covering both indexes may return 10 if called under rcu_read_lock.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   PAGE_CACHE_NEXT_HOLE(9)

MPAGE_READPAGES(9)						   The Linux VFS						MPAGE_READPAGES(9)

NAME

       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)