On Tue, May 29, 2012 at 06:38:39AM +0900, Tejun Heo wrote: > On Mon, May 28, 2012 at 05:27:33PM -0400, Mikulas Patocka wrote: > > > Isn't it more like you shouldn't be sending read requested by user and > > > read ahead in the same bio? > > > > If the user calls read with 512 bytes, you would send bio for just one > > sector. That's too small and you'd get worse performance because of higher > > command overhead. You need to send larger bios. > > All modern FSes are page granular, so the granularity would be > per-page. Most modern filesystems support sparse files and block sizes smaller than page size, so a single page may require multiple unmergable bios to fill all the data in them. Hence IO granularity is definitely not per-page even though that is the granularity of the page cache. > Also, RAHEAD is treated differently in terms of > error-handling. Do filesystems implement their own rahead > (independent from the common logic in vfs layer) on their own? Yes. Keep in mind there is no rule that says filesystems must use the generic IO paths, or even the page cache for that matter. Indeed, XFS (and I think btrfs now) do no use the page cache for their metadata caching and IO. So just off the top of my head, XFS has it's own readahead for metadata constructs (btrees, directory data, etc) , and btrfs implements it's own readpage/readpages and readahead paths (see the btrfs compression support, for example). And FWIW, XFS has variable sized metadata, so to complete the circle, some metadata requires sector granularity, some filesystem block size granularity, and some multiple page granularity. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
