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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
