<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/ocfs2/localalloc.c, branch linux-2.6.37.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.37.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2010-06-15T23:50:43Z</updated>
<entry>
<title>ocfs2: Limit default local alloc size within bitmap range.</title>
<updated>2010-06-15T23:50:43Z</updated>
<author>
<name>Tao Ma</name>
</author>
<published>2010-06-09T08:43:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1739da40543ed2129050ccfa8a076a851ab6ed00'/>
<id>urn:sha1:1739da40543ed2129050ccfa8a076a851ab6ed00</id>
<content type='text'>
In commit 6b82021b9e91cd689fdffadbcdb9a42597bbe764, we increase
our local alloc size and calculate how much megabytes we can
get according to group size and volume size.
But we also need to check the maximum bits a local alloc block
bitmap can have. With a bs=512, cs=32K, local volume with 160G,
it calculate 96MB while the maximum local alloc size is only
76M. So the bitmap will overflow and corrupt the system truncate
log file. See bug
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1262

Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
Acked-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: ocfs2_group_bitmap_size has to handle old volume.</title>
<updated>2010-04-13T06:38:06Z</updated>
<author>
<name>Tao Ma</name>
</author>
<published>2010-04-13T06:38:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8571882c21e5073b2f96147ec4ff9b7042339e1b'/>
<id>urn:sha1:8571882c21e5073b2f96147ec4ff9b7042339e1b</id>
<content type='text'>
ocfs2_group_bitmap_size has to handle the case when the
volume don't have discontiguous block group support. So
pass the feature_incompat in and check it.

Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: ocfs2_claim_*() don't need an ocfs2_super argument.</title>
<updated>2010-05-06T05:59:06Z</updated>
<author>
<name>Joel Becker</name>
</author>
<published>2010-05-06T05:59:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1ed9b777f77929ae961d6f9cdf828a07200ba71c'/>
<id>urn:sha1:1ed9b777f77929ae961d6f9cdf828a07200ba71c</id>
<content type='text'>
They all take an ocfs2_alloc_context, which has the allocation inode.

Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: Define data structures for discontiguous block groups.</title>
<updated>2010-04-13T06:26:12Z</updated>
<author>
<name>Joel Becker</name>
</author>
<published>2010-04-13T06:26:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4cbe4249d6586d5d88ef271e07302407a14c8443'/>
<id>urn:sha1:4cbe4249d6586d5d88ef271e07302407a14c8443</id>
<content type='text'>
Defines the OCFS2_FEATURE_INCOMPAT_DISCONTIG_BG feature bit and modifies
struct ocfs2_group_desc for the feature.

Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2/trivial: Code cleanup for allocation reservation.</title>
<updated>2010-05-06T01:18:09Z</updated>
<author>
<name>Tao Ma</name>
</author>
<published>2010-04-06T08:46:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3e4218df3176657be72ad2fa199779be6c11fe4f'/>
<id>urn:sha1:3e4218df3176657be72ad2fa199779be6c11fe4f</id>
<content type='text'>
Two tiny cleanup for allocation reservation.
1. Remove some extra codes in ocfs2_local_alloc_find_clear_bits.
2. Remove an unuseful variables in ocfs2_find_resv_lhs.

Signed-off-by: Tao Ma &lt;tao.ma@oracle.com&gt;
Acked-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: increase the default size of local alloc windows</title>
<updated>2010-05-06T01:18:07Z</updated>
<author>
<name>Mark Fasheh</name>
</author>
<published>2010-04-06T01:17:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6b82021b9e91cd689fdffadbcdb9a42597bbe764'/>
<id>urn:sha1:6b82021b9e91cd689fdffadbcdb9a42597bbe764</id>
<content type='text'>
I have observed that the current size of 8M gives us pretty poor
fragmentation on multi-threaded workloads which do lots of writes.

Generally, I can increase the size of local alloc windows and observe a
marked decrease in fragmentation, even up and beyond window sizes of 512
megabytes. This makes sense for a couple reasons - larger local alloc means
more room for reservation windows. On multi-node workloads the larger local
alloc helps as well because we don't have to do window slides as often.

Also, I removed the OCFS2_DEFAULT_LOCAL_ALLOC_SIZE constant as it is no
longer used and the comment above it was out of date.

To test fragmentation, I used a workload which launched 4 threads that did
4k writes into a series of about 140 alternating files.

With resv_level=2, and a 4k/4k file system I observed the following average
fragmentation for various localalloc= parameters:

localalloc=	avg. fragmentation
	8		48
	32		16
	64		10
	120		7

On larger cluster sizes, the difference is more dramatic.

The new default size top out at 256M, which we'll only get for cluster
sizes of 32K and above.

Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: clean up localalloc mount option size parsing</title>
<updated>2010-05-06T01:18:06Z</updated>
<author>
<name>Mark Fasheh</name>
</author>
<published>2010-04-06T01:17:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=73c8a80003d13be54e2309865030404441075182'/>
<id>urn:sha1:73c8a80003d13be54e2309865030404441075182</id>
<content type='text'>
This patch pulls the local alloc sizing code into localalloc.c and provides
a callout to it from ocfs2_fill_super(). Behavior is essentially unchanged
except that I correctly calculate the maximum local alloc size. The old code
in ocfs2_parse_options() calculated the max size as:

ocfs2_local_alloc_size(sb) * 8

which is correct, in bits. Unfortunately though the option passed in is in
megabytes. Ultimately, this bug made no real difference - the shrink code
would catch a too-large size and bring it down to something reasonable.
Still, it's less than efficient as-is.

Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: remove ocfs2_local_alloc_in_range()</title>
<updated>2010-05-06T01:17:31Z</updated>
<author>
<name>Mark Fasheh</name>
</author>
<published>2010-03-17T04:01:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a57c8fd2ad238258cc983049008aea5f985804b2'/>
<id>urn:sha1:a57c8fd2ad238258cc983049008aea5f985804b2</id>
<content type='text'>
Inodes are always allocated from the global bitmap now so we don't need this
any more. Also, the existing implementation bounces reservations around
needlessly.

Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: allocation reservations</title>
<updated>2010-05-06T01:17:30Z</updated>
<author>
<name>Mark Fasheh</name>
</author>
<published>2009-12-07T21:10:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d02f00cc057809d96c044cc72d5b9809d59f7d49'/>
<id>urn:sha1:d02f00cc057809d96c044cc72d5b9809d59f7d49</id>
<content type='text'>
This patch improves Ocfs2 allocation policy by allowing an inode to
reserve a portion of the local alloc bitmap for itself. The reserved
portion (allocation window) is advisory in that other allocation
windows might steal it if the local alloc bitmap becomes
full. Otherwise, the reservations are honored and guaranteed to be
free. When the local alloc window is moved to a different portion of
the bitmap, existing reservations are discarded.

Reservation windows are represented internally by a red-black
tree. Within that tree, each node represents the reservation window of
one inode. An LRU of active reservations is also maintained. When new
data is written, we allocate it from the inodes window. When all bits
in a window are exhausted, we allocate a new one as close to the
previous one as possible. Should we not find free space, an existing
reservation is pulled off the LRU and cannibalized.

Signed-off-by: Mark Fasheh &lt;mfasheh@suse.com&gt;
</content>
</entry>
<entry>
<title>ocfs2: Make ocfs2_journal_dirty() void.</title>
<updated>2010-05-06T01:17:29Z</updated>
<author>
<name>Joel Becker</name>
</author>
<published>2010-03-19T21:13:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ec20cec7a351584ca6c70ead012e73d61f9a8e04'/>
<id>urn:sha1:ec20cec7a351584ca6c70ead012e73d61f9a8e04</id>
<content type='text'>
jbd[2]_journal_dirty_metadata() only returns 0.  It's been returning 0
since before the kernel moved to git.  There is no point in checking
this error.

ocfs2_journal_dirty() has been faithfully returning the status since the
beginning.  All over ocfs2, we have blocks of code checking this can't
fail status.  In the past few years, we've tried to avoid adding these
checks, because they are pointless.  But anyone who looks at our code
assumes they are needed.

Finally, ocfs2_journal_dirty() is made a void function.  All error
checking is removed from other files.  We'll BUG_ON() the status of
jbd2_journal_dirty_metadata() just in case they change it someday.  They
won't.

Signed-off-by: Joel Becker &lt;joel.becker@oracle.com&gt;
</content>
</entry>
</feed>
