On Tue, May 22 2007, Matt Mackall wrote:
> On Tue, May 22, 2007 at 11:21:20AM -0700, Andrew Morton wrote:
> > On Tue, 22 May 2007 12:35:11 -0400
> > Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> > > > On Wed, 16 May 2007 16:14:14
Chris Mason wrote:
On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
On Wed, 16 May 2007 16:14:14 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
The good news is that if you let it run long enough, the t
On Tue, May 22, 2007 at 11:21:20AM -0700, Andrew Morton wrote:
> On Tue, 22 May 2007 12:35:11 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> > > On Wed, 16 May 2007 16:14:14 -0400
> > > Chris Mason <[EMAIL PROTECTED]> wrote:
>
On Tue, May 22, 2007 at 11:21:20AM -0700, Andrew Morton wrote:
> >
> > I patched jbd's log_do_checkpoint to put all the blocks it wanted to
> > write in a radix tree, then send them all down in order at the end.
>
> Side note: we already have all of that capability in the kernel:
> sync_inode(blo
On Tue, 22 May 2007 12:35:11 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> > On Wed, 16 May 2007 16:14:14 -0400
> > Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> >
On Tue, May 22, 2007 at 01:50:13PM -0400, John Stoffel wrote:
> > "Chris" == Chris Mason <[EMAIL PROTECTED]> writes:
>
> Chris> On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
[ seeky writes while creating kernel trees on ext3 ]
> >> How do you know that it is a log flush rath
> "Chris" == Chris Mason <[EMAIL PROTECTED]> writes:
Chris> On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
>> On Wed, 16 May 2007 16:14:14 -0400
>> Chris Mason <[EMAIL PROTECTED]> wrote:
>>
>> > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
>> > > > The good n
On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 16:14:14 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> > > > The good news is that if you let it run long enough, the times
> > > > stabilize
Jeff Garzik wrote:
Jan Engelhardt wrote:
On May 16 2007 10:42, Chris Mason wrote:
For example, I'll pick on xfs for a minute. compilebench shows the
default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
kernel trees.
I suppose you used 'nobarrier'? [ http://lkml.org/lkml/2
On May 17, 5:10 am, Chris Mason <[EMAIL PROTECTED]> wrote:
On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 16:14:14 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
> > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> > > > The good news is that
On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 16:14:14 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> > > > The good news is that if you let it run long enough, the times
> > > > stabilize
Andrew Morton wrote:
> Chris Mason <[EMAIL PROTECTED]> wrote:
> > > Should be: it uses first-fit.
> > >
> > > > Looks like ext3 is just walking a list of
> > > > bh/jh, maybe we can just sort the silly thing?
> > >
> > > The IO scheduler is supposed to do that.
> > >
> > > But I don't know what's
On Wed, 16 May 2007 16:14:14 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> > > The good news is that if you let it run long enough, the times
> > > stabilize. The bad news is:
> > >
> > > create dir kernel-86 222MB in 15.85 second
On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote:
> > The good news is that if you let it run long enough, the times
> > stabilize. The bad news is:
> >
> > create dir kernel-86 222MB in 15.85 seconds (14.03 MB/s)
> > create dir kernel-87 222MB in 28.67 seconds (7.76 MB/s)
> > create
On Wed, 16 May 2007 15:53:59 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > Should be: it uses first-fit.
> >
> > > Looks like ext3 is just walking a list of
> > > bh/jh, maybe we can just sort the silly thing?
> >
> > The IO scheduler is supposed to do that.
> >
> > But I don't know wh
On Wed, May 16, 2007 at 12:33:42PM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 15:13:39 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > >
> > > If that's still working then the problem will _probably_ be directory
> > > writeout. Possibly inodes, but they should be well-laid-out.
> >
Jeff Garzik wrote:
Jan Engelhardt wrote:
On May 16 2007 10:42, Chris Mason wrote:
For example, I'll pick on xfs for a minute. compilebench shows the
default FS you get from mkfs.xfs is pretty slow for untarring a
bunch of
kernel trees.
I suppose you used 'nobarrier'? [ http://lkml.org/lkml
On Wed, 16 May 2007 15:13:39 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > If that's still working then the problem will _probably_ be directory
> > writeout. Possibly inodes, but they should be well-laid-out.
> >
> > Were you using dir_index? That might be screwing things up.
>
> Yes,
On Wed, May 16, 2007 at 08:12:09PM +0200, Jan Engelhardt wrote:
>
> On May 16 2007 10:42, Chris Mason wrote:
> >
> >For example, I'll pick on xfs for a minute. compilebench shows the
> >default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
> >kernel trees.
>
> I suppose you us
On May 16 2007 14:16, Jeffrey Hundstad wrote:
> Jeff Garzik wrote:
>> Jan Engelhardt wrote:
>> > On May 16 2007 10:42, Chris Mason wrote:
>> > > For example, I'll pick on xfs for a minute. compilebench shows
>> > > the
>> > > default FS you get from mkfs.xfs is pretty slow for untarring a
>> > >
On Wed, May 16, 2007 at 11:25:15AM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 13:11:56 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > At least on ext3, it may help to sort the blocks under io for
> > flushing...it may not. A bigger log would definitely help, but I would
> > say the m
Jan Engelhardt wrote:
On May 16 2007 10:42, Chris Mason wrote:
For example, I'll pick on xfs for a minute. compilebench shows the
default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
kernel trees.
I suppose you used 'nobarrier'? [ http://lkml.org/lkml/2006/5/19/33 ]
Shou
On Wed, 16 May 2007 13:11:56 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> At least on ext3, it may help to sort the blocks under io for
> flushing...it may not. A bigger log would definitely help, but I would
> say the mkfs defaults should be reasonable for a workload this simple.
>
> (data=wr
On May 16 2007 10:42, Chris Mason wrote:
>
>For example, I'll pick on xfs for a minute. compilebench shows the
>default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
>kernel trees.
I suppose you used 'nobarrier'? [ http://lkml.org/lkml/2006/5/19/33 ]
>Dave Chinner gave me som
On Wed, May 16, 2007 at 12:01:06PM -0400, Chuck Ebbert wrote:
> Chris Mason wrote:
> > For example, I'll pick on xfs for a minute. compilebench shows the
> > default FS you get from mkfs.xfs is pretty slow for untarring a
> > bunch of kernel trees. Dave Chinner gave me some mount options that
> >
Chris Mason wrote:
> For example, I'll pick on xfs for a minute. compilebench shows the
> default FS you get from mkfs.xfs is pretty slow for untarring a bunch of
> kernel trees. Dave Chinner gave me some mount options that make it
> dramatically better, but it still writes at 10MB/s on a sata dr
26 matches
Mail list logo
