<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/ext4/indirect.c, branch linux-4.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.7.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.7.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-05-13T04:44:16Z</updated>
<entry>
<title>ext4: refactor direct IO code</title>
<updated>2016-05-13T04:44:16Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2016-05-13T04:44:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=914f82a32d026884743fb3de9f6f0a5908a9d5dd'/>
<id>urn:sha1:914f82a32d026884743fb3de9f6f0a5908a9d5dd</id>
<content type='text'>
Currently ext4 direct IO handling is split between ext4_ext_direct_IO()
and ext4_ind_direct_IO(). However the extent based function calls into
the indirect based one for some cases and for example it is not able to
handle file extending. Previously it was not also properly handling
retries in case of ENOSPC errors. With DAX things would get even more
contrieved so just refactor the direct IO code and instead of indirect /
extent split do the split to read vs writes.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: return hole from ext4_map_blocks()</title>
<updated>2016-03-10T03:54:00Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2016-03-10T03:54:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=facab4d9711e7aa3532cb82643803e8f1b9518e8'/>
<id>urn:sha1:facab4d9711e7aa3532cb82643803e8f1b9518e8</id>
<content type='text'>
Currently, ext4_map_blocks() just returns 0 when it finds a hole and
allocation is not requested. However we have all the information
available to tell how large the hole actually is and there are callers
of ext4_map_blocks() which would save some block-by-block hole iteration
if they knew this information. So fill in struct ext4_map_blocks even
for holes with the information we have. We keep returning 0 for holes to
maintain backward compatibility of the function.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: rename and split get blocks functions</title>
<updated>2016-03-09T04:08:10Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2016-03-09T04:08:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=705965bd6dfadc3b2e0241da1423ef660bdd04c8'/>
<id>urn:sha1:705965bd6dfadc3b2e0241da1423ef660bdd04c8</id>
<content type='text'>
Rename ext4_get_blocks_write() to ext4_get_blocks_unwritten() to better
describe what it does. Also split out get blocks functions for direct
IO. Later we move functionality from _ext4_get_blocks() there. There's no
functional change in this patch.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: clean up feature test macros with predicate functions</title>
<updated>2015-10-17T20:18:43Z</updated>
<author>
<name>Darrick J. Wong</name>
</author>
<published>2015-10-17T20:18:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e2b911c53584a92266943f3b7f2cdbc19c1a4e80'/>
<id>urn:sha1:e2b911c53584a92266943f3b7f2cdbc19c1a4e80</id>
<content type='text'>
Create separate predicate functions to test/set/clear feature flags,
thereby replacing the wordy old macros.  Furthermore, clean out the
places where we open-coded feature tests.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
</content>
</entry>
<entry>
<title>ext4: call out CRC and corruption errors with specific error codes</title>
<updated>2015-10-17T20:16:04Z</updated>
<author>
<name>Darrick J. Wong</name>
</author>
<published>2015-10-17T20:16:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6a797d2737838906f2ea0a31686e87c3151e21ca'/>
<id>urn:sha1:6a797d2737838906f2ea0a31686e87c3151e21ca</id>
<content type='text'>
Instead of overloading EIO for CRC errors and corrupt structures,
return the same error codes that XFS returns for the same issues.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>dax: move DAX-related functions to a new header</title>
<updated>2015-09-08T22:35:28Z</updated>
<author>
<name>Matthew Wilcox</name>
</author>
<published>2015-09-08T21:58:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c94c2acf84dc16cf4b989bb0bc849785b7ff52f5'/>
<id>urn:sha1:c94c2acf84dc16cf4b989bb0bc849785b7ff52f5</id>
<content type='text'>
In order to handle the !CONFIG_TRANSPARENT_HUGEPAGES case, we need to
return VM_FAULT_FALLBACK from the inlined dax_pmd_fault(), which is
defined in linux/mm.h.  Given that we don't want to include &lt;linux/mm.h&gt;
in &lt;linux/fs.h&gt;, the easiest solution is to move the DAX-related
functions to a new header, &lt;linux/dax.h&gt;.  We could also have moved
VM_FAULT_* definitions to a new header, or a different header that isn't
quite such a boil-the-ocean header as &lt;linux/mm.h&gt;, but this felt like
the best option.

Signed-off-by: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Cc: Hillf Danton &lt;dhillf@gmail.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: don't retry file block mapping on bigalloc fs with non-extent file</title>
<updated>2015-06-22T01:10:51Z</updated>
<author>
<name>Darrick J. Wong</name>
</author>
<published>2015-06-22T01:10:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=292db1bc6c105d86111e858859456bcb11f90f91'/>
<id>urn:sha1:292db1bc6c105d86111e858859456bcb11f90f91</id>
<content type='text'>
ext4 isn't willing to map clusters to a non-extent file.  Don't signal
this with an out of space error, since the FS will retry the
allocation (which didn't fail) forever.  Instead, return EUCLEAN so
that the operation will fail immediately all the way back to userspace.

(The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.)

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>ext4: prevent ext4_quota_write() from failing due to ENOSPC</title>
<updated>2015-06-21T05:25:29Z</updated>
<author>
<name>Theodore Ts'o</name>
</author>
<published>2015-06-21T05:25:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5e298ae53dc2eb69f2f7153be03454c8a33c658'/>
<id>urn:sha1:c5e298ae53dc2eb69f2f7153be03454c8a33c658</id>
<content type='text'>
In order to prevent quota block tracking to be inaccurate when
ext4_quota_write() fails with ENOSPC, we make two changes.  The quota
file can now use the reserved block (since the quota file is arguably
file system metadata), and ext4_quota_write() now uses
ext4_should_retry_alloc() to retry the block allocation after a commit
has completed and released some blocks for allocation.

This fixes failures of xfstests generic/270:

Quota error (device vdc): write_blk: dquota write failed
Quota error (device vdc): qtree_write_dquot: Error -28 occurred while creating quota

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>direct-io: only inc/dec inode-&gt;i_dio_count for file systems</title>
<updated>2015-04-24T19:45:28Z</updated>
<author>
<name>Jens Axboe</name>
</author>
<published>2015-04-15T23:05:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fe0f07d08ee35fb13d2cb048970072fe4f71ad14'/>
<id>urn:sha1:fe0f07d08ee35fb13d2cb048970072fe4f71ad14</id>
<content type='text'>
do_blockdev_direct_IO() increments and decrements the inode
-&gt;i_dio_count for each IO operation. It does this to protect against
truncate of a file. Block devices don't need this sort of protection.

For a capable multiqueue setup, this atomic int is the only shared
state between applications accessing the device for O_DIRECT, and it
presents a scaling wall for that. In my testing, as much as 30% of
system time is spent incrementing and decrementing this value. A mixed
read/write workload improved from ~2.5M IOPS to ~9.6M IOPS, with
better latencies too. Before:

clat percentiles (usec):
 |  1.00th=[   33],  5.00th=[   34], 10.00th=[   34], 20.00th=[   34],
 | 30.00th=[   34], 40.00th=[   34], 50.00th=[   35], 60.00th=[   35],
 | 70.00th=[   35], 80.00th=[   35], 90.00th=[   37], 95.00th=[   80],
 | 99.00th=[   98], 99.50th=[  151], 99.90th=[  155], 99.95th=[  155],
 | 99.99th=[  165]

After:

clat percentiles (usec):
 |  1.00th=[   95],  5.00th=[  108], 10.00th=[  129], 20.00th=[  149],
 | 30.00th=[  155], 40.00th=[  161], 50.00th=[  167], 60.00th=[  171],
 | 70.00th=[  177], 80.00th=[  185], 90.00th=[  201], 95.00th=[  270],
 | 99.00th=[  390], 99.50th=[  398], 99.90th=[  418], 99.95th=[  422],
 | 99.99th=[  438]

In other setups, Robert Elliott reported seeing good performance
improvements:

https://lkml.org/lkml/2015/4/3/557

The more applications accessing the device, the worse it gets.

Add a new direct-io flags, DIO_SKIP_DIO_COUNT, which tells
do_blockdev_direct_IO() that it need not worry about incrementing
or decrementing the inode i_dio_count for this caller.

Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: Elliott, Robert (Server Storage) &lt;elliott@hp.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>direct_IO: use iov_iter_rw() instead of rw everywhere</title>
<updated>2015-04-12T02:29:45Z</updated>
<author>
<name>Omar Sandoval</name>
</author>
<published>2015-03-16T11:33:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f67376318abea58589ebe6d69dffeabb6f6c26a'/>
<id>urn:sha1:6f67376318abea58589ebe6d69dffeabb6f6c26a</id>
<content type='text'>
The rw parameter to direct_IO is redundant with iov_iter-&gt;type, and
treated slightly differently just about everywhere it's used: some users
do rw &amp; WRITE, and others do rw == WRITE where they should be doing a
bitwise check. Simplify this with the new iov_iter_rw() helper, which
always returns either READ or WRITE.

Signed-off-by: Omar Sandoval &lt;osandov@osandov.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
</feed>
