[Bug 206652] [ext2fs][patch] EXT4: sparse file fixes and mmap optimizations

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206652

            Bug ID: 206652
           Summary: [ext2fs][patch] EXT4: sparse file fixes and mmap
                    optimizations
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: damjan.jov at gmail.com
                CC: freebsd-fs at FreeBSD.org

Created attachment 166156
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166156&action=edit
fix handling files with sparse blocks before extent's index, and implement runb
in mmap

It turns out that the ei_blk on the first struct ext4_extent_index in an EXT4
file's root extent isn't 0 if the file starts with sparse blocks. This will
cause ext4_ext_binsearch_index() to keep passing the "if (lbn < m->ei_blk)"
test, moving r to the left, until r < l, then set "path->ep_index = l - 1;"
resulting in garbage data being read from wrong disk blocks since
path->ep_index is pointing to before the first element of the array.

I've attached a patch that keeps track of the first and last block in each
extent as it descends down the extent tree, thus being able to work out that
some blocks are sparse earlier, preventing the previous out of range problem.
Tracking the first and last block in each extent also lets us calculate where
sparse extents end better, passing larger values to read ahead in mmap.

In ext4_bmapext() I've also started supporting the runb parameter (which is
apparently the number of adjacent blocks prior to the block being converted in
the same way that runp is the number of blocks after), which has sped up random
access to mmaped files.

-- 
You are receiving this mail because:
You are on the CC list for the bug.