Stuff has arrived.
ide-viro-2.5.32.patch
ide-lad-2.5.32.patch
ide-all-2.5.32.patch == ide-viro-2.5.32.patch + ide-lad-2.5.32.patch
ide-taskfile-2.5.32.patch
scsi-st-2.5.32.patch
There is one more thing to fix.
./fs/mpage.c
/*
* The largest-sized BIO which this code will assemble, in bytes. Set this
* to PAGE_CACHE_SIZE if your drivers are broken.
*/
#define MPAGE_BIO_MAX_SIZE 32768 //BIO_MAX_SIZE
This is confirmed with Al Viro and was required to make things sane!
We are back.
We is a development team being composed to reduce my load and import fresh
ideas. If you wnat to help please join in, we can make the halloween
party.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick wrote:
>
> ...
> There is one more thing to fix.
>
> ./fs/mpage.c
>
> /*
> * The largest-sized BIO which this code will assemble, in bytes. Set this
> * to PAGE_CACHE_SIZE if your drivers are broken.
> */
> #define MPAGE_BIO_MAX_SIZE 32768 //BIO_MAX_SIZE
>
> This is confirmed with Al Viro and was required to make things sane!
You'll need to do the same thing to fs/direct-io.c:DIO_BIO_MAX_SIZE
in that case.
I'd suggest that you just go in and change BIO_MAX_SECTORS
to 64. Or 32 if you happen to be using a qlogic controller :(
So everything's broken in there - a hardwired constant doesn't
cut it. Jens is cooking up an `add_page_to_bio()' API which
will do the right thing based upon q->max_sectors. But that
is not yet available.
Andrew,
I am just now getting back to crawling speeds in the 2.5 tree.
I can only comment on what works and what Viro tells me.
But if you think it needs to be globally set, until the updates from Jens
arrive, please send to Linus. I am running my stuff by Viro and company.
Cheers,
On Thu, 29 Aug 2002, Andrew Morton wrote:
> Andre Hedrick wrote:
> >
> > ...
> > There is one more thing to fix.
> >
> > ./fs/mpage.c
> >
> > /*
> > * The largest-sized BIO which this code will assemble, in bytes. Set this
> > * to PAGE_CACHE_SIZE if your drivers are broken.
> > */
> > #define MPAGE_BIO_MAX_SIZE 32768 //BIO_MAX_SIZE
> >
> > This is confirmed with Al Viro and was required to make things sane!
>
> You'll need to do the same thing to fs/direct-io.c:DIO_BIO_MAX_SIZE
> in that case.
>
> I'd suggest that you just go in and change BIO_MAX_SECTORS
> to 64. Or 32 if you happen to be using a qlogic controller :(
>
> So everything's broken in there - a hardwired constant doesn't
> cut it. Jens is cooking up an `add_page_to_bio()' API which
> will do the right thing based upon q->max_sectors. But that
> is not yet available.
>
Andre Hedrick
LAD Storage Consulting Group
I'm a wee bit reluctant to shrink these settings globally,
because it will have a small impact on people's ongoing
evaluation of 2.5 on high-end SCSI hardware.
Could you please set BIO_MAX_SECTORS to 64 within the IDE
patch, and add a BIG FAT COMMENT?
Andre Hedrick wrote:
>
> Andrew,
>
> I am just now getting back to crawling speeds in the 2.5 tree.
> I can only comment on what works and what Viro tells me.
> But if you think it needs to be globally set, until the updates from Jens
> arrive, please send to Linus. I am running my stuff by Viro and company.
>
> Cheers,
>
> On Thu, 29 Aug 2002, Andrew Morton wrote:
>
> > Andre Hedrick wrote:
> > >
> > > ...
> > > There is one more thing to fix.
> > >
> > > ./fs/mpage.c
> > >
> > > /*
> > > * The largest-sized BIO which this code will assemble, in bytes. Set this
> > > * to PAGE_CACHE_SIZE if your drivers are broken.
> > > */
> > > #define MPAGE_BIO_MAX_SIZE 32768 //BIO_MAX_SIZE
> > >
> > > This is confirmed with Al Viro and was required to make things sane!
> >
> > You'll need to do the same thing to fs/direct-io.c:DIO_BIO_MAX_SIZE
> > in that case.
> >
> > I'd suggest that you just go in and change BIO_MAX_SECTORS
> > to 64. Or 32 if you happen to be using a qlogic controller :(
> >
> > So everything's broken in there - a hardwired constant doesn't
> > cut it. Jens is cooking up an `add_page_to_bio()' API which
> > will do the right thing based upon q->max_sectors. But that
> > is not yet available.
> >
>
> Andre Hedrick
> LAD Storage Consulting Group