Re: Nick's scheduler v18

[Nick Piggin]

Andrew Morton wrote:

> Mary Edie Meredith <maryedie@xxxxxxxx> wrote:
>
> > Nick,
> >
> > We ran your patch on STP against one of our database workloads (DBT3 on
> > postgreSQL which uses file system rather than raw).
> >
> > The test was able to compile, successfully start up the database,
> > successfully load the database from source file, successfully run the
> > power test (single stream update/query/delete).   
> >
> > It failed, however at the next stage, where it starts 8 streams of query
> > and one stream of updates/deletes where it ran for approximately 40
> > minutes (usually takes over an hour to complete).  The updates appear to
> > have completed and only queries were active at the time of failure.  See
> > the error message below from the database log.
> >
> > ...
> >
> > PANIC:  fdatasync of log file 1, segment 81 failed: Input/output error
>
> It's hard to see how a CPU scheduler change could cause fdatasync() to
> return EIO.
>
> What filesystem was being used?
>
> If it was ext2 then perhaps you hit the recently-fixed block allocator
> race.  That fix was merged after test9.  Please check the kernel logs for
> any filesystem error messages.

The kernel tested was test9-bk14 + my patch.

I don't think it would be due to a problem my patch. Perhaps different
scheduling patterns made some race more likely though.

> Also, please retry the run, see if it is repeatable.

I will let someone else take over from here ;) I'll run the test
again with the latest bk when I submit another round of STP tests
sometime.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/