Re: [PATCH] FLEX_BG Kernel support.

2007-09-11 Thread Andreas Dilger 
On 9/10/07, Jose R. Santos [EMAIL PROTECTED] wrote:
 @@ -1254,7 +1254,8 @@ static int ext4_check_descriptors (struct super_block * 
 sb)

 for (i = 0; i  sbi-s_groups_count; i++)
 {
 -   if (i == sbi-s_groups_count - 1)
 +   if (i == sbi-s_groups_count - 1 || 
 EXT4_HAS_INCOMPAT_FEATURE(sb,
 +   EXT4_FEATURE_INCOMPAT_FLEX_BG))
 last_block = ext4_blocks_count(sbi-s_es) - 1;

No need to check this featyre for every  group, once at the beginning
of the function is enough.

-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] FLEX_BG Kernel support.

2007-09-11 Thread Jose R. Santos 
On Tue, 11 Sep 2007 00:04:43 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:

 On 9/10/07, Jose R. Santos [EMAIL PROTECTED] wrote:
  @@ -1254,7 +1254,8 @@ static int ext4_check_descriptors (struct super_block 
  * sb)
 
  for (i = 0; i  sbi-s_groups_count; i++)
  {
  -   if (i == sbi-s_groups_count - 1)
  +   if (i == sbi-s_groups_count - 1 || 
  EXT4_HAS_INCOMPAT_FEATURE(sb,
  +   EXT4_FEATURE_INCOMPAT_FLEX_BG))
  last_block = ext4_blocks_count(sbi-s_es) - 1;
 
 No need to check this featyre for every  group, once at the beginning
 of the function is enough.
 

Do you mean something like the original patch?
http://lists.openwall.net/linux-ext4/2007/07/12/20

Wouldn't we need to check all the descriptor for corruption if checksum
is not enable on the filesystem?

-JRS
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

2.6.23-rc6: hanging ext3 dbench tests

2007-09-11 Thread Andy Whitcroft 
I have a couple of failed test runs against 2.6.23-rc6 where the
job timed out while running dbench over ext3.  Both on powerpc,
though both significantly different hardware setups.  A failed
run like this implies that the machine was still responsive to
other processes but the dbench was making no progress.  There is
no console diagnostics during the failure.

beavis was lost during a plain ext3 dbench run, having just
successfully run a complete ext2 run.  elm3b19 was lost during an
ext3 data=writeback dbench run, having already completed an plain
ext2, and ext3 runs.

A quick poke at the dbench logs on the second machine shows this
for the working ext3 dbench run:

  4 clients started
  4 35288  814.49 MB/sec
  0 62477  822.99 MB/sec
  Throughput 822.954 MB/sec 4 procs

Whereas the hanging run shows the following continuing until the
machine is reset, which confirms that the machine as a whole was
still with us:

  4 clients started
  4 36479  824.92 MB/sec
  1 46857  519.98 MB/sec
  1 46857  346.65 MB/sec
  1 46857  259.99 MB/sec
  1 46857  207.99 MB/sec
  1 46857  173.32 MB/sec
  1 46857  148.56 MB/sec
  1 46857  129.99 MB/sec
  1 46857  115.55 MB/sec
  1 46857  103.99 MB/sec
  1 46857  94.54 MB/sec
  1 46857  86.66 MB/sec
  1 46857  80.00 MB/sec
  [...]

The first machine is very similar:

  4 clients started
  4 18468  445.29 MB/sec
  4 41945  469.36 MB/sec
  1 46857  346.68 MB/sec
  1 46857  260.00 MB/sec
  1 46857  208.00 MB/sec
  [...]

Not sure if there is any significance to the 46857.  Though it feels
like we may be at the end of the run when it fails.

I will try and reproduce this on one of the machines and see if I
can get any further info.

-apw
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new mballoc patches.

2007-09-11 Thread Aneesh Kumar K.V 



Aneesh Kumar K.V wrote:

I have updated the mballoc patches. The same can be found at

http://www.radian.org/~kvaneesh/ext4/patch-series/





Test status:
Minor testing with KVM. I also didn't do a PPC build.



running fsstress on ppc64 give me 


EXT4-fs: group 9: 16384 blocks in bitmap, 32254 in gd
EXT4-fs error (device sda7): ext4_mb_mark_diskspace_used: Allocating block in 
system zone - block = 294915

EXT4-fs error (device sda7): ext4_ext_find_extent: bad header in inode #213792: 
invalid magic - magic 5e5e, entries 24158, max 24158(0), depth 24158(0)
RTAS: event: 137875, Type: Platform Error, Severity: 2
EXT4-fs error (device sda7): ext4_ext_find_extent: bad header in inode #232149: 
invalid magic - magic e5e5, entries 58853, max 58853(0), depth 58853(0)
RTAS: event: 137876, Type: Platform Error, Severity: 2
EXT4-fs error (device sda7): ext4_ext_find_extent: bad header in inode #214332: 
invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
EXT4-fs error (device sda7): ext4_ext_remove_space: bad header in inode 
#232149: invalid magic - magic e5e5, entries 58853, max 58853(0), depth 58853(0)

-aneesh
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.23-rc6: hanging ext3 dbench tests

2007-09-11 Thread Andy Whitcroft 
Annoyingly this seems to be intermittent, and I have not managed to get
a machine into this state again yet.  Will keep trying.

-apw
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new mballoc patches.

2007-09-11 Thread Mingming Cao 
On Tue, 2007-09-11 at 13:59 +0530, Aneesh Kumar K.V wrote:
 I have updated the mballoc patches. The same can be found at
 
 http://www.radian.org/~kvaneesh/ext4/patch-series/
 
 
 
 The series file is 
 
 # This series applies on GIT commit b07d68b5ca4d55a16fab223d63d5fb36f89ff42f
 ext4-journal_chksum-2.6.20.patch
 ext4-journal-chksum-review-fix.patch
 ext4_uninit_blockgroup.patch
 64-bit-i_version.patch
 i_version_hi.patch
 ext4_i_version_hi_2.patch
 i_version_update_ext4.patch
 jbd-stats-through-procfs
 jbd-stats-through-procfs_fix.patch
 delalloc-vfs.patch
 delalloc-ext4.patch
 ext-truncate-mutex.patch
 ext3-4-migrate.patch
 new-extent-function.patch
 generic-find-next-le-bit
 mballoc-core.patch
 ext234_enlarge_blocksize.patch
 ext2_rec_len_overflow_with_64kblk_fix.patch
 ext3_rec_len_overflow_with_64kblk_fix.patch
 ext4_rec_len_overflow_with_64kblk_fix.patch
 RFC-1-2-JBD-slab-management-support-for-large-b.patch
 RFC-2-2-JBD-blocks-reservation-fix-for-large-bl.patch
 
 
 
 Changes:
 a) deleted mballoc-fixup.patch; merged with mballoc-core.path
 b) deleted mballoc-mkdir-oops-fix.patch; merged with mballoc-core.patch
 c) merged  Uninitialized group related changes for mballoc
 d) merged the checkpatch.pl error fix patch for mballoc 
 e) merged the fix for ext4_ext_search_right for error 
EXT4-fs error (device sdc): ext4_ext_search_right: bad header in inode 
 #3745797: unexpected eh_depth - magic f30a, entries 81, max 84(0), depth 0(1)
 f) PPC build fix by introducing generic_find_next_le_bit()
 g) Document the code. Rest of the places that needs more comments are marked 
 with FIXME!!
 h) 48 bit block usage by converting bg_*_bitmap and bg_inode_table to 
 respective ext4_*_bitmap and ext4_inode_table() function
 i) Added jbd fixes patches from Mingming for large  block size with the 
 comment from hch. (this is added towards the end of the series)
 k) Updated the ext234_enlarge_blocksize.patch 
 ext2_rec_len_overflow_with_64kblk_fix.patch 
 ext3_rec_len_overflow_with_64kblk_fix.patch 
ext4_rec_len_overflow_with_64kblk_fix.patch to make sure they can be 
 applied with stgit. They didn't had a valid email id in the
From: field. ( This is only commit message update )
 
 Test status:
 Minor testing with KVM. I also didn't do a PPC build. 
 
 Mingming/Avantika,
 
 Can we update the patch queue with the series ?
 

Thanks for the update.  I just back to home from London late last night,
still catching up emails, so I haven't get a chance to update the ext4
patch queue yet. Will do so shortly.


Cheers,
Mingming
 -aneesh
   
 -
 To unsubscribe from this list: send the line unsubscribe linux-ext4 in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] FLEX_BG Kernel support.

2007-09-11 Thread Andreas Dilger 
On Sep 11, 2007  07:27 -0500, Jose R. Santos wrote:
 On Tue, 11 Sep 2007 00:04:43 -0600
 Andreas Dilger [EMAIL PROTECTED] wrote:
  On 9/10/07, Jose R. Santos [EMAIL PROTECTED] wrote:
   @@ -1254,7 +1254,8 @@ static int ext4_check_descriptors (struct 
   super_block * sb)
  
   for (i = 0; i  sbi-s_groups_count; i++)
   {
   -   if (i == sbi-s_groups_count - 1)
   +   if (i == sbi-s_groups_count - 1 || 
   EXT4_HAS_INCOMPAT_FEATURE(sb,
   +   EXT4_FEATURE_INCOMPAT_FLEX_BG))
   last_block = ext4_blocks_count(sbi-s_es) - 1;
  
  No need to check this featyre for every  group, once at the beginning
  of the function is enough.
  
 
 Do you mean something like the original patch?
 http://lists.openwall.net/linux-ext4/2007/07/12/20
 
 Wouldn't we need to check all the descriptor for corruption if checksum
 is not enable on the filesystem?

Yes, I just meant you don't need to have:

EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))

for each time through the loop.  That loop is walked 8000 times per TB
at mount, so if we can make it faster we should do so.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html