Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

mpage_readpages(9) [centos man page]

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 3.10 June 2014 MPAGE_READPAGES(9)

Check Out this Related Man Page

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

NAME
sync_file_range - sync a file segment with disk SYNOPSIS
#define _GNU_SOURCE #include <fcntl.h> int sync_file_range(int fd, off64_t offset, off64_t nbytes, unsigned int flags); DESCRIPTION
sync_file_range() permits fine control when synchronizing the open file referred to by the file descriptor fd with disk. offset is the starting byte of the file range to be synchronized. nbytes specifies the length of the range to be synchronized, in bytes; if nbytes is zero, then all bytes from offset through to the end of file are synchronized. Synchronization is in units of the system page size: offset is rounded down to a page boundary; (offset+nbytes-1) is rounded up to a page boundary. The flags bit-mask argument can include any of the following values: SYNC_FILE_RANGE_WAIT_BEFORE Wait upon write-out of all pages in the specified range that have already been submitted to the device driver for write-out before performing any write. SYNC_FILE_RANGE_WRITE Initiate write-out of all dirty pages in the specified range which are not presently submitted write-out. Note that even this may block if you attempt to write more than request queue size. SYNC_FILE_RANGE_WAIT_AFTER Wait upon write-out of all pages in the range after performing any write. Specifying flags as 0 is permitted, as a no-op. Warning This system call is extremely dangerous and should not be used in portable programs. None of these operations writes out the file's meta- data. Therefore, unless the application is strictly performing overwrites of already-instantiated disk blocks, there are no guarantees that the data will be available after a crash. There is no user interface to know if a write is purely an overwrite. On file systems using copy-on-write semantics (e.g., btrfs) an overwrite of existing allocated blocks is impossible. When writing into preallocated space, many file systems also require calls into the block allocator, which this system call does not sync out to disk. This system call does not flush disk write caches and thus does not provide any data integrity on systems with volatile disk write caches. Some details SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any I/O errors or ENOSPC conditions and will return these to the caller. Useful combinations of the flags bits are: SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE Ensures that all pages in the specified range which were dirty when sync_file_range() was called are placed under write-out. This is a start-write-for-data-integrity operation. SYNC_FILE_RANGE_WRITE Start write-out of all dirty pages in the specified range which are not presently under write-out. This is an asynchronous flush- to-disk operation. This is not suitable for data integrity operations. SYNC_FILE_RANGE_WAIT_BEFORE (or SYNC_FILE_RANGE_WAIT_AFTER) Wait for completion of write-out of all pages in the specified range. This can be used after an earlier SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE operation to wait for completion of that operation, and obtain its result. SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE | SYNC_FILE_RANGE_WAIT_AFTER This is a write-for-data-integrity operation that will ensure that all pages in the specified range which were dirty when sync_file_range() was called are committed to disk. RETURN VALUE
On success, sync_file_range() returns 0; on failure -1 is returned and errno is set to indicate the error. ERRORS
EBADF fd is not a valid file descriptor. EINVAL flags specifies an invalid bit; or offset or nbytes is invalid. EIO I/O error. ENOMEM Out of memory. ENOSPC Out of disk space. ESPIPE fd refers to something other than a regular file, a block device, a directory, or a symbolic link. VERSIONS
sync_file_range() appeared on Linux in kernel 2.6.17. CONFORMING TO
This system call is Linux-specific, and should be avoided in portable programs. SEE ALSO
fdatasync(2), fsync(2), msync(2), sync(2), feature_test_macros(7) COLOPHON
This page is part of release 3.25 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2010-01-17 SYNC_FILE_RANGE(2)

Featured Tech Videos