Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 2016 19:22:03 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-fs@FreeBSD.org
Subject:   [Bug 206652] [ext2fs][patch] EXT4: sparse file fixes and mmap optimizations
Message-ID:  <bug-206652-3630@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206652

            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@FreeBSD.org
          Reporter: damjan.jov@gmail.com
                CC: freebsd-fs@FreeBSD.org

Created attachment 166156
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166156&action=
=3Dedit
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 EX=
T4
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 =3D 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 proble=
m.
Tracking the first and last block in each extent also lets us calculate whe=
re
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 ra=
ndom
access to mmaped files.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206652-3630>