reiserfs v3 patches updated

reiserfs v3 patches updated

[Chris Mason]

Hello everyone,

These aren't really data=ordered specific anymore, so I've moved them
around a little in my ftp directory.  You can download the set of
experimental reiserfs v3 patches from:

ftp://ftp.suse.com/pub/people/mason/patches/reiserfs/2.6.5

Since some of these are in -mm and some are not, there are two series
files.  series.linus gives you the patches needed for mainline 2.6.5,
and series.mm gives you the patches needed for 2.6.5-mm1

Most of these are from Jeff Mahoney and I, they include:

bug fixes
logging optimizations
data=ordered support
xattrs
acls
quotas
error messages with device names (based on Oleg's 2.4 patch)
block allocator improvements

Hans, could you please comment on the xattr and acl patches?  Something
more substantial then "I don't want xattrs in v3" is needed.  If there
is some technical objection to the patches I'd really like to discuss
it.

The block allocator improvements is our attempt to reduce
fragmentation.  The patch defaults to the regular 2.6.5 block allocator,
but has options documented at the top of the patch that allow grouping
of blocks by packing locality or object id.  It also has an option to
inherit lightly used packing localities across multiple subdirs, which
keeps things closer together in the tree if you have a bunch of subdirs
without much in them.

If anyone is interested in experimenting with the block allocator stuff,
please let me know.

-chris

Re: reiserfs v3 patches updated

[Christian Mayrhuber]

On Tuesday 06 April 2004 02:10, Chris Mason wrote:

Seem to run fine so far with
 rw,noatime,nodiratime,acl,user_xattr,data=ordered,alloc=skip_busy:dirid_groups,packing_groups

>
> The block allocator improvements is our attempt to reduce
> fragmentation.  The patch defaults to the regular 2.6.5 block allocator,
> but has options documented at the top of the patch that allow grouping
> of blocks by packing locality or object id.  It also has an option to
> inherit lightly used packing localities across multiple subdirs, which
> keeps things closer together in the tree if you have a bunch of subdirs
> without much in them.
>
> If anyone is interested in experimenting with the block allocator stuff,
> please let me know.
So it is the block allocator that makes ext3 preferable to oracle database 
load?
Are there any figures how "mount -o alloc=oid_groups" influences oracle 
performance?


-- 
lg, Chris

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 12:38, Christian Mayrhuber wrote:
> On Tuesday 06 April 2004 02:10, Chris Mason wrote:
> 
> Seem to run fine so far with
>  rw,noatime,nodiratime,acl,user_xattr,data=ordered,alloc=skip_busy:dirid_groups,packing_groups
> 
Good to hear.

> >
> > The block allocator improvements is our attempt to reduce
> > fragmentation.  The patch defaults to the regular 2.6.5 block allocator,
> > but has options documented at the top of the patch that allow grouping
> > of blocks by packing locality or object id.  It also has an option to
> > inherit lightly used packing localities across multiple subdirs, which
> > keeps things closer together in the tree if you have a bunch of subdirs
> > without much in them.
> >
> > If anyone is interested in experimenting with the block allocator stuff,
> > please let me know.
> So it is the block allocator that makes ext3 preferable to oracle database 
> load?

Yes and no.  For databases you tend to preallocate the files one at a
time, and fragmentation isn't a huge issue.  If you have your tables set
to autoextend, and you frequently need to grow them, the block allocator
might be causing fragmentation.

> Are there any figures how "mount -o alloc=oid_groups" influences oracle 
> performance?
> 

None, this code is pretty new.  The benchmarks so far are from iozone
and tiobench.pl

-chris

Re: reiserfs v3 patches updated

[camis]

> Seem to run fine so far with
> rw,noatime,nodiratime,acl,user_xattr,data=ordered,alloc=skip_busy:dirid_groups,packing_groups

Has anyone done any throughput/benchmarks for the various
new patches/code?

>The block allocator improvements is our attempt to reduce
>fragmentation.  The patch defaults to the regular 2.6.5 block allocator,
>but has options documented at the top of the patch that allow grouping
>of blocks by packing locality or object id.  It also has an option to
>inherit lightly used packing localities across multiple subdirs, which
>keeps things closer together in the tree if you have a bunch of subdirs
>without much in them.

Any of these new features documented anywhere? ;)

Cami

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 14:29, camis wrote:
> > Seem to run fine so far with
> > rw,noatime,nodiratime,acl,user_xattr,data=ordered,alloc=skip_busy:dirid_groups,packing_groups
> 
> Has anyone done any throughput/benchmarks for the various
> new patches/code?
> 
The block allocator stuff is fresh from the oven and still warm inside. 
I'll be posting benchmarks for it as the week goes on.

> >The block allocator improvements is our attempt to reduce
> >fragmentation.  The patch defaults to the regular 2.6.5 block allocator,
> >but has options documented at the top of the patch that allow grouping
> >of blocks by packing locality or object id.  It also has an option to
> >inherit lightly used packing localities across multiple subdirs, which
> >keeps things closer together in the tree if you have a bunch of subdirs
> >without much in them.
> 
> Any of these new features documented anywhere? ;)

I'm writing up a mount option summary, the block allocator stuff is all
documented at the top of the patch.

-chris

Re: reiserfs v3 patches updated

[camis]

>>Has anyone done any throughput/benchmarks for the various
>>new patches/code?
> 
> The block allocator stuff is fresh from the oven and still warm inside. 
> I'll be posting benchmarks for it as the week goes on.

Something interesitng:
I have 8 dell 2650's (dual xeon 2.8ghz+hyperthreading) and i've setup
the one machine above with the patches.. All 8 machines are incoming
MX/smtp machines which handle quite large loads (5gigs of mail per day).

machine 1: 
(mounted:noatime,nodiratime,data=ordered,alloc=skip_busy:dirid_groups,packing_groups)

  21:16:17  up 12:17,  1 user,  load average: 0.45, 1.04, 1.07
375 processes: 374 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    7.2%    0.0%   32.4%   0.0%     0.8%    5.2%  353.2%
            cpu00    1.8%    0.0%   10.6%   0.1%     0.9%    1.3%   85.0%
            cpu01    1.5%    0.0%    7.4%   0.0%     0.1%    0.9%   89.9%
            cpu02    1.7%    0.0%    7.0%   0.0%     0.1%    1.7%   89.3%
            cpu03    1.8%    0.0%    7.4%   0.0%     0.1%    1.5%   88.9%

Iowait total stays hovering at around the 6->8% mark..

machine 2->8: (mounted: noatime,nodiratime)

  21:14:31  up 1 day,  8:41,  1 user,  load average: 0.43, 0.72, 0.66
392 processes: 391 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    8.0%    0.0%   35.2%   0.0%     1.6%    0.8%  352.8%
            cpu00    2.0%    0.0%   11.1%   0.1%     1.5%    0.3%   84.6%
            cpu01    2.0%    0.0%    7.7%   0.0%     0.3%    0.1%   89.5%
            cpu02    2.2%    0.0%    7.7%   0.0%     0.0%    0.3%   89.5%
            cpu03    1.8%    0.0%    8.7%   0.0%     0.0%    0.0%   89.3%

The majority of the rest of the machines iowait hover around the 1%
mark.. CPU time tends to be about the same, just the iowait is much
much higher..

Cami

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 15:17, camis wrote:
> >>Has anyone done any throughput/benchmarks for the various
> >>new patches/code?
> > 
> > The block allocator stuff is fresh from the oven and still warm inside. 
> > I'll be posting benchmarks for it as the week goes on.
> 
> Something interesitng:
> I have 8 dell 2650's (dual xeon 2.8ghz+hyperthreading) and i've setup
> the one machine above with the patches.. All 8 machines are incoming
> MX/smtp machines which handle quite large loads (5gigs of mail per day).
> 
> machine 1: 
> (mounted:noatime,nodiratime,data=ordered,alloc=skip_busy:dirid_groups,packing_groups)
> 
>   21:16:17  up 12:17,  1 user,  load average: 0.45, 1.04, 1.07
> 375 processes: 374 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
>             total    7.2%    0.0%   32.4%   0.0%     0.8%    5.2%  353.2%
>             cpu00    1.8%    0.0%   10.6%   0.1%     0.9%    1.3%   85.0%
>             cpu01    1.5%    0.0%    7.4%   0.0%     0.1%    0.9%   89.9%
>             cpu02    1.7%    0.0%    7.0%   0.0%     0.1%    1.7%   89.3%
>             cpu03    1.8%    0.0%    7.4%   0.0%     0.1%    1.5%   88.9%
> 
> Iowait total stays hovering at around the 6->8% mark..
> 
> machine 2->8: (mounted: noatime,nodiratime)
> 
>   21:14:31  up 1 day,  8:41,  1 user,  load average: 0.43, 0.72, 0.66
> 392 processes: 391 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
>             total    8.0%    0.0%   35.2%   0.0%     1.6%    0.8%  352.8%
>             cpu00    2.0%    0.0%   11.1%   0.1%     1.5%    0.3%   84.6%
>             cpu01    2.0%    0.0%    7.7%   0.0%     0.3%    0.1%   89.5%
>             cpu02    2.2%    0.0%    7.7%   0.0%     0.0%    0.3%   89.5%
>             cpu03    1.8%    0.0%    8.7%   0.0%     0.0%    0.0%   89.3%
> 
> The majority of the rest of the machines iowait hover around the 1%
> mark.. CPU time tends to be about the same, just the iowait is much
> much higher..

Very interesting.  data=ordered makes fsync more expensive, since it
ends up syncing more then just the buffers for that one file.  Could you
please try removing data=ordered from machine1?

-chris

Re: reiserfs v3 patches updated

[camis]

>>The majority of the rest of the machines iowait hover around the 1%
>>mark.. CPU time tends to be about the same, just the iowait is much
>>much higher..
> 
> Very interesting.  data=ordered makes fsync more expensive, since it
> ends up syncing more then just the buffers for that one file.  Could you
> please try removing data=ordered from machine1?

Ok.. after leaving it for a few minutes..

machine 1: (mounted: 
noatime,nodiratime,alloc=skip_busy:dirid_groups,packing_groups)
  21:48:08  up 12:49,  1 user,  load average: 0.57, 0.74, 0.92
338 processes: 337 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    9.6%    0.0%   39.2%   0.0%     1.2%    6.8%  342.0%
            cpu00    2.2%    0.0%   12.4%   0.1%     0.7%    1.3%   82.9%
            cpu01    2.6%    0.0%    9.1%   0.0%     0.1%    1.9%   86.0%
            cpu02    2.4%    0.0%    9.0%   0.0%     0.0%    0.9%   87.5%
            cpu03    2.6%    0.0%    8.9%   0.0%     0.0%    2.6%   85.6%

At first i thought that it *might* be just this machine itself,
so i rebooted machine2 with the same kernel patches..

machine 2: (mounted: 
noatime,nodiratime,alloc=skip_busy:dirid_groups,packing_groups)
  21:46:24  up 7 min,  1 user,  load average: 0.85, 0.64, 0.27
315 processes: 314 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    9.6%    0.0%   34.8%   0.0%     1.2%    7.2%  346.4%
            cpu00    2.5%    0.0%    7.1%   0.1%     1.1%    2.1%   86.8%
            cpu01    2.6%    0.0%    8.0%   0.0%     0.1%    1.1%   87.8%
            cpu02    2.4%    0.0%   10.9%   0.0%     0.1%    1.7%   84.6%
            cpu03    2.1%    0.0%    8.6%   0.0%     0.0%    2.3%   86.8%

machine 3->8: (mounted: noatime,nodiratime)
  21:46:21  up 1 day,  9:12,  1 user,  load average: 1.07, 2.24, 1.88
295 processes: 294 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total   11.2%    0.0%   40.8%   0.0%     2.0%    1.6%  343.2%
            cpu00    2.7%    0.0%   10.4%   0.1%     1.5%    0.3%   84.7%
            cpu01    3.0%    0.0%   10.1%   0.0%     0.1%    0.5%   85.9%
            cpu02    2.6%    0.0%   11.1%   0.0%     0.1%    0.5%   85.3%
            cpu03    2.8%    0.0%    9.2%   0.0%     0.1%    0.3%   87.2%

What i then tried on machine1 was remounting it noatime,nodiratime and
what was wierd was that the iowait stayed exactly the same, no indication
of dropping at all.. Does the kernel patches change any of the default
mount options at all? If i put the stock 2.6.5 kernel back on without
the patch applied and mount it back as noatime,nodiratime, the iowait
drops back to its normal 1%..

Cami

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 15:53, camis wrote:
> >>The majority of the rest of the machines iowait hover around the 1%
> >>mark.. CPU time tends to be about the same, just the iowait is much
> >>much higher..
> > 
> > Very interesting.  data=ordered makes fsync more expensive, since it
> > ends up syncing more then just the buffers for that one file.  Could you
> > please try removing data=ordered from machine1?
> 
> Ok.. after leaving it for a few minutes..

[ higher io wait percentage with patches applied ]

> What i then tried on machine1 was remounting it noatime,nodiratime and
> what was wierd was that the iowait stayed exactly the same, no indication
> of dropping at all.. Does the kernel patches change any of the default
> mount options at all? If i put the stock 2.6.5 kernel back on without
> the patch applied and mount it back as noatime,nodiratime, the iowait
> drops back to its normal 1%..

Do you have any numbers for the amount of mail delivered per second on
each box?  I've got an idea that should help lower the io wait
percentage as well, trying a few things here.

-chris

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 15:53, camis wrote:
> >>The majority of the rest of the machines iowait hover around the 1%
> >>mark.. CPU time tends to be about the same, just the iowait is much
> >>much higher..
> > 
> > Very interesting.  data=ordered makes fsync more expensive, since it
> > ends up syncing more then just the buffers for that one file.  Could you
> > please try removing data=ordered from machine1?
> 
> Ok.. after leaving it for a few minutes..

I'm a little slow today.  data=ordered is the default with these
patches.  You need to mount -o data=writeback.

-chris

Re: reiserfs v3 patches updated

[Cami]

>>What i then tried on machine1 was remounting it noatime,nodiratime and
>>what was wierd was that the iowait stayed exactly the same, no indication
>>of dropping at all.. Does the kernel patches change any of the default
>>mount options at all? If i put the stock 2.6.5 kernel back on without
>>the patch applied and mount it back as noatime,nodiratime, the iowait
>>drops back to its normal 1%..
> 
> Do you have any numbers for the amount of mail delivered per second on
> each box? 

Currently, each machine is doing about 10 mails per second.

Puring peak hours this figure can increase to the 20's and 30's
and about 1500 concurrent connections each (at around
20mbit/s of incoming mail)..

> I've got an idea that should help lower the io wait
> percentage as well, trying a few things here.

I'll be looking forward to that..

Cami

Re: reiserfs v3 patches updated

[Cami]

>>>>The majority of the rest of the machines iowait hover around the 1%
>>>>mark.. CPU time tends to be about the same, just the iowait is much
>>>>much higher..
>>>
>>>Very interesting.  data=ordered makes fsync more expensive, since it
>>>ends up syncing more then just the buffers for that one file.  Could you
>>>please try removing data=ordered from machine1?
>>
>>Ok.. after leaving it for a few minutes..
> 
> 
> I'm a little slow today.  data=ordered is the default with these
> patches.  You need to mount -o data=writeback.

data=writeback yields pretty much the same iowait results..
(machine 1+2 are around 5%->8% whereas machine 3->8 are at around 0.8%)

Cami

Re: reiserfs v3 patches updated

[Chris Mason]

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

On Tue, 2004-04-06 at 16:51, Cami wrote:
> >>>>The majority of the rest of the machines iowait hover around the 1%
> >>>>mark.. CPU time tends to be about the same, just the iowait is much
> >>>>much higher..
> >>>
> >>>Very interesting.  data=ordered makes fsync more expensive, since it
> >>>ends up syncing more then just the buffers for that one file.  Could you
> >>>please try removing data=ordered from machine1?
> >>
> >>Ok.. after leaving it for a few minutes..
> > 
> > I'm a little slow today.  data=ordered is the default with these
> > patches.  You need to mount -o data=writeback.
> 
> data=writeback yields pretty much the same iowait results..
> (machine 1+2 are around 5%->8% whereas machine 3->8 are at around 0.8%)

This is so much faster I'm worried the io isn't actually getting done. 
In the mail server benchmark I use (synctest -n 1 -t 50 -f -F), the time
went from 2m15s to 43s.  The old 2m15s was still faster then I used to
get with unpatched reiserfs.

I'm posting this for the truly brave among you and a little review.  I
need to do more tests on it.  The basic idea is to make sure we don't
start writeback on the log buffers and metadata if someone is already
doing it.

Also, the reiserfs work queue is not kicked during transaction end if
some other process is going to do the commit.  This saves a lot of
context switches.

-chris


[-- Attachment #2: reiserfs-delayed-work --]
[-- Type: text/x-patch, Size: 2421 bytes --]

Index: linux.mm/fs/reiserfs/journal.c
===================================================================
--- linux.mm.orig/fs/reiserfs/journal.c	2004-04-05 17:46:12.000000000 -0400
+++ linux.mm/fs/reiserfs/journal.c	2004-04-06 17:00:25.391877520 -0400
@@ -86,6 +86,7 @@ static struct workqueue_struct *commit_w
 /* journal list state bits */
 #define LIST_TOUCHED 1
 #define LIST_DIRTY   2
+#define LIST_COMMIT_PENDING  4		/* someone will commit this list */
 
 /* flags for do_journal_end */
 #define FLUSH_ALL   1		/* flush commit and real blocks */
@@ -2484,7 +2485,9 @@ static void let_transaction_grow(struct 
 {
     unsigned long bcount = SB_JOURNAL(sb)->j_bcount;
     while(1) {
-	yield();
+	set_current_state(TASK_UNINTERRUPTIBLE);
+	schedule_timeout(1);
+	SB_JOURNAL(sb)->j_current_jl->j_state |= LIST_COMMIT_PENDING;
         while ((atomic_read(&SB_JOURNAL(sb)->j_wcount) > 0 ||
 	        atomic_read(&SB_JOURNAL(sb)->j_jlock)) &&
 	       SB_JOURNAL(sb)->j_trans_id == trans_id) {
@@ -2920,9 +2923,15 @@ static void flush_async_commits(void *p)
       flush_commit_list(p_s_sb, jl, 1);
   }
   unlock_kernel();
-  atomic_inc(&SB_JOURNAL(p_s_sb)->j_async_throttle);
-  filemap_fdatawrite(p_s_sb->s_bdev->bd_inode->i_mapping);
-  atomic_dec(&SB_JOURNAL(p_s_sb)->j_async_throttle);
+  /*
+   * this is a little racey, but there's no harm in missing
+   * the filemap_fdata_write
+   */
+  if (!atomic_read(&SB_JOURNAL(p_s_sb)->j_async_throttle)) {
+      atomic_inc(&SB_JOURNAL(p_s_sb)->j_async_throttle);
+      filemap_fdatawrite(p_s_sb->s_bdev->bd_inode->i_mapping);
+      atomic_dec(&SB_JOURNAL(p_s_sb)->j_async_throttle);
+  }
 }
 
 /*
@@ -3011,7 +3020,8 @@ static int check_journal_end(struct reis
 
       jl = SB_JOURNAL(p_s_sb)->j_current_jl;
       trans_id = jl->j_trans_id;
-
+      if (wait_on_commit)
+        jl->j_state |= LIST_COMMIT_PENDING;
       atomic_set(&(SB_JOURNAL(p_s_sb)->j_jlock), 1) ;
       if (flush) {
         SB_JOURNAL(p_s_sb)->j_next_full_flush = 1 ;
@@ -3533,8 +3543,8 @@ static int do_journal_end(struct reiserf
   if (flush) {
     flush_commit_list(p_s_sb, jl, 1) ;
     flush_journal_list(p_s_sb, jl, 1) ;
-  } else
-    queue_work(commit_wq, &SB_JOURNAL(p_s_sb)->j_work);
+  } else if (!(jl->j_state & LIST_COMMIT_PENDING))
+    queue_delayed_work(commit_wq, &SB_JOURNAL(p_s_sb)->j_work, HZ/10);
 
 
   /* if the next transaction has any chance of wrapping, flush 

Re: reiserfs v3 patches updated

[Cami]

>>>I'm a little slow today.  data=ordered is the default with these
>>>patches.  You need to mount -o data=writeback.
>>
>>data=writeback yields pretty much the same iowait results..
>>(machine 1+2 are around 5%->8% whereas machine 3->8 are at around 0.8%)
> 
> This is so much faster I'm worried the io isn't actually getting done.
> In the mail server benchmark I use (synctest -n 1 -t 50 -f -F), the time
> went from 2m15s to 43s.  The old 2m15s was still faster then I used to
> get with unpatched reiserfs.
> 
> I'm posting this for the truly brave among you and a little review.  I
> need to do more tests on it.  The basic idea is to make sure we don't
> start writeback on the log buffers and metadata if someone is already
> doing it.
> 
> Also, the reiserfs work queue is not kicked during transaction end if
> some other process is going to do the commit.  This saves a lot of
> context switches.

And just as i was about to head into bed ;)

  23:26:25  up 5 min,  1 user,  load average: 0.62, 0.36, 0.14
340 processes: 339 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    7.6%    0.0%   30.8%   0.0%     1.2%    0.4%  358.8%
            cpu00    1.7%    0.0%    6.6%   0.1%     1.1%    0.1%   90.0%
            cpu01    2.1%    0.0%   11.1%   0.0%     0.0%    0.0%   86.7%
            cpu02    2.0%    0.0%    6.8%   0.0%     0.0%    0.3%   90.6%
            cpu03    1.9%    0.0%    6.7%   0.0%     0.0%    0.1%   91.1%

  23:27:11  up 5 min,  1 user,  load average: 0.40, 0.34, 0.14
343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    6.8%    0.0%   26.0%   0.0%     0.8%    0.4%  364.8%
            cpu00    1.7%    0.0%    5.9%   0.1%     0.9%    0.1%   91.0%
            cpu01    1.5%    0.0%    5.3%   0.0%     0.0%    0.0%   93.1%
            cpu02    1.9%    0.0%    4.7%   0.0%     0.0%    0.1%   93.1%
            cpu03    1.9%    0.0%    9.9%   0.0%     0.1%    0.0%   87.9%

  23:27:21  up 5 min,  1 user,  load average: 0.63, 0.40, 0.16
343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    8.0%    0.0%   28.4%   0.0%     1.2%    0.4%  360.8%
            cpu00    2.2%    0.0%    6.1%   0.1%     1.1%    0.0%   90.2%
            cpu01    2.0%    0.0%   10.4%   0.0%     0.1%    0.3%   86.8%
            cpu02    1.7%    0.0%    6.4%   0.0%     0.0%    0.1%   91.6%
            cpu03    1.7%    0.0%    5.7%   0.0%     0.0%    0.1%   92.3%

  23:27:32  up 6 min,  1 user,  load average: 0.53, 0.38, 0.16
343 processes: 341 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total   10.0%    0.0%   35.6%   0.0%     1.6%    0.8%  350.8%
            cpu00    2.4%    0.0%    8.3%   0.1%     1.3%    0.1%   87.4%
            cpu01    2.6%    0.0%   11.8%   0.0%     0.1%    0.1%   85.1%
            cpu02    2.4%    0.0%    7.8%   0.0%     0.1%    0.1%   89.3%
            cpu03    2.4%    0.0%    8.0%   0.0%     0.0%    0.3%   89.1%

  23:27:37  up 6 min,  1 user,  load average: 0.49, 0.38, 0.16
343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    6.4%    0.0%   26.4%   0.0%     0.4%    0.0%  365.2%
            cpu00    1.7%    0.0%    5.9%   0.1%     0.5%    0.0%   91.6%
            cpu01    1.5%    0.0%    9.5%   0.0%     0.0%    0.0%   88.9%
            cpu02    1.7%    0.0%    5.5%   0.0%     0.0%    0.1%   92.5%
            cpu03    1.7%    0.0%    5.7%   0.0%     0.1%    0.1%   92.2%

  23:27:47  up 6 min,  1 user,  load average: 0.41, 0.36, 0.16
343 processes: 342 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
            total    8.0%    0.0%   29.2%   0.0%     1.2%    0.4%  360.0%
            cpu00    2.0%    0.0%    9.7%   0.1%     0.9%    0.1%   86.8%
            cpu01    2.2%    0.0%    5.9%   0.0%     0.0%    0.1%   91.6%
            cpu02    1.7%    0.0%    7.4%   0.0%     0.1%    0.0%   90.6%
            cpu03    2.4%    0.0%    6.1%   0.0%     0.0%    0.3%   91.0%

Hrmph! Its not going above 0.8% iowait.. it hangs around the 0.0% ->
0.04% mark.. Looks good, thanks.. ;)

Regards,
Cami

Re: reiserfs v3 patches updated

[Chris Mason]

On Tue, 2004-04-06 at 17:30, Cami wrote:
> >>>I'm a little slow today.  data=ordered is the default with these
> >>>patches.  You need to mount -o data=writeback.

> Hrmph! Its not going above 0.8% iowait.. it hangs around the 0.0% ->
> 0.04% mark.. Looks good, thanks.. ;)

Great to hear, thanks for getting me to look at this.

-chris

Re: reiserfs v3 patches updated - Bug

[Christian Mayrhuber]

On Tuesday 06 April 2004 18:38, Christian Mayrhuber wrote:

> On Tuesday 06 April 2004 02:10, Chris Mason wrote:
>
> Seem to run fine so far with
I've to correct myself. There seems to be a problem with
install. Version: install (coreutils) 5.0.91

install: cannot change owner of ,,/tmp/mkinitrd.18919/initrd/bin/echo" : 
operation not permitted

I can change the owner with chown without problems.
I tried with the mount options "rw,noatime,nodiratime,data=writeback".

"data=writeback" seems to get ignored. The fs always mounts with 
data=ordered.

This is a bug that has been introduced somewhere between 2.6.4 + data-logging
and 2.6.5 + data-logging, as install works fine unter 2.6.4 + data=ordered.

It has nothing to do with acl's, because this bug appears with and without
the acl mount option. The block allocator does not matter, too.


PS: If invalid mount options are specified to reiserfs it mounts "ro", but the 
invalid options show up in /proc/mounts. This makes it impossible to do a
mount -o remount,ro /
because all the wrong options are retained.
==> fstab cannot be fixed, reboot with other kernel required.
I suggest to print a warning for the invalid options and to ignore them
during mount.

-- 
lg, Chris

Re: reiserfs v3 patches updated - Bug

[Chris Mason]

On Wed, 2004-04-07 at 05:28, Christian Mayrhuber wrote:
> On Tuesday 06 April 2004 18:38, Christian Mayrhuber wrote:
> 
> > On Tuesday 06 April 2004 02:10, Chris Mason wrote:
> >
> > Seem to run fine so far with
> I've to correct myself. There seems to be a problem with
> install. Version: install (coreutils) 5.0.91
> 
> install: cannot change owner of ,,/tmp/mkinitrd.18919/initrd/bin/echo" : 
> operation not permitted
> 
> I can change the owner with chown without problems.

Could you please strace the failing function?

> I tried with the mount options "rw,noatime,nodiratime,data=writeback".
> 
> "data=writeback" seems to get ignored. The fs always mounts with 
> data=ordered.
> 
Hmmm, data=writeback is working for me, how are you mounting?

> This is a bug that has been introduced somewhere between 2.6.4 + data-logging
> and 2.6.5 + data-logging, as install works fine unter 2.6.4 + data=ordered.
> 
> It has nothing to do with acl's, because this bug appears with and without
> the acl mount option. The block allocator does not matter, too.
> 
> 
> PS: If invalid mount options are specified to reiserfs it mounts "ro", but the 
> invalid options show up in /proc/mounts. This makes it impossible to do a
> mount -o remount,ro /
> because all the wrong options are retained.
> ==> fstab cannot be fixed, reboot with other kernel required.
> I suggest to print a warning for the invalid options and to ignore them
> during mount.

Hmmm, I'll take a look.

Thanks
Chris

Re: reiserfs v3 patches updated - Bug

[Chris Mason]

On Wed, 2004-04-07 at 11:14, Christian Mayrhuber wrote:
> On Wednesday 07 April 2004 15:07, you wrote:
> > On Wed, 2004-04-07 at 05:28, Christian Mayrhuber wrote:
> > > On Tuesday 06 April 2004 18:38, Christian Mayrhuber wrote:
> > > > On Tuesday 06 April 2004 02:10, Chris Mason wrote:
> > > >
> > > > Seem to run fine so far with
> > >
> > > I've to correct myself. There seems to be a problem with
> > > install. Version: install (coreutils) 5.0.91
> > >
> > > install: cannot change owner of ,,/tmp/mkinitrd.18919/initrd/bin/echo" :
> > > operation not permitted
> > >
> > > I can change the owner with chown without problems.
> >
> > Could you please strace the failing function?
> 
> Attached. 
> 
> The function is
> chown32("/tmp/wavesearch-deb.log.bz2", -1, -1) = -1 EPERM (Operation not 
> permitted)
> 
> The same install works fine on 2.6.4 + data=ordered.
> The disk is mounted with data=ordered.

Strange stuff, we can't reproduce it here.  Are you sure you've got the
whole patch set applied (maybe missing permission-reiserfs?)

Thanks for the strace, we'll have to debug this when you get back.

-chris

Re: reiserfs v3 patches updated

[Hubert Chan]

Using stock 2.6.5, plus Reiser4 patches (which probably shouldn't make a
difference), plus Chris' patches (applied everything from series.linus):

...
  CC      fs/reiserfs/bitmap.o
In file included from fs/reiserfs/bitmap.c:8:
include/linux/reiserfs_fs.h: In function `reiserfs_transaction_running':
include/linux/reiserfs_fs.h:1761: error: structure has no member named `journal_info'
make[3]: *** [fs/reiserfs/bitmap.o] Error 1
make[2]: *** [fs/reiserfs] Error 2
make[1]: *** [fs] Error 2

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: reiserfs v3 patches updated - Bug

[Christian Mayrhuber]

On Thursday 08 April 2004 01:58, you wrote:

> Strange stuff, we can't reproduce it here.  Are you sure you've got the
> whole patch set applied (maybe missing permission-reiserfs?)
>
> Thanks for the strace, we'll have to debug this when you get back.
>
> -chris

I can confirm, this is a non-bug.
I guess there was some old patch lurking around in my local kernel tree.
With a clean 2.6.5 from kernel.org this bug does not exist.

"quilt push -a" Applied:
reiserfs-nesting-02
reiserfs-journal-writer
reiserfs-logging
reiserfs-jh-2
reiserfs-prealloc
reiserfs-tail-jh
reiserfs-writepage-ordered-race
reiserfs-file_write_hole_sd.diff
reiserfs-laptop-mode
reiserfs-truncate-leak
reiserfs-ordered-lat
reiserfs-dirty-warning
reiserfs_kfree-warning-fix.patch
reiserfs-end-trans-bkl
reiserfs-acl-mknod.diff
reiserfs-xattrs-04
reiserfs-acl-02
reiserfs-trusted-02
reiserfs-selinux-02
reiserfs-xattr-locking-02
reiserfs-quota
permission-reiserfs
reiserfs-warning.linus
reiserfs-group-alloc-8
reiserfs-delayed-work

Mount options:
rw,noatime,nodiratime,acl,user_xattr,data=ordered,alloc=skip_busy:dirid_groups,packing_groups

Everything looks good, now.
I'll let you know if I experience any strange things.

-- 
lg, Chris