Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Hans Reiser]

Jens Benecke wrote:

>Hi,
>
>I applied the 2.4.22 patches from Chris Mason's SuSE FTP directory for data
>logging etc:
>
>available at 
>http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/people/mason
>patches/data-logging/2.4.22/ or
>mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.22/
>
>root         3109 Jul 11 21:10 02-akpm-b_journal_head-1.diff
>root        17133 Jul 11 21:10 04-reiserfs-sync_fs-4.diff
>root       155659 Jul 11 21:09 05-data-logging-39.diff
>root          650 Jul 11 21:10 06-write_times.diff
>root        41276 Jul 11 21:09 07-reiserfs-quota-28.diff
>root         3275 Jul 11 21:15 08-kinoded-9.diff
>root         2653 Jul 11 21:10 10-reiserfs-quota-link-fix.diff
>root          898 Oct 10 12:25 README
>
>This system is running 2.4.22-kernel from Debian (stable) with the
>GRsecurity 1.9.12 patch, on P4 optimization and no other patches, except
>for the above.
>
>
>Two problems appeared with the above patches:
>
>a) Synchronizing with drbd (www.drbd.org) shared devices slowed down to 
>   a crawl. I guess this might have something to do with the way drbd
>   inserts itself between block device and file system and the changed
>   sync behavoiur.
>   Sync rates were >5000k/s before and <500k/s after I patched.
>
>b) bonnie++ on a (previously created) reiserfs partition (with 
>   mkreiserfs 3.6.6) exited with random "disk full" errors, although 
>   the disk was never full. This didn't happen before.
>
>
>Details:
>
>  
>
>>bonnie++ -d . -s 2048 -m master1 -r 1024 -x 2 -u nobody:nogroup
>>    
>>
>
>Now bonnie++ exits randomly with "no space left on device" when 'df' clearly
>shows there is ample space left:
>
>Writing with putc()...  
>Writing intelligently...
>Can't write block.
>Bonnie: drastic I/O error (write(2)): No space left on device
>
>-rw-------    1 nobody   nogroup  474931200 Nov 28 22:04 Bonnie.19345.000
>-rw-------    1 nobody   nogroup         0 Nov 28 22:04 Bonnie.19345.001
>
>Dateisystem          1k-Blöcke    Benutzt Verfügbar Ben% montiert auf
>/dev/ide/host0/bus0/target0/lun0/part7
>                       3044184    945424   2098760  32% /var
>
>
>This did not happen before I applied the patches.
>To be honest, I don't know how to debug this.
>
>There is nothing in the syslog and nothing via 'dmesg' related to drbd or
>reiserfs.
>
>
>I would appreciate any help.
>Thank you! :-)
>
>
>  
>
there may be a holiday related delay in Chris's response, don't 
interpret it as a lack of interest....

-- 
Hans

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Christian Mayrhuber]

Jens Benecke wrote:
> Hi,
> 
> I applied the 2.4.22 patches from Chris Mason's SuSE FTP directory for data
> logging etc:
> 
> available at 
> http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/people/mason
> patches/data-logging/2.4.22/ or
> mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.22/
> 
> root         3109 Jul 11 21:10 02-akpm-b_journal_head-1.diff
> root        17133 Jul 11 21:10 04-reiserfs-sync_fs-4.diff
> root       155659 Jul 11 21:09 05-data-logging-39.diff
> root          650 Jul 11 21:10 06-write_times.diff
> root        41276 Jul 11 21:09 07-reiserfs-quota-28.diff
> root         3275 Jul 11 21:15 08-kinoded-9.diff
> root         2653 Jul 11 21:10 10-reiserfs-quota-link-fix.diff
> root          898 Oct 10 12:25 README

Huh! What has happened to 06-reiserfs-jh-3.diff on the ftp server?
I've the above patches + jh-3 running for months. Without any problems 
on servers and on clients.

-- 
lg, Chris

Re: slow stat() ?

[Hans Reiser]

Chris Mason wrote:

>On Mon, 2003-12-01 at 12:21, David Bernick wrote:
>  
>
>>Hi all,
>>
>>First, what I'm running Reiser on:
>>
>>Supermicro dual Xeon motherboard with 2x2.6Ghz xeons in hyperthreaded
>>mode. 3ware 7500-8 (or whatever the call the 8 port ATA card) with 8x250GB
>>disks attatched. 4GB RAM. 
>>
>>Software: 
>>RedHat 9 with latest up2date
>>Kernel 2.4.22 no patches
>>The journal is not on a separate set of spindles.
>>
>>/proc/sys/vm/max-readahead=512
>>/proc/sys/vm/min-readahead=128
>>/proc/sys/vm/bdflush
>>100     5000    640     2560    150     30000   60      20      0
>>
>>Okay. Now for the issue at hand. When the logical disk is being read from,
>>reiser is fast and effecient. We have millions (10M?) of files (about 1M
>>each) in thousands of directories. Reiser reads well (exporting the disk
>>over NFS) and we're very impressed by it. It's a bit slow on the writes
>>and the system load goes up marginally, but that's not a big deal. The
>>thing that puzzles me is that when we perform functions like "find" or in
>>perl "-e filename" or anything that uses fstat() or stat64() or any of
>>those functions brings the system usage to 100% and the load climbs
>>quickly. 
>>
>>Are there any patches, kernel updates, tuning, etc that can help with this
>>problem?
>>    
>>
>
>You could boot with profile=2 and send the results of a readprofile
>command taken after the system load goes very high.  This will slow down
>your box for general usage, so you would only want to run with profile=2
>for a short time.
>
>My guess is the stats are being done across a large directory tree and
>this is generating lots of atime updates.  You could mount -o
>noatime,nodiratime, which will reduce the amount of work reiserfs does
>on each stat.
>
>atimes are used by many mail programs to find out the last time you read
>your mailbox file.  nodiratime probably won't affect most applications.
>
>-chris
>
>
>
>
>  
>
profiling will also tell you if the performance problem is in user 
space.....;-)

-- 
Hans

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Jens Benecke]

Jens Benecke wrote:

> a) Synchronizing with drbd (www.drbd.org) shared devices slowed down to
>    a crawl. I guess this might have something to do with the way drbd
>    inserts itself between block device and file system and the changed
>    sync behavoiur.
>    Sync rates were >5000k/s before and <500k/s after I patched.

Hi,

followup: (a) has been solved, it's not the ReiserFS patches, it was
(seemingly) bad interaction between hardware (network) and software
(drivers).


-- 
Jens Benecke (jens-unibw@spamfreemail.de)
http://www.hitchhikers.de - Europaweite kostenlose Mitfahrzentrale
http://www.spamfreemail.de - 100% saubere Postfächer - garantiert!
http://www.rb-hosting.de - PHP ab 9? - SSH ab 19? - günstiger Traffic

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Chris Mason]

On Sat, 2003-11-29 at 14:27, Christian Mayrhuber wrote:
> Jens Benecke wrote:
> > Hi,
> > 
> > I applied the 2.4.22 patches from Chris Mason's SuSE FTP directory for data
> > logging etc:
> > 
> > available at 
> > http://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/people/mason
> > patches/data-logging/2.4.22/ or
> > mirror.mcs.anl.gov/suse-people/mason/patches/data-logging/2.4.22/
> > 
> > root         3109 Jul 11 21:10 02-akpm-b_journal_head-1.diff
> > root        17133 Jul 11 21:10 04-reiserfs-sync_fs-4.diff
> > root       155659 Jul 11 21:09 05-data-logging-39.diff
> > root          650 Jul 11 21:10 06-write_times.diff
> > root        41276 Jul 11 21:09 07-reiserfs-quota-28.diff
> > root         3275 Jul 11 21:15 08-kinoded-9.diff
> > root         2653 Jul 11 21:10 10-reiserfs-quota-link-fix.diff
> > root          898 Oct 10 12:25 README
> 
> Huh! What has happened to 06-reiserfs-jh-3.diff on the ftp server?
> I've the above patches + jh-3 running for months. Without any problems 
> on servers and on clients.

I've had to remove reiserfs-jh-3, it caused problems in the suse kernel
and a week or so of hunting wasn't able to track it down.  All my effort
right now is on fixing it in my 2.6 branch.

-chris

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Chris Mason]

On Fri, 2003-11-28 at 16:38, Jens Benecke wrote:

> b) bonnie++ on a (previously created) reiserfs partition (with 
>    mkreiserfs 3.6.6) exited with random "disk full" errors, although 
>    the disk was never full. This didn't happen before.
> 
> 
> Details:
> 
> > bonnie++ -d . -s 2048 -m master1 -r 1024 -x 2 -u nobody:nogroup
> 
> Now bonnie++ exits randomly with "no space left on device" when 'df' clearly
> shows there is ample space left:
> 
> Writing with putc()...  
> Writing intelligently...
> Can't write block.
> Bonnie: drastic I/O error (write(2)): No space left on device
> 
> -rw-------    1 nobody   nogroup  474931200 Nov 28 22:04 Bonnie.19345.000
> -rw-------    1 nobody   nogroup         0 Nov 28 22:04 Bonnie.19345.001
> 
> Dateisystem          1k-Blöcke    Benutzt Verfügbar Ben% montiert auf
> /dev/ide/host0/bus0/target0/lun0/part7
>                        3044184    945424   2098760  32% /var
> 
> 
> This did not happen before I applied the patches.
> To be honest, I don't know how to debug this.
> 
> There is nothing in the syslog and nothing via 'dmesg' related to drbd or
> reiserfs.
>
> I would appreciate any help.
> Thank you! :-)

Ugh, the new block allocator isn't properly forcing a commit when an
allocation fails, so we don't reclaim blocks deleted in an uncommitted
transaction.  I thought this fix got pulled out of the suse kernel when
namesys and I pulled out the important bug fixes, but it got missed.

porting.

-chris

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Christian Mayrhuber]

> I've had to remove reiserfs-jh-3, it caused problems in the suse kernel
> and a week or so of hunting wasn't able to track it down.  All my effort
> right now is on fixing it in my 2.6 branch.
Nice, to see data logging in 2.6.

So one is more safe without reiserfs-jh-3 than with it?

I sometimes get permission denied messages on some files if I read from 
LVM snapshots. This happens rather seldom and goes away if I redo a
snapshot. I could ask an admin to have a look for the console messsages, 
if this is the same problem you are facing.
I had no corruption.
-- 
lg, Chris

slow stat() ?

[David Bernick]

Hi all,

First, what I'm running Reiser on:

Supermicro dual Xeon motherboard with 2x2.6Ghz xeons in hyperthreaded
mode. 3ware 7500-8 (or whatever the call the 8 port ATA card) with 8x250GB
disks attatched. 4GB RAM. 

Software: 
RedHat 9 with latest up2date
Kernel 2.4.22 no patches
The journal is not on a separate set of spindles.

/proc/sys/vm/max-readahead=512
/proc/sys/vm/min-readahead=128
/proc/sys/vm/bdflush
100     5000    640     2560    150     30000   60      20      0

Okay. Now for the issue at hand. When the logical disk is being read from,
reiser is fast and effecient. We have millions (10M?) of files (about 1M
each) in thousands of directories. Reiser reads well (exporting the disk
over NFS) and we're very impressed by it. It's a bit slow on the writes
and the system load goes up marginally, but that's not a big deal. The
thing that puzzles me is that when we perform functions like "find" or in
perl "-e filename" or anything that uses fstat() or stat64() or any of
those functions brings the system usage to 100% and the load climbs
quickly. 

Are there any patches, kernel updates, tuning, etc that can help with this
problem?

thanks for any help you can give me.

dave

Re: slow stat() ?

[Chris Mason]

On Mon, 2003-12-01 at 12:21, David Bernick wrote:
> Hi all,
> 
> First, what I'm running Reiser on:
> 
> Supermicro dual Xeon motherboard with 2x2.6Ghz xeons in hyperthreaded
> mode. 3ware 7500-8 (or whatever the call the 8 port ATA card) with 8x250GB
> disks attatched. 4GB RAM. 
> 
> Software: 
> RedHat 9 with latest up2date
> Kernel 2.4.22 no patches
> The journal is not on a separate set of spindles.
> 
> /proc/sys/vm/max-readahead=512
> /proc/sys/vm/min-readahead=128
> /proc/sys/vm/bdflush
> 100     5000    640     2560    150     30000   60      20      0
> 
> Okay. Now for the issue at hand. When the logical disk is being read from,
> reiser is fast and effecient. We have millions (10M?) of files (about 1M
> each) in thousands of directories. Reiser reads well (exporting the disk
> over NFS) and we're very impressed by it. It's a bit slow on the writes
> and the system load goes up marginally, but that's not a big deal. The
> thing that puzzles me is that when we perform functions like "find" or in
> perl "-e filename" or anything that uses fstat() or stat64() or any of
> those functions brings the system usage to 100% and the load climbs
> quickly. 
> 
> Are there any patches, kernel updates, tuning, etc that can help with this
> problem?

You could boot with profile=2 and send the results of a readprofile
command taken after the system load goes very high.  This will slow down
your box for general usage, so you would only want to run with profile=2
for a short time.

My guess is the stats are being done across a large directory tree and
this is generating lots of atime updates.  You could mount -o
noatime,nodiratime, which will reduce the amount of work reiserfs does
on each stat.

atimes are used by many mail programs to find out the last time you read
your mailbox file.  nodiratime probably won't affect most applications.

-chris

Re: slow stat() ?

[David Bernick]

> My guess is the stats are being done across a large directory tree and
> this is generating lots of atime updates.  You could mount -o
> noatime,nodiratime, which will reduce the amount of work reiserfs does
> on each stat.

thanks for the quick response. i'll try this tonight and report back. i
totally didn't even think of doing that. that really might help a great
deal.

Any other suggestions? 

d

Re: slow stat() ?

[Chris Mason]

On Mon, 2003-12-01 at 12:43, David Bernick wrote:
> > My guess is the stats are being done across a large directory tree and
> > this is generating lots of atime updates.  You could mount -o
> > noatime,nodiratime, which will reduce the amount of work reiserfs does
> > on each stat.
> 
> thanks for the quick response. i'll try this tonight and report back. i
> totally didn't even think of doing that. that really might help a great
> deal.
> 
> Any other suggestions? 

The profile results would really allow us to pinpoint the problem.

-chris

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Jens Benecke]

Chris Mason wrote:

> On Fri, 2003-11-28 at 16:38, Jens Benecke wrote:
> 
>> b) bonnie++ on a (previously created) reiserfs partition (with
>>    mkreiserfs 3.6.6) exited with random "disk full" errors, although
>>    the disk was never full. This didn't happen before.
>> (...)
>> I would appreciate any help. Thank you! :-)
> 
> Ugh, the new block allocator isn't properly forcing a commit when an
> allocation fails, so we don't reclaim blocks deleted in an uncommitted
> transaction.  I thought this fix got pulled out of the suse kernel when
> namesys and I pulled out the important bug fixes, but it got missed.
> 
> porting.

Hi Chris,

so... the worst-case impact on this bug is that reiserfs will report "disk
full" when you still have some space available. Right? No data loss,
corruption, or similar Bad Things(tm)?

I have two servers here that are supposed to be deployed next week and use
ReiserFS. I've had some bad issues with MySQL files becoming corrupted
after a crash in the past so I'd really like to put these into production
with data-logging patches.

btw, what are the patches that SuSE uses? IIRC, SuSE ships with data-logging
enabled, right?


-- 
Jens Benecke (jens-unibw@spamfreemail.de)
http://www.hitchhikers.de - Europaweite kostenlose Mitfahrzentrale
http://www.spamfreemail.de - 100% saubere Postfächer - garantiert!
http://www.rb-hosting.de - PHP ab 9? - SSH ab 19? - günstiger Traffic

Re: slow stat() ?

[David Bernick]

> My guess is the stats are being done across a large directory tree and
> this is generating lots of atime updates.  You could mount -o
> noatime,nodiratime, which will reduce the amount of work reiserfs does
> on each stat.

so far so good!

The program (a series of very large finds across large directory
structures) usually spikes the load to 5 or 6 because of all the times
kupdated and kjournald are being accessed during stat() operations. It's
been running for a few hours and the load has barely to hit 1. 

I'll keep you all informed but this looks like it helped a great deal.
thanks a bunch!

d

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Chris Mason]

On Tue, 2003-12-02 at 03:35, Jens Benecke wrote:
> Chris Mason wrote:
> 
> > On Fri, 2003-11-28 at 16:38, Jens Benecke wrote:
> > 
> >> b) bonnie++ on a (previously created) reiserfs partition (with
> >>    mkreiserfs 3.6.6) exited with random "disk full" errors, although
> >>    the disk was never full. This didn't happen before.
> >> (...)
> >> I would appreciate any help. Thank you! :-)
> > 
> > Ugh, the new block allocator isn't properly forcing a commit when an
> > allocation fails, so we don't reclaim blocks deleted in an uncommitted
> > transaction.  I thought this fix got pulled out of the suse kernel when
> > namesys and I pulled out the important bug fixes, but it got missed.
> > 
> > porting.
> 
> Hi Chris,
> 
> so... the worst-case impact on this bug is that reiserfs will report "disk
> full" when you still have some space available. Right? No data loss,
> corruption, or similar Bad Things(tm)?
> 
Correct.  I'll have a fix available today along with a remerge of data
logging and quota against 2.4.23.

> I have two servers here that are supposed to be deployed next week and use
> ReiserFS. I've had some bad issues with MySQL files becoming corrupted
> after a crash in the past so I'd really like to put these into production
> with data-logging patches.
> 
> btw, what are the patches that SuSE uses? IIRC, SuSE ships with data-logging
> enabled, right?
> 

SUSE ships data logging and the xattr patches, along with a few others.

-chris

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Jens Benecke]

Chris Mason wrote:

>> so... the worst-case impact on this bug is that reiserfs will report
>> "disk full" when you still have some space available. Right? No data
>> loss, corruption, or similar Bad Things(tm)?
>> 
> Correct.  I'll have a fix available today along with a remerge of data
> logging and quota against 2.4.23.

Thank you!
 
>> btw, what are the patches that SuSE uses? IIRC, SuSE ships with
>> data-logging enabled, right?
> SUSE ships data logging and the xattr patches, along with a few others.

What patches exactly? 
Are they available in public to be applied to a vanilla kernel?


-- 
Jens Benecke (jens-unibw@spamfreemail.de)
http://www.hitchhikers.de - Europaweite kostenlose Mitfahrzentrale
http://www.spamfreemail.de - 100% saubere Postfächer - garantiert!
http://www.rb-hosting.de - PHP ab 9? - SSH ab 19? - günstiger Traffic

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Chris Mason]

On Thu, 2003-12-04 at 07:44, Jens Benecke wrote:
> Chris Mason wrote:
> 
> >> so... the worst-case impact on this bug is that reiserfs will report
> >> "disk full" when you still have some space available. Right? No data
> >> loss, corruption, or similar Bad Things(tm)?
> >> 
> > Correct.  I'll have a fix available today along with a remerge of data
> > logging and quota against 2.4.23.

The -ENOSPC fix is attached, 2.6 should have the same bug (it was
introduced with the new allocator) so I'm porting the fix there. 
Basically after a data block allocation fails, we need to trigger and
wait on a commit so we can reclaim any blocks freed in transactions that
have not yet been comitted.

>  
> >> btw, what are the patches that SuSE uses? IIRC, SuSE ships with
> >> data-logging enabled, right?
> > SUSE ships data logging and the xattr patches, along with a few others.
> 
> What patches exactly? 

Well there are a few basic categories:

Major featuers -- data logging, xattrs/acls
Backports of fixes
Support for new generic code - aio, laptop mode, barriers, o_direct
minor performance tweaks

Any significant feature or big performance tweak ends up posted here,
the minor stuff I tend to try out in the suse qa/testing process to see
if it is worth maintaining over the long haul.

> Are they available in public to be applied to a vanilla kernel?
> 

The nosrc src kernel rpms (perhaps the worst named thing on the planet)
have the individual patch files.  The suse kernel has quite a few
patches, and most of the changes I don't upload to pub/people/mason are
dependent in some large way on other patches in the suse kernel.

-chris

Re: Strange errors with 2.4.22 patches (from Chris) and bonnie++

[Chris Mason]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Thu, 2003-12-04 at 11:28, Chris Mason wrote:
> On Thu, 2003-12-04 at 07:44, Jens Benecke wrote:
> > Chris Mason wrote:
> > 
> > >> so... the worst-case impact on this bug is that reiserfs will report
> > >> "disk full" when you still have some space available. Right? No data
> > >> loss, corruption, or similar Bad Things(tm)?
> > >> 
> > > Correct.  I'll have a fix available today along with a remerge of data
> > > logging and quota against 2.4.23.
> 
> The -ENOSPC fix is attached, 2.6 should have the same bug (it was
> introduced with the new allocator) so I'm porting the fix there. 
> Basically after a data block allocation fails, we need to trigger and
> wait on a commit so we can reclaim any blocks freed in transactions that
> have not yet been comitted.

Hmpf, this time it is really attached.

-chris


[-- Attachment #2: 01-reiserfs-free-blocks --]
[-- Type: text/plain, Size: 2534 bytes --]

%patch

trigger a commit when a data block allocation fails, this will
allow us to reclaim any blocks freed in uncommitted transactsions

diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c	Wed Dec  3 18:13:01 2003
+++ b/fs/reiserfs/inode.c	Wed Dec  3 18:13:01 2003
@@ -628,7 +628,11 @@
 	    /* restart the transaction to give the journal a chance to free
 	    ** some blocks.  releases the path, so we have to go back to
 	    ** research if we succeed on the second try
+	    **
+	    ** the journal won't free the blocks if we don't force a commit
+	    ** and wait for it
 	    */
+	    SB_JOURNAL(inode->i_sb)->j_next_async_flush = 1;
 	    restart_transaction(&th, inode, &path) ; 
 	    repeat = _allocate_block(&th, block, inode, &allocated_block_nr, NULL, create);
 
diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c	Wed Dec  3 18:13:01 2003
+++ b/fs/reiserfs/journal.c	Wed Dec  3 18:13:01 2003
@@ -2996,7 +2996,6 @@
   int jindex ;
   int orig_jindex ;
   int flush = flags & FLUSH_ALL ;
-  int commit_now = flags & COMMIT_NOW ;
   int wait_on_commit = flags & WAIT ;
   struct reiserfs_super_block *rs ; 
 
@@ -3010,8 +3009,8 @@
     flush = 1 ;
   }
   if (SB_JOURNAL(p_s_sb)->j_next_async_flush) {
-    flags |= COMMIT_NOW ;
-    commit_now = 1 ;
+    flags |= COMMIT_NOW | WAIT;
+    wait_on_commit = 1;
   }
 
   /* check_journal_end locks the journal, and unlocks if it does not return 1 
@@ -3025,9 +3024,6 @@
   if (SB_JOURNAL(p_s_sb)->j_next_full_flush) {
     flush = 1 ;
   }
-  if (SB_JOURNAL(p_s_sb)->j_next_async_flush) {
-    commit_now = 1 ;
-  }
   /*
   ** j must wait means we have to flush the log blocks, and the real blocks for
   ** this transaction
@@ -3191,15 +3187,12 @@
 
   /* honor the flush and async wishes from the caller */
   if (flush) {
-  
     flush_commit_list(p_s_sb, SB_JOURNAL_LIST(p_s_sb) + orig_jindex, 1) ;
     flush_journal_list(p_s_sb,  SB_JOURNAL_LIST(p_s_sb) + orig_jindex , 1) ;  
-  } else if (commit_now) {
-    if (wait_on_commit) {
-      flush_commit_list(p_s_sb, SB_JOURNAL_LIST(p_s_sb) + orig_jindex, 1) ;
-    } else {
-      commit_flush_async(p_s_sb, orig_jindex) ; 
-    }
+  } else if (wait_on_commit) {
+    flush_commit_list(p_s_sb, SB_JOURNAL_LIST(p_s_sb) + orig_jindex, 1) ;
+  } else {
+    commit_flush_async(p_s_sb, orig_jindex) ; 
   }
 
   /* reset journal values for the next transaction */
@@ -3263,6 +3256,3 @@
   wake_up(&(SB_JOURNAL(p_s_sb)->j_join_wait)) ;
   return 0 ;
 }
-
-
-

update on Re: slow stat() ?

[David Bernick]

Thought I'd update this issue:

I was using Kernel 2.4.22 with himem enabled and 4GB of hardware RAM. The
system was occasionally getting overloaded, especially with lots of stat()
syscalls. kupdated seemed to dominate the system during these parts. Very
frustrating.

I moved to kernel 2.4.23 after reading that the HIMEM section was greatly
improved and that seemed to solve my problem. 

Just thought I'd mention it.