Data-logging for 2.4.21-rc1+ (again)

Data-logging for 2.4.21-rc1+ (again)

[Manuel Krause]

Hi!

is there any effort on data-logging for 2.4.21-rc1+?

Still using 2.4.21-pre7 as I didn't know how to sort your, Chris',  last 
messages on this topic, ->cynicism || ->sarcasm .

Are there new patches out that I only don't find?!

Thank you very much!

Manuel Krause

Re: Data-logging for 2.4.21-rc1+ (again)

[Oleg Drokin]

Hello!

On Sat, May 03, 2003 at 02:07:46AM +0200, Manuel Krause wrote:

> is there any effort on data-logging for 2.4.21-rc1+?

Grab the replacement patches from
ftp://namesys.com/pub/reiserfs-for-2.4/testing/data-logging-and-quota-2.4.21-rc1

Bye,
    Oleg

Data-logging and md as / fs bug

[Christian Mayrhuber]

Am Samstag, 3. Mai 2003 12:31 schrieb Oleg Drokin:
> Hello!
>
> On Sat, May 03, 2003 at 02:07:46AM +0200, Manuel Krause wrote:
> > is there any effort on data-logging for 2.4.21-rc1+?
>
> Grab the replacement patches from
> ftp://namesys.com/pub/reiserfs-for-2.4/testing/data-logging-and-quota-2.4.2
>1-rc1
>
> Bye,
>     Oleg

Hi,

I've patched 2.4.21-rc1 with the following:
       
02-akpm-b_journal_head-1.diff        
03-2.4.21-rc1-relocation-6.diff      
04-reiserfs-sync_fs-1.diff           
05-2.4.21-pre6-data-logging-36.diff  
06-logging-export.diff               
06-write_times.diff                  
07-quota-v2-2.4.21.diff
08-2.4.21-pre6-reiserfs-quota-26.diff
09-kinoded-8.diff
10-reiserfs-quota-link-fix.diff

After rebooting this kernel it fails to cleanly shutdown /dev/md0, which
is mounted as / and runs as raid1. This causes a nasty resync of the disks at
every boot.
2.4.21-rc1 without those patches has no problems with md shutdown.
I just wanted let you know.
-- 
lg, Chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Tue, 2003-05-06 at 15:34, Christian Mayrhuber wrote:

> Hi,
> 
> I've patched 2.4.21-rc1 with the following:
>        
> 02-akpm-b_journal_head-1.diff        
> 03-2.4.21-rc1-relocation-6.diff      
> 04-reiserfs-sync_fs-1.diff           
> 05-2.4.21-pre6-data-logging-36.diff  
> 06-logging-export.diff               
> 06-write_times.diff                  
> 07-quota-v2-2.4.21.diff
> 08-2.4.21-pre6-reiserfs-quota-26.diff
> 09-kinoded-8.diff
> 10-reiserfs-quota-link-fix.diff
> 
> After rebooting this kernel it fails to cleanly shutdown /dev/md0, which
> is mounted as / and runs as raid1. This causes a nasty resync of the disks at
> every boot.
> 2.4.21-rc1 without those patches has no problems with md shutdown.
> I just wanted let you know.

Interesting, this isn't a known bug.  Could you please try two things:

1) try to reproduce without any patches past 06-write_times.diff applied
(in other words, without the quota)

2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
03-2.4.21-rc1-relocation-6.diff applied.

thanks!

-chris

Re: Data-logging and md as / fs bug

[Dieter Nützel]

Am Dienstag, 6. Mai 2003 21:44 schrieb Chris Mason:
> On Tue, 2003-05-06 at 15:34, Christian Mayrhuber wrote:
> > Hi,
> >
> > I've patched 2.4.21-rc1 with the following:

I have nearly the same running on-top of 2.4.21-pre6-jam1

> > 02-akpm-b_journal_head-1.diff

Needed?

> > 03-2.4.21-rc1-relocation-6.diff
> > 04-reiserfs-sync_fs-1.diff
> > 05-2.4.21-pre6-data-logging-36.diff
> > 06-logging-export.diff

Needed?

> > 06-write_times.diff

I have -aa;-)

> > 07-quota-v2-2.4.21.diff
> > 08-2.4.21-pre6-reiserfs-quota-26.diff

Both not, yet.

> > 09-kinoded-8.diff
> > 10-reiserfs-quota-link-fix.diff

Needed?

11.dirty-inodes-for-kinoded.diff
iget5_locked_for_2.4.21-pre5-datalogging.diff
search_reada-4.diff

Usefull?

> > After rebooting this kernel it fails to cleanly shutdown /dev/md0, which
> > is mounted as / and runs as raid1. This causes a nasty resync of the
> > disks at every boot.
> > 2.4.21-rc1 without those patches has no problems with md shutdown.
> > I just wanted let you know.
>
> Interesting, this isn't a known bug.  Could you please try two things:
>
> 1) try to reproduce without any patches past 06-write_times.diff applied
> (in other words, without the quota)
>
> 2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
> 03-2.4.21-rc1-relocation-6.diff applied.

Clean new versions?

What about merging them into 2.4.22-pre, finally?

Thanks,
	Dieter

Re: Data-logging and md as / fs bug

[Christian Mayrhuber]

Am Dienstag, 6. Mai 2003 21:44 schrieb Chris Mason:
> On Tue, 2003-05-06 at 15:34, Christian Mayrhuber wrote:
> > Hi,
> >
> > I've patched 2.4.21-rc1 with the following:
> >
> > 02-akpm-b_journal_head-1.diff
> > 03-2.4.21-rc1-relocation-6.diff
> > 04-reiserfs-sync_fs-1.diff
> > 05-2.4.21-pre6-data-logging-36.diff
> > 06-logging-export.diff
> > 06-write_times.diff
> > 07-quota-v2-2.4.21.diff
> > 08-2.4.21-pre6-reiserfs-quota-26.diff
> > 09-kinoded-8.diff
> > 10-reiserfs-quota-link-fix.diff
> >
> > After rebooting this kernel it fails to cleanly shutdown /dev/md0, which
> > is mounted as / and runs as raid1. This causes a nasty resync of the
> > disks at every boot.
> > 2.4.21-rc1 without those patches has no problems with md shutdown.
> > I just wanted let you know.
>
> Interesting, this isn't a known bug.  Could you please try two things:
>
> 1) try to reproduce without any patches past 06-write_times.diff applied
> (in other words, without the quota)
>
> 2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
> 03-2.4.21-rc1-relocation-6.diff applied.
>
> thanks!
>
> -chris

The bug already appears in case 2) with akpm and relocation only applied.

-- 
lg, Chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Tue, 2003-05-06 at 16:53, Christian Mayrhuber wrote:
> Am Dienstag, 6. Mai 2003 21:44 schrieb Chris Mason:

> >
> > 2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
> > 03-2.4.21-rc1-relocation-6.diff applied.
> >
> > thanks!
> >
> > -chris
> 
> The bug already appears in case 2) with akpm and relocation only applied.

Ok, thanks, checking

-chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Tue, 2003-05-06 at 16:53, Christian Mayrhuber wrote:

> > Interesting, this isn't a known bug.  Could you please try two things:
> >
> > 1) try to reproduce without any patches past 06-write_times.diff applied
> > (in other words, without the quota)
> >
> > 2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
> > 03-2.4.21-rc1-relocation-6.diff applied.

> The bug already appears in case 2) with akpm and relocation only applied.

I'd like to make sure I'm tracking the right problem.  Could you please
send me the exact kernel messages from the failed shutdown?

-chris

Re: Data-logging and md as / fs bug

[Christian Mayrhuber]

Am Mittwoch, 7. Mai 2003 14:34 schrieb Chris Mason:

> > > 2) try to reproduce with only 02-akpm-b_journal_head-1.diff and
> > > 03-2.4.21-rc1-relocation-6.diff applied.
> >
> > The bug already appears in case 2) with akpm and relocation only applied.
>
> I'd like to make sure I'm tracking the right problem.  Could you please
> send me the exact kernel messages from the failed shutdown?
>
> -chris


/dev/md0 is reiserfs mounted / and /dev/md1 is swap space, messages are from a
Debian woody system. /dev/md0 needs to resync after reboot.
/dev/md0 consists of hda1 and hdc1
/dev/md1 consists of hda2 and hdc2
The
Here's the output from the failed shutdown:

Stopping RAID devices: md: md0 still in use
/dev/md0: Device or resource busy
md: marking sb clean...
md: updating md1 RAID superblock on device
md: hdc2 [events: 00000259]<6>(write) hdc2's sb offset: 2000000
md: hda2 [events: 00000259]<6>(write) hda2's sb offset: 2000256
md: md1 stopped
md: unbind <hdc2,1>
md: export_rdev(hdc2)
md: unbind <hda2,0>
md: export_rdev(hda2)
/dev/md1 done.
md: stopping all devices.
md: md0 still in use.
flushing ide devices: hda hdb hdc
Power down.


For the case you need them the boot messages after reboot:

May  7 16:23:42 byblos kernel: md: linear personality registered as nr 1
May  7 16:23:42 byblos kernel: md: raid0 personality registered as nr 2
May  7 16:23:42 byblos kernel: md: raid1 personality registered as nr 3
May  7 16:23:42 byblos kernel: md: raid5 personality registered as nr 4
May  7 16:23:42 byblos kernel: raid5: measuring checksumming speed
May  7 16:23:42 byblos kernel:    8regs     :  2527.600 MB/sec
May  7 16:23:42 byblos kernel:    32regs    :  2236.000 MB/sec
May  7 16:23:42 byblos kernel:    pIII_sse  :  4679.200 MB/sec
May  7 16:23:42 byblos kernel:    pII_mmx   :  3864.000 MB/sec
May  7 16:23:42 byblos kernel:    p5_mmx    :  4949.200 MB/sec
May  7 16:23:42 byblos kernel: raid5: using function: pIII_sse (4679.200 MB/sec)
May  7 16:23:42 byblos kernel: md: multipath personality registered as nr 7
May  7 16:23:42 byblos kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
May  7 16:23:42 byblos kernel: md: Autodetecting RAID arrays.
May  7 16:23:42 byblos kernel:  [events: 00000161]
May  7 16:23:42 byblos kernel:  [events: 00000259]
May  7 16:23:42 byblos kernel:  [events: 00000161]
May  7 16:23:42 byblos kernel:  [events: 00000259]
May  7 16:23:42 byblos kernel: md: autorun ...
May  7 16:23:42 byblos kernel: md: considering hdc2 ...
May  7 16:23:42 byblos kernel: md:  adding hdc2 ...
May  7 16:23:42 byblos kernel: md:  adding hda2 ...
May  7 16:23:42 byblos kernel: md: created md1
May  7 16:23:42 byblos kernel: md: bind<hda2,1>
May  7 16:23:42 byblos kernel: md: bind<hdc2,2>
May  7 16:23:42 byblos kernel: md: running: <hdc2><hda2>
May  7 16:23:42 byblos kernel: md: hdc2's event counter: 00000259
May  7 16:23:42 byblos kernel: md: hda2's event counter: 00000259
May  7 16:23:42 byblos kernel: md: RAID level 1 does not need chunksize! Continuing anyway.
May  7 16:23:42 byblos kernel: md1: max total readahead window set to 124k
May  7 16:23:42 byblos kernel: md1: 1 data-disks, max readahead per data-disk: 124k
May  7 16:23:42 byblos kernel: raid1: device hdc2 operational as mirror 1
May  7 16:23:42 byblos kernel: raid1: device hda2 operational as mirror 0
May  7 16:23:42 byblos kernel: raid1: raid set md1 active with 2 out of 2 mirrors
May  7 16:23:42 byblos kernel: md: updating md1 RAID superblock on device
May  7 16:23:42 byblos kernel: md: hdc2 [events: 0000025a]<6>(write) hdc2's sb offset: 2000000
May  7 16:23:42 byblos kernel: md: hda2 [events: 0000025a]<6>(write) hda2's sb offset: 2000256
May  7 16:23:42 byblos kernel: md: considering hdc1 ...
May  7 16:23:42 byblos kernel: md:  adding hdc1 ...
May  7 16:23:42 byblos kernel: md:  adding hda1 ...
May  7 16:23:42 byblos kernel: md: created md0
May  7 16:23:42 byblos kernel: md: bind<hda1,1>
May  7 16:23:42 byblos kernel: md: bind<hdc1,2>
May  7 16:23:42 byblos kernel: md: running: <hdc1><hda1>
May  7 16:23:42 byblos kernel: md: hdc1's event counter: 00000161
May  7 16:23:42 byblos kernel: md: hda1's event counter: 00000161
May  7 16:23:42 byblos kernel: md: md0: raid array is not clean -- starting background reconstruction
May  7 16:23:42 byblos kernel: md: RAID level 1 does not need chunksize! Continuing anyway.
May  7 16:23:42 byblos kernel: md0: max total readahead window set to 124k
May  7 16:23:42 byblos kernel: md0: 1 data-disks, max readahead per data-disk: 124k
May  7 16:23:42 byblos kernel: raid1: device hdc1 operational as mirror 1
May  7 16:23:42 byblos kernel: raid1: device hda1 operational as mirror 0
May  7 16:23:42 byblos kernel: raid1: raid set md0 not clean; reconstructing mirrors
May  7 16:23:42 byblos kernel: raid1: raid set md0 active with 2 out of 2 mirrors
May  7 16:23:42 byblos kernel: md: updating md0 RAID superblock on device
May  7 16:23:42 byblos kernel: md: hdc1 [events: 00000162]<6>(write) hdc1's sb offset: 19534912
May  7 16:23:42 byblos kernel: md: syncing RAID array md0
May  7 16:23:42 byblos kernel: md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
May  7 16:23:42 byblos kernel: md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction.
May  7 16:23:42 byblos kernel: md: using 124k window, over a total of 19534912 blocks.
May  7 16:23:42 byblos kernel: md: hda1 [events: 00000162]<6>(write) hda1's sb offset: 19534912
May  7 16:23:42 byblos kernel: md: ... autorun DONE.
-- 
lg, Chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Wed, 2003-05-07 at 10:41, Christian Mayrhuber wrote:

> /dev/md0 is reiserfs mounted / and /dev/md1 is swap space, messages are from a
> Debian woody system. /dev/md0 needs to resync after reboot.
> /dev/md0 consists of hda1 and hdc1
> /dev/md1 consists of hda2 and hdc2
> The
> Here's the output from the failed shutdown:
> 
> Stopping RAID devices: md: md0 still in use
> /dev/md0: Device or resource busy

Interesting, I think I understand it.  You don't any warnings about
failures while unmounting /, right?

-chris

Re: Data-logging and md as / fs bug

[Christian Mayrhuber]

Am Mittwoch, 7. Mai 2003 16:43 schrieb Chris Mason:
> On Wed, 2003-05-07 at 10:41, Christian Mayrhuber wrote:
> > /dev/md0 is reiserfs mounted / and /dev/md1 is swap space, messages are
> > from a Debian woody system. /dev/md0 needs to resync after reboot.
> > /dev/md0 consists of hda1 and hdc1
> > /dev/md1 consists of hda2 and hdc2
> > The
> > Here's the output from the failed shutdown:
> >
> > Stopping RAID devices: md: md0 still in use
> > /dev/md0: Device or resource busy
>
> Interesting, I think I understand it.  You don't any warnings about
> failures while unmounting /, right?
>
> -chris

No warning at all.
I've reiserfsck'ed /dev/hda1 and /dev/hdc1 from a cd boot without md support
to see if there is something corrupt on one drive, but both raid1 disks were
perfectly ok.
-- 
lg, Chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Wed, 2003-05-07 at 10:52, Christian Mayrhuber wrote:
> Am Mittwoch, 7. Mai 2003 16:43 schrieb Chris Mason:
> > On Wed, 2003-05-07 at 10:41, Christian Mayrhuber wrote:
> > > /dev/md0 is reiserfs mounted / and /dev/md1 is swap space, messages are
> > > from a Debian woody system. /dev/md0 needs to resync after reboot.
> > > /dev/md0 consists of hda1 and hdc1
> > > /dev/md1 consists of hda2 and hdc2
> > > The
> > > Here's the output from the failed shutdown:
> > >
> > > Stopping RAID devices: md: md0 still in use
> > > /dev/md0: Device or resource busy
> >
> > Interesting, I think I understand it.  You don't any warnings about
> > failures while unmounting /, right?

> No warning at all.
> I've reiserfsck'ed /dev/hda1 and /dev/hdc1 from a cd boot without md support
> to see if there is something corrupt on one drive, but both raid1 disks were
> perfectly ok.

Ok, it's probably because of the way the journal relocation code grabs
the journal device.  Since root doesn't really get fully unmounted we've
probably got a reference open and that is upsetting the md code.

The right fix is probably to skip the bdget when the journal device is
not external , and just set journal->j_dev_bd to super->s_bdev.

Oleg/namesys, do you see any reason this won't work?

-chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Tue, 2003-05-06 at 15:56, Dieter Nützel wrote:
> Am Dienstag, 6. Mai 2003 21:44 schrieb Chris Mason:
> > On Tue, 2003-05-06 at 15:34, Christian Mayrhuber wrote:
> > > Hi,
> > >
> > > I've patched 2.4.21-rc1 with the following:
> 
> I have nearly the same running on-top of 2.4.21-pre6-jam1
> 
> > > 02-akpm-b_journal_head-1.diff
> 
> Needed?
> 

Yes

> > > 03-2.4.21-rc1-relocation-6.diff
> > > 04-reiserfs-sync_fs-1.diff
> > > 05-2.4.21-pre6-data-logging-36.diff
> > > 06-logging-export.diff
> 
> Needed?

06-logging-export is only needed if you want to compile reiserfs as a
module

> 
> > > 06-write_times.diff
> 
> I have -aa;-)
> 
> > > 07-quota-v2-2.4.21.diff
> > > 08-2.4.21-pre6-reiserfs-quota-26.diff
> 
> Both not, yet.
> 
> > > 09-kinoded-8.diff
> > > 10-reiserfs-quota-link-fix.diff
> 
> Needed?
> 

Only if you are using quota

> 11.dirty-inodes-for-kinoded.diff

This is flawed, since it does not include any way to throttle inode
changes.  kinoded can't keep up with an active FS, and major changes are
needed to fix that.  I've dropped it for now.

> iget5_locked_for_2.4.21-pre5-datalogging.diff

Not needed any more.

> search_reada-4.diff
> 
> Usefull?

Good for desktop workload, needs additional changes for random io.

-chris

Re: Data-logging and md as / fs bug

[Chris Mason]

On Wed, 2003-05-07 at 11:23, Chris Mason wrote:

[ md complains about busy devices on reboot ]

> Ok, it's probably because of the way the journal relocation code grabs
> the journal device.  Since root doesn't really get fully unmounted we've
> probably got a reference open and that is upsetting the md code.
> 
> The right fix is probably to skip the bdget when the journal device is
> not external , and just set journal->j_dev_bd to super->s_bdev.

Hopefully 03-relocation-8.diff fixes this.  The incremental is below if
you'd like to give it a try, but use with caution as I haven't tested on
an md root device here.

diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c	Thu May  8 09:38:49 2003
+++ b/fs/reiserfs/journal.c	Thu May  8 09:38:49 2003
@@ -2294,7 +2294,7 @@
     
     result = 0;
 	
-    if( journal -> j_dev_bd != NULL ) {
+    if( journal -> j_dev_bd != NULL && journal->j_dev_bd != super->s_bdev) {
 	result = blkdev_put( journal -> j_dev_bd, BDEV_FS );
 	journal -> j_dev_bd = NULL;
     }
@@ -2330,6 +2330,14 @@
 
 	if( ( !jdev_name || !jdev_name[ 0 ] ) ) {
 
+		/* don't add an extra reference to the device when 
+		 * the log is on the same disk as the FS.  It makes the
+		 * raid code unhappy
+		 */
+		if (jdev == super->s_dev) {
+		    journal->j_dev_bd = super->s_bdev;
+		    return 0;
+		}
 		journal -> j_dev_bd = bdget( kdev_t_to_nr( jdev ) );
 		if( journal -> j_dev_bd ) {
 			result = blkdev_get( journal -> j_dev_bd, 

Re: Data-logging and md as / fs bug

[Kerin Millar]

Hello,

I apologise that this reply isn't threaded - as I have only just joined the list, I wasn't able to observe the correct value for the necessary "In-Reply-To:" field! Anyway ...

> On Wed, 2003-05-07 at 11:23, Chris Mason wrote:
> 
> [ md complains about busy devices on reboot ]
> 
> > Ok, it's probably because of the way the journal relocation code grabs
> > the journal device.  Since root doesn't really get fully unmounted we've
> > probably got a reference open and that is upsetting the md code.
> > 
> > The right fix is probably to skip the bdget when the journal device is
> > not external , and just set journal->j_dev_bd to super->s_bdev.
> 
> Hopefully 03-relocation-8.diff fixes this.  The incremental is below if
> you'd like to give it a try, but use with caution as I haven't tested on
> an md root device here.

Chris, I had exactly the same problem (with Marc-Christian Peterson's WOLK kernel to be precise). The problematic dmesg upon a reboot (and other configuration information can be seen here at the time of writing):

  http://wolk.sourceforge.net/people/Kerin Millar/server/

Well, Marc notified me about your patch and I tried it. I am very pleased to say that it works - thank you! I am extremely grateful. It is most satisfying to put this irksome issue to rest once and for all, and both the cause and the solution are very interesting. I can now comfortably use my preferred filesystem in the context for which I had intended!

I still get a device/resource busy error message, but I suspect that has more to do with some flaws in the init scripts of my distribution than anything else. In any case, no resync of my software RAID-5 array is initiated upon reboot.

Thanks again - to use an American colloquialism, you rock!

Regards,

--Kerin Millar

Re: Data-logging and md as / fs bug

[Manuel Krause]

Thanks for your description below about what is really useful... :-))

On 02/23/03 you posted a kinoded-9.diff.gz to the list that solved a 
"device busy" on here when umounting a partition directly after copying 
some GB data to it.
In those days you proposed to also use kinoded when not having the quota 
patches applied. (That were the times when dirty-inodes-for-kinoded.diff
was new.)

My questions:
Is kinoded really useless without quota?
Did you discontinue the kinoded-9 changes?
Does it conflict with the recent data-logging changes?
And, I just read on the list that Kerin Millar wrote about 
device/resource busy error messages and was wondering if that had 
something to do with it.

Thanks,
  Manuel


On 05/08/2003 03:31 PM, Chris Mason wrote:
> On Tue, 2003-05-06 at 15:56, Dieter Nützel wrote:
> 
>>Am Dienstag, 6. Mai 2003 21:44 schrieb Chris Mason:
>>
>>>On Tue, 2003-05-06 at 15:34, Christian Mayrhuber wrote:
>>>
>>>>Hi,
>>>>
>>>>I've patched 2.4.21-rc1 with the following:
>>>
>>I have nearly the same running on-top of 2.4.21-pre6-jam1
>>
>>
>>>>02-akpm-b_journal_head-1.diff
>>>
>>Needed?
>>
> 
> 
> Yes
> 
> 
>>>>03-2.4.21-rc1-relocation-6.diff
>>>>04-reiserfs-sync_fs-1.diff
>>>>05-2.4.21-pre6-data-logging-36.diff
>>>>06-logging-export.diff
>>>
>>Needed?
> 
> 
> 06-logging-export is only needed if you want to compile reiserfs as a
> module
> 
> 
>>>>06-write_times.diff
>>>
>>I have -aa;-)
>>
>>
>>>>07-quota-v2-2.4.21.diff
>>>>08-2.4.21-pre6-reiserfs-quota-26.diff
>>>
>>Both not, yet.
>>
>>
>>>>09-kinoded-8.diff
>>>>10-reiserfs-quota-link-fix.diff
>>>
>>Needed?
>>
> 
> 
> Only if you are using quota
> 
> 
>>11.dirty-inodes-for-kinoded.diff
> 
> 
> This is flawed, since it does not include any way to throttle inode
> changes.  kinoded can't keep up with an active FS, and major changes are
> needed to fix that.  I've dropped it for now.
> 
> 
>>iget5_locked_for_2.4.21-pre5-datalogging.diff
> 
> 
> Not needed any more.
> 
> 
>>search_reada-4.diff
>>
>>Usefull?
> 
> 
> Good for desktop workload, needs additional changes for random io.
> 
> -chris
> 
> 
> 

Re: Data-logging and md as / fs bug

[Chris Mason]

On Fri, 2003-05-09 at 16:21, Manuel Krause wrote:
> Thanks for your description below about what is really useful... :-))
> 
> On 02/23/03 you posted a kinoded-9.diff.gz to the list that solved a 
> "device busy" on here when umounting a partition directly after copying 
> some GB data to it.

kinoded-9 was fixing a symptom, the real problem  was the patch to allow
dirty inodes to hang around instead of logging them instantly.  With the
right workload you could reproduce the device busy on unmount problem
with kinoded-9 applied too.

> In those days you proposed to also use kinoded when not having the quota 
> patches applied. (That were the times when dirty-inodes-for-kinoded.diff
> was new.)
> 
> My questions:
> Is kinoded really useless without quota?

Right now, yes.

> Did you discontinue the kinoded-9 changes?

kinoded-9 changes are still good, I need to post an updated patch.  They
are not critical though.

> Does it conflict with the recent data-logging changes?

No

> And, I just read on the list that Kerin Millar wrote about 
> device/resource busy error messages and was wondering if that had 
> something to do with it.
> 

The software raid problems are different, that was a long standing bug
in the journal relocation code.

-chris

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Thu, May 08, 2003 at 09:31:25AM -0400, Chris Mason wrote:

> > iget5_locked_for_2.4.21-pre5-datalogging.diff
> Not needed any more.

How so?
This one is still not fixed in Marcelo tree at least.
And I hope to get at least the least-intrusive fix in before 2.4.22 is out.

Bye,
    Oleg

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Wed, May 07, 2003 at 11:23:25AM -0400, Chris Mason wrote:

> The right fix is probably to skip the bdget when the journal device is
> not external , and just set journal->j_dev_bd to super->s_bdev.
> Oleg/namesys, do you see any reason this won't work?

Well, this is probably the most simple solution.
The more full one would probably be to only grab journal in case of RW mount
and to release journal when remounting read-only. This way we will be able to also free
the RAM assotiated with journal that never used because the FS is readonly.
What do you think?

Bye,
    Oleg

Re: Data-logging and md as / fs bug

[Manuel Krause]

On 05/12/2003 09:29 AM, Oleg Drokin wrote:
> Hello!
> 
> On Thu, May 08, 2003 at 09:31:25AM -0400, Chris Mason wrote:
> 
> 
>>>iget5_locked_for_2.4.21-pre5-datalogging.diff
>>
>>Not needed any more.
> 
> 
> How so?
> This one is still not fixed in Marcelo tree at least.
> And I hope to get at least the least-intrusive fix in before 2.4.22 is out.
> 
> Bye,
>     Oleg

Do you have something new to try? Does this original patch affect disk 
i/o perfomance (positive/negative)?

Always appreciated are less intrusive ones regarding i/o speed ;-))

(BTW, with small change (for non-quota people like me: a remove of 
dquot.o from the export-objs) this patch runs well on here ("desktop 
load") since you published it: On -pre5, -pre7 and now -rc2).


Bye and many thanks,

  Manuel


--
Currently running 2.4.21-rc2 +

patch-2.4.21-rc2.rfs01.m02-akpm-b_journal_head-1.diff
patch-2.4.21-rc2.rfs02.m03-relocation-8.diff
patch-2.4.21-rc2.rfs03.m04-reiserfs-sync_fs-4.diff
patch-2.4.21-rc2.rfs04.m05-data-logging-37.diff
patch-2.4.21-rc2.rfs05.m06-logging-export.diff
patch-2.4.21-rc2.rfs06.m06-write_times.diff
patch-2.4.21-rc2.rfs07.m09.kinoded-9.ML.diff
patch-2.4.21-rc2.rfs08.m11.inode-dirty-for-kinoded.ML.diff
patch-2.4.21-rc2.rfs09.m12.search_reada-4.diff
patch-2.4.21-rc2.rfs10.iget5_locked_for_datalogging.namesys.noquota.diff
preempt-kernel-rml-2.4.21-rc2-was-pre1-1.0.patch
patch.mk.01.Makefile.diff
patch.mk.02.r128_drv.diff
patch.mk.03.2.4.21-rc2-Config.in.diff

applied in this order.

-
rfs??=reiserfs, m??=Chris' patches, ML=posted to reiserfs-list only, 
mk=my own needed changes

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Tue, May 13, 2003 at 04:15:30PM +0200, Manuel Krause wrote:

> Do you have something new to try? Does this original patch affect disk 
> i/o perfomance (positive/negative)?

No. I have old patch instead that applies to 2.4.20 and basically every other kernel
and that I am pushing to Marchelo as this iget5_locked is too intrusive at current 2.4
development stage.
This old patch is attached.

> Always appreciated are less intrusive ones regarding i/o speed ;-))

I/O speed should be the same with all the aproaches.
The patch below is a bit more cpu hungry as it introduces one more spinlock.

Bye,
    Oleg
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1209  -> 1.1210 
#	 fs/reiserfs/inode.c	1.42    -> 1.43   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/05/12	green@angband.namesys.com	1.1210
# reiserfs: iget4() race fix
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c	Tue May 13 18:24:37 2003
+++ b/fs/reiserfs/inode.c	Tue May 13 18:24:37 2003
@@ -20,6 +20,10 @@
 static int reiserfs_get_block (struct inode * inode, long block,
 			       struct buffer_head * bh_result, int create);
 
+/* This spinlock guards inode pkey in private part of inode
+   against race between find_actor() vs reiserfs_read_inode2 */
+static spinlock_t keycopy_lock = SPIN_LOCK_UNLOCKED;
+
 void reiserfs_delete_inode (struct inode * inode)
 {
     int jbegin_count = JOURNAL_PER_BALANCE_CNT * 2; 
@@ -898,8 +902,9 @@
     bh = PATH_PLAST_BUFFER (path);
     ih = PATH_PITEM_HEAD (path);
 
-
+    spin_lock(&keycopy_lock);
     copy_key (INODE_PKEY (inode), &(ih->ih_key));
+    spin_unlock(&keycopy_lock);
     inode->i_blksize = PAGE_SIZE;
 
     INIT_LIST_HEAD(&inode->u.reiserfs_i.i_prealloc_list) ;
@@ -1220,10 +1225,27 @@
 				unsigned long inode_no, void *opaque )
 {
     struct reiserfs_iget4_args *args;
+    int retval;
 
     args = opaque;
+    /* We protect against possible parallel init_inode() on another CPU here. */
+    spin_lock(&keycopy_lock);
     /* args is already in CPU order */
-    return le32_to_cpu(INODE_PKEY(inode)->k_dir_id) == args -> objectid;
+    if (le32_to_cpu(INODE_PKEY(inode)->k_dir_id) == args -> objectid)
+	retval = 1;
+    else
+	/* If The key does not match, lets see if we are racing
+	   with another iget4, that already progressed so far
+	   to reiserfs_read_inode2() and was preempted in
+	   call to search_by_key(). The signs of that are:
+	     Inode is locked
+	     dirid and object id are zero (not yet initialized)*/
+	retval = (inode->i_state & I_LOCK) &&
+		 !INODE_PKEY(inode)->k_dir_id &&
+		 !INODE_PKEY(inode)->k_objectid;
+
+    spin_unlock(&keycopy_lock);
+    return retval;
 }
 
 struct inode * reiserfs_iget (struct super_block * s, const struct cpu_key * key)

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Tue, May 13, 2003 at 05:00:09PM +0200, Manuel Krause wrote:

> >No. I have old patch instead that applies to 2.4.20 and basically every 
> >other kernel
> >and that I am pushing to Marchelo as this iget5_locked is too intrusive at 
> >current 2.4
> >development stage.
> In what kind? Or: What kind of intrusion do you mean then (see below)?!

It touches too much code, the code vfs code, nfs and coda (and reiserfs of course).

> >This old patch is attached.
> >>Always appreciated are less intrusive ones regarding i/o speed ;-))
> >I/O speed should be the same with all the aproaches.
> >The patch below is a bit more cpu hungry as it introduces one more 
> >spinlock.
> But, errhm, why should I use a patch that uses more cpu and doesn't 
> speed up disk i/o (see above)???

Well, you are free to use that iget5_locked backport, but I cannot feed it to Marcelo now,
and I need the bug to be fixed, so I am sending this old patch now and will revert to
proper fix asfter 2.4.22 is out.
(when it is out, you can revert the patch I sent in previous mail and apply the iget5_locked backport).
And the more testing is better as always ;)

> I only did a very little testing when the discussions on 
> iget5_locked_for-2.4.21-pre5-datalogging.diff, kinoded-? + 
> inode-dirty-for-kinoded began. And it seemed that kinoded + inode-dirty 
> doesn't make a difference without quota (as Chris already pointed out) 
> but that I loose 2s on OpenOffice- and 1s on Netscape7-startup time 
> without your -pre5 patch. Is that possible or should I improve my 
> looking-at-the-clock or re-verify that?

Hm. Loose as in startup now takes XX sec more ? Or XX sec less?

Thank you.

Bye,
    Oleg

Re: Data-logging and md as / fs bug

[Manuel Krause]

Hi and thank you, for the quick reply!

On 05/13/2003 04:25 PM, Oleg Drokin wrote:
> Hello!
> 
> On Tue, May 13, 2003 at 04:15:30PM +0200, Manuel Krause wrote:
> 
> 
>>Do you have something new to try? Does this original patch affect disk 
>>i/o perfomance (positive/negative)?
> 
> 
> No. I have old patch instead that applies to 2.4.20 and basically every other kernel
> and that I am pushing to Marchelo as this iget5_locked is too intrusive at current 2.4
> development stage.

In what kind? Or: What kind of intrusion do you mean then (see below)?!

> This old patch is attached.
> 
> 
>>Always appreciated are less intrusive ones regarding i/o speed ;-))
> 
> 
> I/O speed should be the same with all the aproaches.
> The patch below is a bit more cpu hungry as it introduces one more spinlock.
> 
> Bye,
>     Oleg
[Patch]

But, errhm, why should I use a patch that uses more cpu and doesn't 
speed up disk i/o (see above)???

I only did a very little testing when the discussions on 
iget5_locked_for-2.4.21-pre5-datalogging.diff, kinoded-? + 
inode-dirty-for-kinoded began. And it seemed that kinoded + inode-dirty 
doesn't make a difference without quota (as Chris already pointed out) 
but that I loose 2s on OpenOffice- and 1s on Netscape7-startup time 
without your -pre5 patch. Is that possible or should I improve my 
looking-at-the-clock or re-verify that?


Thanks,

  Manuel

Re: Data-logging and md as / fs bug

[Manuel Krause]

On 05/13/2003 04:59 PM, Oleg Drokin wrote:
> Hello!
> 
> On Tue, May 13, 2003 at 05:00:09PM +0200, Manuel Krause wrote:
> 
[...]
O.k. Quite thoughtful. But "reverting to proper fix" later sounds 
strange to me.

> 
>>I only did a very little testing when the discussions on 
>>iget5_locked_for-2.4.21-pre5-datalogging.diff, kinoded-? + 
>>inode-dirty-for-kinoded began. And it seemed that kinoded + inode-dirty 
>>doesn't make a difference without quota (as Chris already pointed out) 
>>but that I loose 2s on OpenOffice- and 1s on Netscape7-startup time 
>>without your -pre5 patch. Is that possible or should I improve my 
>>looking-at-the-clock or re-verify that?
> 
> 
> Hm. Loose as in startup now takes XX sec more ? Or XX sec less?

Sorry,
with "loss" <-> "time" I meant "loosing" spare time, "decrease of" work 
time to use ... my English, yes, I'm still still learning.

Clearly, what I meant:
        with iget5-pre5-patch,  without,  with your posted patch
App.   NS7  OOo                NS7  OOo
(s)    10   17                 11+  19+     untested
-
(s) = startup times in seconds

Bye,

  Manuel

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Tue, May 13, 2003 at 05:39:44PM +0200, Manuel Krause wrote:
> O.k. Quite thoughtful. But "reverting to proper fix" later sounds 
> strange to me.

This is because the "non-intrusive" fix is a kind of hack.
And Coda have fixed this with hack too (only they accepted the speed
penalty and run iget4() under semaphore).

> >>I only did a very little testing when the discussions on 
> >>iget5_locked_for-2.4.21-pre5-datalogging.diff, kinoded-? + 
> >>inode-dirty-for-kinoded began. And it seemed that kinoded + inode-dirty 
> >>doesn't make a difference without quota (as Chris already pointed out) 
> >>but that I loose 2s on OpenOffice- and 1s on Netscape7-startup time 
> >>without your -pre5 patch. Is that possible or should I improve my 
> >>looking-at-the-clock or re-verify that?
> >Hm. Loose as in startup now takes XX sec more ? Or XX sec less?
> Sorry,
> with "loss" <-> "time" I meant "loosing" spare time, "decrease of" work 
> time to use ... my English, yes, I'm still still learning.
> 
> Clearly, what I meant:
>        with iget5-pre5-patch,  without,  with your posted patch
> App.   NS7  OOo                NS7  OOo
> (s)    10   17                 11+  19+     untested
> -
> (s) = startup times in seconds

Hm. Strange. Of course there are some VFS changes present but they are
inode loading related, so I do not think they should be visible at all.
Can you retest and see if this is not a measurement error/random fluctuations?

Thank you.

Bye,
    Oleg

Re: Data-logging and md as / fs bug

[Newsmail]

wow could somebody make my mind a bit more clear: what patches to use 
exactly to have the more error less functioning with datalogging without 
quota? Manuel uses patches posted only on the mailing list but not present 
on suse.de or namesys.com apparently. is it better to use what he uses, or 
some of them are +- useless as not on namesys, or what happens exactly?
cheers,
greg

ps: what about iget5_locked? is it safe to use?

>Currently running 2.4.21-rc2 +
>
>patch-2.4.21-rc2.rfs01.m02-akpm-b_journal_head-1.diff
>patch-2.4.21-rc2.rfs02.m03-relocation-8.diff
>patch-2.4.21-rc2.rfs03.m04-reiserfs-sync_fs-4.diff
>patch-2.4.21-rc2.rfs04.m05-data-logging-37.diff
>patch-2.4.21-rc2.rfs05.m06-logging-export.diff
>patch-2.4.21-rc2.rfs06.m06-write_times.diff
>patch-2.4.21-rc2.rfs07.m09.kinoded-9.ML.diff
>patch-2.4.21-rc2.rfs08.m11.inode-dirty-for-kinoded.ML.diff
>patch-2.4.21-rc2.rfs09.m12.search_reada-4.diff
>patch-2.4.21-rc2.rfs10.iget5_locked_for_datalogging.namesys.noquota.diff
>preempt-kernel-rml-2.4.21-rc2-was-pre1-1.0.patch
>patch.mk.01.Makefile.diff
>patch.mk.02.r128_drv.diff
>patch.mk.03.2.4.21-rc2-Config.in.diff
>
>applied in this order.
>
>-
>rfs??=reiserfs, m??=Chris' patches, ML=posted to reiserfs-list only, mk=my 
>own needed changes

Re: Data-logging and md as / fs bug

[Christian Mayrhuber]

Am Dienstag, 13. Mai 2003 23:52 schrieb Newsmail:
> wow could somebody make my mind a bit more clear: what patches to use
> exactly to have the more error less functioning with datalogging without
> quota? Manuel uses patches posted only on the mailing list but not present
> on suse.de or namesys.com apparently. is it better to use what he uses, or
> some of them are +- useless as not on namesys, or what happens exactly?
> cheers,
> greg


At the moment the newest ones are at:
ftp://ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/

Needed for data logging:
02-akpm-b_journal_head-1.diff.gz
03-relocation-8.diff.gz
04-reiserfs-sync_fs-4.diff.gz
05-data-logging-37.diff.gz
06-logging-export.diff.gz

General speedup:
06-write_times.diff.gz 

Quota support:
07-quota-v2-2.4.21.diff.gz
08-reiserfs-quota-27.diff.gz
09-kinoded-8.diff.gz
10-reiserfs-quota-link-fix.diff.gz

Those patches apply to 2.4.21-rc1 and 2.4.21-rc2.
If you want data logging only you do not need
"General Speedup" and "Quota support".

I have all of them running and did some stress tests
over the weekend. Those patches are behaving nice.
They have good performance, seem stable and look like
they do not corrupt any data.

Hopefully, the data logging part is due for inclusion in
2.4.22-pre.
-- 
lg, Chris

Re: Data-logging and md as / fs bug

[Oleg Drokin]

Hello!

On Tue, May 13, 2003 at 10:52:40PM +0100, Newsmail wrote:

> ps: what about iget5_locked? is it safe to use?

I've got not a single bugreport on it, it passed our tester's load too.
And it works for me. So I assume it is reasonably safe to use.

(alll of this is only true for 2.4.21-pre5+ stuff, the iget5_locked backport to 2.4.20
seems to be broken).

Bye,
    Oleg

Re: Data-logging and md as / fs bug

[Manuel Krause]

On 05/13/2003 05:42 PM, Oleg Drokin wrote:
> Hello!
> 
> On Tue, May 13, 2003 at 05:39:44PM +0200, Manuel Krause wrote:
> 
[...]
>>
>>Clearly, what I meant:
>>       with iget5-pre5-patch,  without,  with your posted patch
>>App.   NS7  OOo                NS7  OOo
>>(s)    10   17                 11+  19+     untested
>>-
>>(s) = startup times in seconds
> 
> 
> Hm. Strange. Of course there are some VFS changes present but they are
> inode loading related, so I do not think they should be visible at all.
> Can you retest and see if this is not a measurement error/random fluctuations?
> 

Please, excuse the delay. I had to dry and reassemble my notebook 
keyboard first. :-((

I was able to reproduce the differences shown above, grin, but as 
general fluctuations... Netscape7 always takes 10..12s and OpenOffice 
always 17...19s to start _no_matter_ whether iget5 is applied, with 
kinoded-9 with or without dirty-inodes-patch or none of these three.

So, simply forget what I've written.


Bye,

  Manuel