Re: [PATCH 2/2] Btrfs: Fix setting umask when POSIX ACLs are not enabled
Hi Chris! On Thu, Sep 17, 2009 at 8:42 AM, Chris Ball c...@laptop.org wrote: We currently set sb-s_flags |= MS_POSIXACL unconditionally, which is incorrect -- it tells the VFS that it shouldn't set umask because we will, yet we don't set it ourselves if we aren't using POSIX ACLs, so the umask ends up ignored. Signed-off-by: Chris Ball c...@laptop.org --- fs/btrfs/super.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Works fine now! Thank you .. :) With best regards from the Soul, Alex. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote: On Mon, Sep 07 2009, Markus Trippelsdorf wrote: Just got this error today in my dmesg: btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798 linux % find . -inum 1483065 ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack It's the main pack file from my git linux kernel tree: Hmm, I ran into something very similar. Care to check what the corrupted block of data looks like (and how big it is)? I've hit the same problem again today: btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 1660028275 The file in question is: ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack I can't read the file directly, because of the csum mismatch: Chris, is there a way to force reading the file? Seems like that would be a very handy feature. Markus, not sure if that works, but you could always try and remount with data checksumming disabled. mount /dev/fooX -o remount,rw,nodatasum should do the trick. That doesn't work unfortunately, btrfs still calculates and compares the checksums (it won't write new ones I guess). -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote: On Mon, Sep 07 2009, Markus Trippelsdorf wrote: Just got this error today in my dmesg: btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798 linux % find . -inum 1483065 ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack It's the main pack file from my git linux kernel tree: Hmm, I ran into something very similar. Care to check what the corrupted block of data looks like (and how big it is)? I've hit the same problem again today: btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 1660028275 The file in question is: ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack I can't read the file directly, because of the csum mismatch: Chris, is there a way to force reading the file? Seems like that would be a very handy feature. Markus, not sure if that works, but you could always try and remount with data checksumming disabled. mount /dev/fooX -o remount,rw,nodatasum should do the trick. That doesn't work unfortunately, btrfs still calculates and compares the checksums (it won't write new ones I guess). Ah ok, as mentioned I wasn't sure whether that would work or not. I'll defer to Chris :-) -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 11:05:49AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote: On Mon, Sep 07 2009, Markus Trippelsdorf wrote: Just got this error today in my dmesg: btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798 linux % find . -inum 1483065 ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack It's the main pack file from my git linux kernel tree: Hmm, I ran into something very similar. Care to check what the corrupted block of data looks like (and how big it is)? I've hit the same problem again today: btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 1660028275 The file in question is: ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack I can't read the file directly, because of the csum mismatch: Chris, is there a way to force reading the file? Seems like that would be a very handy feature. Markus, not sure if that works, but you could always try and remount with data checksumming disabled. mount /dev/fooX -o remount,rw,nodatasum should do the trick. That doesn't work unfortunately, btrfs still calculates and compares the checksums (it won't write new ones I guess). Ah ok, as mentioned I wasn't sure whether that would work or not. I'll defer to Chris :-) Understood. I did some further investigations and was able to reconstruct exactly the same pack file in question by starting from an older backup copy of my git repro and then running the same git commands as previous. Then I did a binary comparison between this reconstructed file and a corrupted backup copy from the time before the csum errors occured (I automatically backup every 4h). This is the result (first line good pack file, second line corrupted file): vbindiff debug/.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack debug2/.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 B7 FD AB DA 74 2D 1C 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 33 FD AB DA 74 2D 1C 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 5E 7E EB DA 5F D6 11 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 1E 7E EB DA 5F D6 11 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A 0802 C3C0: 5C A5 E1 4A 1C BC 14 04 16 4A 29 D3 CC EF A6 80 0802 C3C0: 5C 25 E1 4A 1C BC 14 04 16 48 29 D3 CC EF A6 80 081A B3C0: 7D 7A 2C CD 20 89 E5 F2 A8 D3 32 38 04 BA 8A B5 081A B3C0: 7D 3A 2C CD 20 89 E5 F2 A8 D3 32 38 04 BA 8A B5 098E C430: FE 24 4A 19 09 F4 D5 1F 22 E8 36 FA F8 55 B2 6E 098E C430: FE 24 4A 19 09 F4 D5 1F 22 E0 36 FA F8 55 B2 6E 098E C440: 1B 3F C1 B4 BB 80 F8 5A FB EE 0D A3 3F C5 A4 DB 098E C440: 1B 3D C1 B4 BB 80 F8 5A FB EE 0D A3 3F C5 A4 DB 098E C4D0: F8 6C E2 65 18 7A 5D 33 2E 35 77 64 B2 81 BE DF 098E C4D0: F8 6C E2 65 18 7A 5D 33 2E 25 77 64 B2 81 BE DF 098E C4E0: 05 18 DE E3 00 78 D2 2C 4F 91 8F AF 0B F6 0C 31 098E C4E0: 05 1C DE E3 00 78 D2 2C 4F 91 8F AF 0B F6 0C 31 098E C500: 0A 12 D3 E7 FA B8 40 DE 0D 71 94 88 5D 4C 97 21 098E C500: 0A 12 D3 E7 FA B8 40 DE 0D 51 94 88 5D 4C 97 21 098E C540: 93 F2 58 C7 49 9A AA EB 30 3D 28 AA E3 09 4B 7B 098E C540: 93 F2 58 C7 49 9A AA EB 30 3C 28 AA E3 09 4B 7B 0FDE C420: F3 6A C2 38 76 43 9E 86 0D 9C 89 86 F1 E6 B0 F2 0FDE C420: F3 6A C2 38 76 43 9E 86 0D DC 89 86 F1 E6 B0 F2 0FDE C430: 38 E4 69 2E 22 1D E4 FF 90 A7 C6 E8 9F 08 4C 98 0FDE C430: 38 E4 69 2E 22 1D E4 FF 90 A5 C6 E8 9F 08 4C 98 1214 A4C0: 24 D6 56 AC 8B D8 D0 9B D2 62 7B 83 C7 0B 3D BE 1214 A4C0: 24 D4 56 AC 8B D8 D0 9B D2 62 7B 83 C7 0B 3D BE 1214 A500: EC 51 D3 FF C5 7D 30 DD 6D 45 50 FE E9 64 A4 FC 1214 A500: EC 11 D3 FF C5 7D 30 DD 6D 45 50 FE E9 64 A4 FC 1214 A520: D9 4D 63 EB 77 4D F0 BE 5E B3 6B DE E6 D2 28 67 1214 A520: D9 4D 63 EB 77 4D F0 BE 5E 33 6B DE E6 D2 28 67 -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 02:15:01PM +0200, Markus Trippelsdorf wrote: On Thu, Sep 17, 2009 at 11:05:49AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote: On Thu, Sep 17 2009, Markus Trippelsdorf wrote: On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote: On Mon, Sep 07 2009, Markus Trippelsdorf wrote: Just got this error today in my dmesg: btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private 43905798 linux % find . -inum 1483065 ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack It's the main pack file from my git linux kernel tree: Hmm, I ran into something very similar. Care to check what the corrupted block of data looks like (and how big it is)? I've hit the same problem again today: btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 1660028275 The file in question is: ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack I can't read the file directly, because of the csum mismatch: Chris, is there a way to force reading the file? Seems like that would be a very handy feature. Markus, not sure if that works, but you could always try and remount with data checksumming disabled. mount /dev/fooX -o remount,rw,nodatasum should do the trick. That doesn't work unfortunately, btrfs still calculates and compares the checksums (it won't write new ones I guess). Ah ok, as mentioned I wasn't sure whether that would work or not. I'll defer to Chris :-) Understood. I did some further investigations and was able to reconstruct exactly the same pack file in question by starting from an older backup copy of my git repro and then running the same git commands as previous. Then I did a binary comparison between this reconstructed file and a corrupted backup copy from the time before the csum errors occured (I automatically backup every 4h). Thanks to Chris' patch (from IRC) I was able to compare the file with the csum error to the reconstructed one. You'll find the reults as attachments. -- Markus 08F403A0 5D 8E B3 32 7D 8F 5D E7 54 B6 9D 1E E6 0C 9B 0D BE 1D 9D 0C 34 BA 7F FE 7F D4 E5 1A 0A 16 29 96 105AC3A0 76 80 1E 0A 3F 8A 7E FC B3 2E 2B 9E 9E 53 82 10 C3 F6 4B C1 C0 12 FC 61 A5 0E 63 70 B0 A4 7B 27 105AC3C0 DC AE 26 CE 48 5D CA 07 B7 26 B6 3C BC 91 AD 00 55 97 BF E4 8C D7 EF AA 28 B7 54 65 30 DB 78 A6 105AC3E0 26 90 18 88 8F F4 25 91 48 5F 9C F6 4F 0D 46 72 A2 04 77 1A AF FB 88 23 93 AF FB AA B9 82 BC CC 08F403A0 5D 8E B3 32 7D 8F 5D E7 54 B4 9D 1E E6 0C 9B 0D BE 1D 9D 0C 34 BA 7F FE 7F D4 E5 1A 0A 16 29 96 105AC3A0 76 80 1E 0A 3F 8A 7E FC B3 2E 2B 9E 9E 53 82 10 C3 F7 4B C1 C0 12 FC 61 A5 0E 63 70 B0 A4 7B 27 105AC3C0 DC AE 26 CE 48 5D CA 07 B7 77 B6 3C BC 91 AD 00 55 97 BF E4 8C D7 EF AA 28 A7 54 65 30 DB 78 A6 105AC3E0 26 90 18 88 8F F4 25 91 48 5F 9C F6 4F 0D 46 72 A2 04 77 1A AF FB 88 23 93 AF FB AA B9 82 BC CC
Re: btrfs csum failed on git .pack file
0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 B7 FD AB DA 74 2D 1C 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 33 FD AB DA 74 2D 1C B7 = 10110111 33 = 00110011 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 5E 7E EB DA 5F D6 11 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 1E 7E EB DA 5F D6 11 5E = 0100 1E = 0000 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A 4B = 01001011 0B = 1011 And so on. It looks like a few bits are getting flipped at the same byte offset. One can imagine software bugs that would do this, certainly, but upset hardware seems awfully likely too. - z -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 10:00:28AM -0700, Zach Brown wrote: 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 B7 FD AB DA 74 2D 1C 0130 9FA0: E2 3B 43 AA 63 BF 28 B3 87 33 FD AB DA 74 2D 1C B7 = 10110111 33 = 00110011 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 5E 7E EB DA 5F D6 11 06CD DF90: B0 22 6B 46 9F ED 6E 47 73 1E 7E EB DA 5F D6 11 5E = 0100 1E = 0000 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A 4B = 01001011 0B = 1011 And so on. It looks like a few bits are getting flipped at the same byte offset. One can imagine software bugs that would do this, certainly, but upset hardware seems awfully likely too. I'm afraid you're right. I did some further tests and now I'm pretty sure that a bad RAM module was the root cause of it all... Oh well. -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs csum failed on git .pack file
On Thu, Sep 17, 2009 at 07:10:06PM +0200, Markus Trippelsdorf wrote: 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 4B 08 94 C0 65 17 3A 06CD DFC0: 0D 86 2B B2 57 A4 5A CD 78 0B 08 94 C0 65 17 3A 4B = 01001011 0B = 1011 And so on. It looks like a few bits are getting flipped at the same byte offset. One can imagine software bugs that would do this, certainly, but upset hardware seems awfully likely too. I'm afraid you're right. I did some further tests and now I'm pretty sure that a bad RAM module was the root cause of it all... Oh well. On the other hand, that what's so great in checksumming filesystems. You found bad module thanks to btrfs, otherwise you wouldn't suspect anything wrong. If you have had raid-1 for data, this corruption would have been fixed by btrfs. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated performance results
Chris Mason wrote: On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote: Only bit of bad news is I did get one error that crashed the system on single threaded nocow run. So that data point is missing. Output below: I hope I've got this fixed. If you pull from the master branch of btrfs-unstable there are fixes for async thread races. The single patch I sent before is included, but not enough. Chris: FYI - all five of my test systems have now finished my standard test cycle on the -unstable master branch, and I've not seen a single hang. So, your fix for the async thread shutdown race seems to have fixed my problems, even if Steve's still seeing trouble. I'll note that the running times for fsstress on some of my systems have become rather longer with btrfs-unstable/master kernels - 3.5 rather than 2.5 hours on multidevice filesystems. Running times on single device filesystems are roughly the same. I'm going to start another set of tests for thoroughness unless you've got more patches coming. Thanks, Eric -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated performance results
On Thu, Sep 17, 2009 at 01:39:01PM -0500, Steven Pratt wrote: Eric Whitney wrote: Chris Mason wrote: On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote: Only bit of bad news is I did get one error that crashed the system on single threaded nocow run. So that data point is missing. Output below: I hope I've got this fixed. If you pull from the master branch of btrfs-unstable there are fixes for async thread races. The single patch I sent before is included, but not enough. Chris: FYI - all five of my test systems have now finished my standard test cycle on the -unstable master branch, and I've not seen a single hang. So, your fix for the async thread shutdown race seems to have fixed my problems, even if Steve's still seeing trouble. I'll note that the running times for fsstress on some of my systems have become rather longer with btrfs-unstable/master kernels - 3.5 rather than 2.5 hours on multidevice filesystems. Running times on single device filesystems are roughly the same. I'm going to start another set of tests for thoroughness unless you've got more patches coming. I've had some offline discussions with Chris, and it seems the problem is triggered by unmounting and re-mounting the file system between tests (but not running mkfs again). I have also just verified that the problem does not occur if repeated tests are run without the unmount mount cycle. So in case this is not clear: Ok, I've triggered it here. Next step is trying Yan Zheng's async caching update. [ cut here ] kernel BUG at fs/btrfs/extent-tree.c:4097! invalid opcode: [#1] SMP -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated performance results
[ crashes on runs involving unmounts ]
The run is still going here, but it has survived longer than before.
I'm trying with Yan Zheng's patch:
From: Yan Zheng zheng@oracle.com
Date: Fri, 11 Sep 2009 16:11:19 -0400
Subject: [PATCH] Btrfs: improve async block group caching
This patch gets rid of two limitations of async block group caching.
The old code delays handling pinned extents when block group is in
caching. To allocate logged file extents, the old code need wait
until block group is fully cached. To get rid of the limitations,
This patch introduces a data structure to track the progress of
caching. Base on the caching progress, we know which extents should
be added to the free space cache when handling the pinned extents.
The logged file extents are also handled in a similar way.
This patch also changes how pinned extents are tracked. The old
code uses one tree to track pinned extents, and copy the pinned
extents tree at transaction commit time. This patch makes it use
two trees to track pinned extents. One tree for extents that are
pinned in the running transaction, one tree for extents that can
be unpinned. At transaction commit time, we swap the two trees.
Signed-off-by: Yan Zheng zheng@oracle.com
Signed-off-by: Chris Mason chris.ma...@oracle.com
---
fs/btrfs/ctree.h | 29 ++-
fs/btrfs/disk-io.c |7 +-
fs/btrfs/extent-tree.c | 586 +---
fs/btrfs/transaction.c | 15 +-
fs/btrfs/tree-log.c|4 +-
5 files changed, 382 insertions(+), 259 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 732d5b8..3b6df71 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -726,6 +726,15 @@ enum btrfs_caching_type {
BTRFS_CACHE_FINISHED= 2,
};
+struct btrfs_caching_control {
+ struct list_head list;
+ struct mutex mutex;
+ wait_queue_head_t wait;
+ struct btrfs_block_group_cache *block_group;
+ u64 progress;
+ atomic_t count;
+};
+
struct btrfs_block_group_cache {
struct btrfs_key key;
struct btrfs_block_group_item item;
@@ -742,8 +751,9 @@ struct btrfs_block_group_cache {
int dirty;
/* cache tracking stuff */
- wait_queue_head_t caching_q;
int cached;
+ struct btrfs_caching_control *caching_ctl;
+ u64 last_byte_to_unpin;
struct btrfs_space_info *space_info;
@@ -788,7 +798,8 @@ struct btrfs_fs_info {
spinlock_t block_group_cache_lock;
struct rb_root block_group_cache_tree;
- struct extent_io_tree pinned_extents;
+ struct extent_io_tree freed_extents[2];
+ struct extent_io_tree *pinned_extents;
/* logical-physical extent mapping */
struct btrfs_mapping_tree mapping_tree;
@@ -825,8 +836,6 @@ struct btrfs_fs_info {
struct mutex drop_mutex;
struct mutex volume_mutex;
struct mutex tree_reloc_mutex;
- struct rw_semaphore extent_commit_sem;
-
/*
* this protects the ordered operations list only while we are
* processing all of the entries on it. This way we make
@@ -835,10 +844,12 @@ struct btrfs_fs_info {
* before jumping into the main commit.
*/
struct mutex ordered_operations_mutex;
+ struct rw_semaphore extent_commit_sem;
struct list_head trans_list;
struct list_head hashers;
struct list_head dead_roots;
+ struct list_head caching_block_groups;
atomic_t nr_async_submits;
atomic_t async_submit_draining;
@@ -1920,8 +1931,8 @@ void btrfs_put_block_group(struct btrfs_block_group_cache
*cache);
int btrfs_run_delayed_refs(struct btrfs_trans_handle *trans,
struct btrfs_root *root, unsigned long count);
int btrfs_lookup_extent(struct btrfs_root *root, u64 start, u64 len);
-int btrfs_update_pinned_extents(struct btrfs_root *root,
- u64 bytenr, u64 num, int pin);
+int btrfs_pin_extent(struct btrfs_root *root,
+u64 bytenr, u64 num, int reserved);
int btrfs_drop_leaf_ref(struct btrfs_trans_handle *trans,
struct btrfs_root *root, struct extent_buffer *leaf);
int btrfs_cross_ref_exist(struct btrfs_trans_handle *trans,
@@ -1971,9 +1982,10 @@ int btrfs_free_extent(struct btrfs_trans_handle *trans,
u64 root_objectid, u64 owner, u64 offset);
int btrfs_free_reserved_extent(struct btrfs_root *root, u64 start, u64 len);
+int btrfs_prepare_extent_commit(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root);
int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans,
- struct btrfs_root *root,
- struct extent_io_tree *unpin);
+ struct btrfs_root *root);
int btrfs_inc_extent_ref(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
Re: Updated performance results
On Thu, Sep 17, 2009 at 04:17:14PM -0400, Chris Mason wrote: [ crashes on runs involving unmounts ] The run is still going here, but it has survived longer than before. I'm trying with Yan Zheng's patch: From: Yan Zheng zheng@oracle.com Date: Fri, 11 Sep 2009 16:11:19 -0400 Subject: [PATCH] Btrfs: improve async block group caching Quick update, I got through a full run of Steve's test with this applied. I'll start a few more ;) -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated performance results
Chris Mason wrote: On Thu, Sep 17, 2009 at 04:17:14PM -0400, Chris Mason wrote: [ crashes on runs involving unmounts ] The run is still going here, but it has survived longer than before. I'm trying with Yan Zheng's patch: From: Yan Zheng zheng@oracle.com Date: Fri, 11 Sep 2009 16:11:19 -0400 Subject: [PATCH] Btrfs: improve async block group caching Quick update, I got through a full run of Steve's test with this applied. I'll start a few more ;) Seems to work for me too! Got through all the random write tests with no problems. Will kick off full run overnight. Steve -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
