<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lwn.git/fs/btrfs/free-space-cache.c, branch v3.0.54</title>
<subtitle>Linux kernel documentation tree maintained by Jonathan Corbet</subtitle>
<id>http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.0.54</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.0.54'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/'/>
<updated>2011-06-25T13:31:06+00:00</updated>
<entry>
<title>Btrfs: make sure to update total_bitmaps when freeing cache V3</title>
<updated>2011-06-25T13:31:06+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-06-24T16:02:51+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=9b90f5135320bc74dc6c9a8c74d69fd4821d9282'/>
<id>urn:sha1:9b90f5135320bc74dc6c9a8c74d69fd4821d9282</id>
<content type='text'>
A user reported this bug again where we have more bitmaps than we are supposed
to.  This is because we failed to load the free space cache, but don't update
the ctl-&gt;total_bitmaps counter when we remove entries from the tree.  This patch
fixes this problem and we should be good to go again.  Thanks,

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
Signed-off-by: Chris Mason &lt;chris.mason@oracle.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: make sure to recheck for bitmaps in clusters</title>
<updated>2011-06-10T20:36:57+00:00</updated>
<author>
<name>Chris Mason</name>
<email>chris.mason@oracle.com</email>
</author>
<published>2011-06-10T20:36:57+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=38e87880666091fe9c572a7a2ed2e771d97ca5aa'/>
<id>urn:sha1:38e87880666091fe9c572a7a2ed2e771d97ca5aa</id>
<content type='text'>
Josef recently changed the free extent cache to look in
the block group cluster for any bitmaps before trying to
add a new bitmap for the same offset.  This avoids BUG_ON()s due
covering duplicate ranges.

But it didn't go quite far enough.  A given free range might span
between one or more bitmaps or free space entries.  The code has
looping to cover this, but it doesn't check for clustered bitmaps
every time.

This shuffles our gotos to check for a bitmap in the cluster
for every new bitmap entry we try to add.

Signed-off-by: Chris Mason &lt;chris.mason@oracle.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: fix duplicate checking logic</title>
<updated>2011-06-08T20:37:29+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-06-06T14:50:35+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=f6a398298d34af66ec3a2d82a44a4dbc5277357d'/>
<id>urn:sha1:f6a398298d34af66ec3a2d82a44a4dbc5277357d</id>
<content type='text'>
When merging my code into the integration test the second check for duplicate
entries got screwed up.  This patch fixes it by dropping ret2 and just using ret
for the return value, and checking if we got an error before adding the bitmap
to the local list.  Thanks,

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: fix bitmap regression</title>
<updated>2011-06-08T20:37:28+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-05-27T18:07:49+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8'/>
<id>urn:sha1:2cdc342c204dba69ca3b2ec43d8e6ff41ed920b8</id>
<content type='text'>
In cleaning up the clustering code I accidently introduced a regression by
adding bitmap entries to the cluster rb tree.  The problem is if we've maxed out
the number of bitmaps we can have for the block group we can only add free space
to the bitmaps, but since the bitmap is on the cluster we can't find it and we
try to create another one.  This would result in a panic because the total
bitmaps was bigger than the max bitmaps that were allowed.  This patch fixes
this by checking to see if we have a cluster, and then looking at the cluster rb
tree to see if it has a bitmap entry and if it does and that space belongs to
that bitmap, go ahead and add it to that bitmap.

I could hit this panic every time with an fs_mark test within a couple of
minutes.  With this patch I no longer hit the panic and fs_mark goes to
completion.  Thanks,

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: noinline the cluster searching functions</title>
<updated>2011-06-08T19:08:30+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-05-25T17:07:37+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=3de85bb95cc50d0977cbb7a0c605e894be4c790d'/>
<id>urn:sha1:3de85bb95cc50d0977cbb7a0c605e894be4c790d</id>
<content type='text'>
When profiling the find cluster code it's hard to tell where we are spending our
time because the bitmap and non-bitmap functions get inlined by the compiler, so
make that not happen.  Thanks,

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: cache bitmaps when searching for a cluster</title>
<updated>2011-06-08T19:08:28+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2011-05-25T17:03:16+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=86d4a77ba3dc4ace238a0556541a41df2bd71d49'/>
<id>urn:sha1:86d4a77ba3dc4ace238a0556541a41df2bd71d49</id>
<content type='text'>
If we are looking for a cluster in a particularly sparse or fragmented block
group, we will do a lot of looping through the free space tree looking for
various things, and if we need to look at bitmaps we will endup doing the whole
dance twice.  So instead add the bitmap entries to a temporary list so if we
have to do the bitmap search we can just look through the list of entries we've
found quickly instead of having to loop through the entire tree again.  Thanks,

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
</content>
</entry>
<entry>
<title>btrfs: add helper for fs_info-&gt;closing</title>
<updated>2011-06-04T12:11:22+00:00</updated>
<author>
<name>David Sterba</name>
<email>dsterba@suse.cz</email>
</author>
<published>2011-05-31T16:07:27+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=7841cb2898f66a73062c64d0ef5733dde7279e46'/>
<id>urn:sha1:7841cb2898f66a73062c64d0ef5733dde7279e46</id>
<content type='text'>
wrap checking of filesystem 'closing' flag and fix a few missing memory
barriers.

Signed-off-by: David Sterba &lt;dsterba@suse.cz&gt;
</content>
</entry>
<entry>
<title>Btrfs: add mount -o inode_cache</title>
<updated>2011-06-04T12:03:47+00:00</updated>
<author>
<name>Chris Mason</name>
<email>chris.mason@oracle.com</email>
</author>
<published>2011-06-03T13:36:29+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=4b9465cb9e3859186eefa1ca3b990a5849386320'/>
<id>urn:sha1:4b9465cb9e3859186eefa1ca3b990a5849386320</id>
<content type='text'>
This makes the inode map cache default to off until we
fix the overflow problem when the free space crcs don't fit
inside a single page.

Signed-off-by: Chris Mason &lt;chris.mason@oracle.com&gt;
</content>
</entry>
<entry>
<title>Btrfs: make sure we don't overflow the free space cache crc page</title>
<updated>2011-06-04T12:03:43+00:00</updated>
<author>
<name>Chris Mason</name>
<email>chris.mason@oracle.com</email>
</author>
<published>2011-06-03T05:26:53+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=211f96c24f117fcc6e9e2431e40d92f4de22625e'/>
<id>urn:sha1:211f96c24f117fcc6e9e2431e40d92f4de22625e</id>
<content type='text'>
The free space cache uses only one page for crcs right now,
which means we can't have a cache file bigger than the
crcs we can fit in the first page.  This adds a check to
enforce that restriction.

Signed-off-by: Chris Mason &lt;chris.mason@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-chris' of</title>
<updated>2011-05-28T11:00:39+00:00</updated>
<author>
<name>Chris Mason</name>
<email>chris.mason@oracle.com</email>
</author>
<published>2011-05-28T11:00:39+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=ff5714cca971848963b87d6b477c16ca8abbaa54'/>
<id>urn:sha1:ff5714cca971848963b87d6b477c16ca8abbaa54</id>
<content type='text'>
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work into for-linus

Conflicts:
	fs/btrfs/disk-io.c
	fs/btrfs/extent-tree.c
	fs/btrfs/free-space-cache.c
	fs/btrfs/inode.c
	fs/btrfs/transaction.c

Signed-off-by: Chris Mason &lt;chris.mason@oracle.com&gt;
</content>
</entry>
</feed>
