Reiser4 SCSI Bug?

Reiser4 SCSI Bug?

[Steve Olivieri]

Greetings!

I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running in
a PCI slot).  I have partitioned it and installed a temporary Gentoo
system with the reiserfs filesytem.  My boot partition uses ext2.  These
partitions seem perfectly stable.  I have booted this temporary system
multiple times and I have attempted to use it to install a permanent
system with the reiser4 filesystem.

After making the fileystems on each partition and mounting them, I was
able to download two tarballs (the stage and portage snapshot).  While
extracting the first, the terminal seems to hang.

I switched to another terminal to see what was wrong.  Everything works
great until I try to do anything at all on a reiser4 partition.  Then,
this terminal also hangs.  Repeat until I'm out of terminals.

I've been able to repeat this problem a number of times.  The only
messages in my log file claimed that a flush failed (with code -12, if I
remember correctly).  I do not have access to the logs at this time but I
will try to get them soon.

I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4 patchset.
 Patitions were made using the 1.0.5 reiser4progs/libaal.  In the past, I
have also replicated this problem using a 2.6.12-gentoo kernel with the
2.6.12 patchset and 1.0.5 reiser4progs/libaal.

Is there something that I can do to fix this problem?  Is it a known bug?

Also, I am not on the mailing list and I would appreciate it if I could be
cc'd with any information about this problem.

Thanks,
Steve

Re: Reiser4 SCSI Bug?

[Isaac Chanin]

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

Steve Olivieri wrote:
> Greetings!
>
> I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
> LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running in
> a PCI slot).  I have partitioned it and installed a temporary Gentoo
> system with the reiserfs filesytem.  My boot partition uses ext2.  These
> partitions seem perfectly stable.  I have booted this temporary system
> multiple times and I have attempted to use it to install a permanent
> system with the reiser4 filesystem.
>
> After making the fileystems on each partition and mounting them, I was
> able to download two tarballs (the stage and portage snapshot).  While
> extracting the first, the terminal seems to hang.
>
> I switched to another terminal to see what was wrong.  Everything works
> great until I try to do anything at all on a reiser4 partition.  Then,
> this terminal also hangs.  Repeat until I'm out of terminals.
>
> I've been able to repeat this problem a number of times.  The only
> messages in my log file claimed that a flush failed (with code -12, if I
> remember correctly).  I do not have access to the logs at this time but I
> will try to get them soon.
>
> I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4 patchset.
>  Patitions were made using the 1.0.5 reiser4progs/libaal.  In the past, I
> have also replicated this problem using a 2.6.12-gentoo kernel with the
> 2.6.12 patchset and 1.0.5 reiser4progs/libaal.
>
> Is there something that I can do to fix this problem?  Is it a known bug?
>
> Also, I am not on the mailing list and I would appreciate it if I could be
> cc'd with any information about this problem.
>
> Thanks,
> Steve
>
>
>
>

Hey Steve,

The problem appears to be in the fs/reiser4/wander.c file.  In short,
nr_blocks passed to bio_alloc ends up being too big; in my testing 1024,
whereas the maximum the called functions will properly deal with is 256.

The attached patch adds a hacky fix for this problem, but perhaps someone
who knows the code better should go through and take a look why max_blocks
and nr in write_jnodes_to_disk_extent in wander.c do not always have a
shared minimum of no greater than 256.

Hope this helps,
Isaac

[-- Attachment #2: /usr/src/thefix.patch --]
[-- Type: text/plain, Size: 332 bytes --]

--- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c	2005-10-28 19:27:02.301541280 -0400
+++ linux/fs/reiser4/wander.c	2005-10-28 19:29:37.000000000 -0400
@@ -1241,7 +1241,7 @@
 
 	while (nr > 0) {
 		struct bio *bio;
-		int nr_blocks = min(nr, max_blocks);
+		int nr_blocks = min(min(nr, max_blocks), 256);
 		int i;
 		int nr_used;
 

Re: Reiser4 SCSI Bug?

[Hans Reiser]

Thanks Isaac!

Does IDE have a different maximum?  Is there a non-hack way to discover
the maximum of the device driver underneath?

Hans

Isaac Chanin wrote:

>Steve Olivieri wrote:
>  
>
>>Greetings!
>>
>>I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
>>LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running in
>>a PCI slot).  I have partitioned it and installed a temporary Gentoo
>>system with the reiserfs filesytem.  My boot partition uses ext2.  These
>>partitions seem perfectly stable.  I have booted this temporary system
>>multiple times and I have attempted to use it to install a permanent
>>system with the reiser4 filesystem.
>>
>>After making the fileystems on each partition and mounting them, I was
>>able to download two tarballs (the stage and portage snapshot).  While
>>extracting the first, the terminal seems to hang.
>>
>>I switched to another terminal to see what was wrong.  Everything works
>>great until I try to do anything at all on a reiser4 partition.  Then,
>>this terminal also hangs.  Repeat until I'm out of terminals.
>>
>>I've been able to repeat this problem a number of times.  The only
>>messages in my log file claimed that a flush failed (with code -12, if I
>>remember correctly).  I do not have access to the logs at this time but I
>>will try to get them soon.
>>
>>I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4 patchset.
>> Patitions were made using the 1.0.5 reiser4progs/libaal.  In the past, I
>>have also replicated this problem using a 2.6.12-gentoo kernel with the
>>2.6.12 patchset and 1.0.5 reiser4progs/libaal.
>>
>>Is there something that I can do to fix this problem?  Is it a known bug?
>>
>>Also, I am not on the mailing list and I would appreciate it if I could be
>>cc'd with any information about this problem.
>>
>>Thanks,
>>Steve
>>
>>
>>
>>
>>    
>>
>
>Hey Steve,
>
>The problem appears to be in the fs/reiser4/wander.c file.  In short,
>nr_blocks passed to bio_alloc ends up being too big; in my testing 1024,
>whereas the maximum the called functions will properly deal with is 256.
>
>The attached patch adds a hacky fix for this problem, but perhaps someone
>who knows the code better should go through and take a look why max_blocks
>and nr in write_jnodes_to_disk_extent in wander.c do not always have a
>shared minimum of no greater than 256.
>
>Hope this helps,
>Isaac
>  
>
>------------------------------------------------------------------------
>
>--- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c	2005-10-28 19:27:02.301541280 -0400
>+++ linux/fs/reiser4/wander.c	2005-10-28 19:29:37.000000000 -0400
>@@ -1241,7 +1241,7 @@
> 
> 	while (nr > 0) {
> 		struct bio *bio;
>-		int nr_blocks = min(nr, max_blocks);
>+		int nr_blocks = min(min(nr, max_blocks), 256);
> 		int i;
> 		int nr_used;
> 
>

Re: Reiser4 SCSI Bug?

[Isaac Chanin]

Hi Hans,

I don't think it's a device driver problem.  My fix derived simply from 
noticing that the function where the problem originates is bvec_alloc_bs 
in fs/bio.c.

To trace, the problem goes something like:
(fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs

In any case, BIO_MAX_PAGES is defined to be 256 in include/linux/bio.h, 
thus bvec_alloc_bs returns null, likewise bio_alloc_bioset does the 
same, as does bio_alloc.  And thus the error in wander.c.

Looking at the problem from the other direction, the max_blocks check 
that was already in wander.c looks like:

max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >> 
(super->s_blocksize_bits - 9);

I'd look into the construction of the super block around 
s_blocksize_bits, or however max_sectors is derived, to see if there're 
any problems there (I suppose a device driver very well could be giving 
a bad value that gets used somewhere in that code), but I really don't 
know the reiser4 code well enough to do so.  In any case, as a temporary 
(or perhaps permanent, as it seems that the limit is hardcoded in the 
kernel anyways) solution it would probably be better to put the min(256, 
...) check around where max_blocks is set rather than around nr_blocks 
inside the while loop.


Isaac


Hans Reiser wrote:
> Thanks Isaac!
> 
> Does IDE have a different maximum?  Is there a non-hack way to discover
> the maximum of the device driver underneath?
> 
> Hans
> 
> Isaac Chanin wrote:
> 
> 
>>Steve Olivieri wrote:
>> 
>>
>>
>>>Greetings!
>>>
>>>I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
>>>LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running in
>>>a PCI slot).  I have partitioned it and installed a temporary Gentoo
>>>system with the reiserfs filesytem.  My boot partition uses ext2.  These
>>>partitions seem perfectly stable.  I have booted this temporary system
>>>multiple times and I have attempted to use it to install a permanent
>>>system with the reiser4 filesystem.
>>>
>>>After making the fileystems on each partition and mounting them, I was
>>>able to download two tarballs (the stage and portage snapshot).  While
>>>extracting the first, the terminal seems to hang.
>>>
>>>I switched to another terminal to see what was wrong.  Everything works
>>>great until I try to do anything at all on a reiser4 partition.  Then,
>>>this terminal also hangs.  Repeat until I'm out of terminals.
>>>
>>>I've been able to repeat this problem a number of times.  The only
>>>messages in my log file claimed that a flush failed (with code -12, if I
>>>remember correctly).  I do not have access to the logs at this time but I
>>>will try to get them soon.
>>>
>>>I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4 patchset.
>>>Patitions were made using the 1.0.5 reiser4progs/libaal.  In the past, I
>>>have also replicated this problem using a 2.6.12-gentoo kernel with the
>>>2.6.12 patchset and 1.0.5 reiser4progs/libaal.
>>>
>>>Is there something that I can do to fix this problem?  Is it a known bug?
>>>
>>>Also, I am not on the mailing list and I would appreciate it if I could be
>>>cc'd with any information about this problem.
>>>
>>>Thanks,
>>>Steve
>>>
>>>
>>>
>>>
>>>   
>>>
>>
>>Hey Steve,
>>
>>The problem appears to be in the fs/reiser4/wander.c file.  In short,
>>nr_blocks passed to bio_alloc ends up being too big; in my testing 1024,
>>whereas the maximum the called functions will properly deal with is 256.
>>
>>The attached patch adds a hacky fix for this problem, but perhaps someone
>>who knows the code better should go through and take a look why max_blocks
>>and nr in write_jnodes_to_disk_extent in wander.c do not always have a
>>shared minimum of no greater than 256.
>>
>>Hope this helps,
>>Isaac
>> 
>>
>>------------------------------------------------------------------------
>>
>>--- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c	2005-10-28 19:27:02.301541280 -0400
>>+++ linux/fs/reiser4/wander.c	2005-10-28 19:29:37.000000000 -0400
>>@@ -1241,7 +1241,7 @@
>>
>>	while (nr > 0) {
>>		struct bio *bio;
>>-		int nr_blocks = min(nr, max_blocks);
>>+		int nr_blocks = min(min(nr, max_blocks), 256);
>>		int i;
>>		int nr_used;
>>
>>
> 
> 
> 

Re: Reiser4 SCSI Bug?

[Hans Reiser]

Isaac Chanin wrote:

> Hi Hans,
>
> I don't think it's a device driver problem.  My fix derived simply
> from noticing that the function where the problem originates is
> bvec_alloc_bs in fs/bio.c.
>
> To trace, the problem goes something like:
> (fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
> bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs
>
> In any case, BIO_MAX_PAGES is defined to be 256 in
> include/linux/bio.h, thus bvec_alloc_bs returns null, likewise
> bio_alloc_bioset does the same, as does bio_alloc.  And thus the error
> in wander.c.
>
> Looking at the problem from the other direction, the max_blocks check
> that was already in wander.c looks like:
>
> max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >>
> (super->s_blocksize_bits - 9);
>
> I'd look into the construction of the super block around
> s_blocksize_bits, or however max_sectors is derived, to see if
> there're any problems there (I suppose a device driver very well could
> be giving a bad value that gets used somewhere in that code), but I
> really don't know the reiser4 code well enough to do so.  In any case,
> as a temporary (or perhaps permanent, as it seems that the limit is
> hardcoded in the kernel anyways) solution it would probably be better
> to put the min(256, ...) 

It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in two
places is bad, yes?

> check around where max_blocks is set rather than around nr_blocks
> inside the while loop.
>
>
> Isaac
>
>
> Hans Reiser wrote:
>
>> Thanks Isaac!
>>
>> Does IDE have a different maximum?  Is there a non-hack way to discover
>> the maximum of the device driver underneath?
>>
>> Hans
>>
>> Isaac Chanin wrote:
>>
>>
>>> Steve Olivieri wrote:
>>>
>>>
>>>
>>>> Greetings!
>>>>
>>>> I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
>>>> LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's
>>>> running in
>>>> a PCI slot).  I have partitioned it and installed a temporary Gentoo
>>>> system with the reiserfs filesytem.  My boot partition uses ext2. 
>>>> These
>>>> partitions seem perfectly stable.  I have booted this temporary system
>>>> multiple times and I have attempted to use it to install a permanent
>>>> system with the reiser4 filesystem.
>>>>
>>>> After making the fileystems on each partition and mounting them, I was
>>>> able to download two tarballs (the stage and portage snapshot).  While
>>>> extracting the first, the terminal seems to hang.
>>>>
>>>> I switched to another terminal to see what was wrong.  Everything
>>>> works
>>>> great until I try to do anything at all on a reiser4 partition.  Then,
>>>> this terminal also hangs.  Repeat until I'm out of terminals.
>>>>
>>>> I've been able to repeat this problem a number of times.  The only
>>>> messages in my log file claimed that a flush failed (with code -12,
>>>> if I
>>>> remember correctly).  I do not have access to the logs at this time
>>>> but I
>>>> will try to get them soon.
>>>>
>>>> I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4
>>>> patchset.
>>>> Patitions were made using the 1.0.5 reiser4progs/libaal.  In the
>>>> past, I
>>>> have also replicated this problem using a 2.6.12-gentoo kernel with
>>>> the
>>>> 2.6.12 patchset and 1.0.5 reiser4progs/libaal.
>>>>
>>>> Is there something that I can do to fix this problem?  Is it a
>>>> known bug?
>>>>
>>>> Also, I am not on the mailing list and I would appreciate it if I
>>>> could be
>>>> cc'd with any information about this problem.
>>>>
>>>> Thanks,
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>
>>>
>>> Hey Steve,
>>>
>>> The problem appears to be in the fs/reiser4/wander.c file.  In short,
>>> nr_blocks passed to bio_alloc ends up being too big; in my testing
>>> 1024,
>>> whereas the maximum the called functions will properly deal with is
>>> 256.
>>>
>>> The attached patch adds a hacky fix for this problem, but perhaps
>>> someone
>>> who knows the code better should go through and take a look why
>>> max_blocks
>>> and nr in write_jnodes_to_disk_extent in wander.c do not always have a
>>> shared minimum of no greater than 256.
>>>
>>> Hope this helps,
>>> Isaac
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> --- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c    2005-10-28
>>> 19:27:02.301541280 -0400
>>> +++ linux/fs/reiser4/wander.c    2005-10-28 19:29:37.000000000 -0400
>>> @@ -1241,7 +1241,7 @@
>>>
>>>     while (nr > 0) {
>>>         struct bio *bio;
>>> -        int nr_blocks = min(nr, max_blocks);
>>> +        int nr_blocks = min(min(nr, max_blocks), 256);
>>>         int i;
>>>         int nr_used;
>>>
>>>
>>
>>
>>
>
>

Re: Reiser4 SCSI Bug?

[Isaac Chanin]

Hans Reiser wrote:
> 
> It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in two
> places is bad, yes?
> 
>

Yeah, I think the code is running into two different limits here. 
Reiser4 wants it to be nr, but limits it to BIO_MAX_PAGES.  However, 
apparently, the BIO_MAX_PAGES limit does not take into consideration the 
underlying 256 limit imposed by bio_alloc.

I'm not quite sure if having the two different limits is a bad thing in 
this case, unless BIO_MAX_PAGES can be made to (or is supposed to, and 
there's a bug) take into account the 256 limit.

I suppose the other solution is to not use bio_alloc et al due to the 
256 limit, and find another method that allows values as large as 
BIO_MAX_PAGES, under the current implementation, will grow to.

Re: Reiser4 SCSI Bug?

[Isaac Chanin]

Hans Reiser wrote:
> Isaac Chanin wrote:
> 
> 
>>Hans Reiser wrote:
>>
>>
>>>It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in two
>>>places is bad, yes?
>>>
>>>
>>
>>Yeah, I think the code is running into two different limits here.
>>Reiser4 wants it to be nr, but limits it to BIO_MAX_PAGES.  However,
>>apparently, the BIO_MAX_PAGES limit does not take into consideration
>>the underlying 256 limit imposed by bio_alloc.
>>
>>I'm not quite sure if having the two different limits is a bad thing
>>in this case, unless BIO_MAX_PAGES can be made to (or is supposed to,
>>and there's a bug) take into account the 256 limit.
>>
>>I suppose the other solution is to not use bio_alloc et al due to the
>>256 limit, and find another method that allows values as large as
>>BIO_MAX_PAGES, under the current implementation, will grow to.
>>
>>
> 
> but you said:
> 
> "In any case, BIO_MAX_PAGES is defined to be 256"
> 
> Now I am confused.
> 
> We should use the same macro defining our limit as the underlying layer uses.  What macro is that called?
> 
> 

Right, it would be far better to do min(BIO_MAX_PAGES, ...); rather than 
using 256 directly.  It's defined in include/linux/bio.h which is 
already included in wander.c.

Re: Reiser4 SCSI Bug?

[Hans Reiser]

Isaac Chanin wrote:

> Hans Reiser wrote:
>
>>
>> It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in two
>> places is bad, yes?
>>
>>
>
> Yeah, I think the code is running into two different limits here.
> Reiser4 wants it to be nr, but limits it to BIO_MAX_PAGES.  However,
> apparently, the BIO_MAX_PAGES limit does not take into consideration
> the underlying 256 limit imposed by bio_alloc.
>
> I'm not quite sure if having the two different limits is a bad thing
> in this case, unless BIO_MAX_PAGES can be made to (or is supposed to,
> and there's a bug) take into account the 256 limit.
>
> I suppose the other solution is to not use bio_alloc et al due to the
> 256 limit, and find another method that allows values as large as
> BIO_MAX_PAGES, under the current implementation, will grow to.
>
>
but you said:

"In any case, BIO_MAX_PAGES is defined to be 256"

Now I am confused.

We should use the same macro defining our limit as the underlying layer uses.  What macro is that called?

Re: Reiser4 SCSI Bug?

[Hans Reiser]

Isaac Chanin wrote:

> Hans Reiser wrote:
>
>> Isaac Chanin wrote:
>>
>>
>>> Hans Reiser wrote:
>>>
>>>
>>>> It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in two
>>>> places is bad, yes?
>>>>
>>>>
>>>
>>> Yeah, I think the code is running into two different limits here.
>>> Reiser4 wants it to be nr, but limits it to BIO_MAX_PAGES.  However,
>>> apparently, the BIO_MAX_PAGES limit does not take into consideration
>>> the underlying 256 limit imposed by bio_alloc.
>>>
>>> I'm not quite sure if having the two different limits is a bad thing
>>> in this case, unless BIO_MAX_PAGES can be made to (or is supposed to,
>>> and there's a bug) take into account the 256 limit.
>>>
>>> I suppose the other solution is to not use bio_alloc et al due to the
>>> 256 limit, and find another method that allows values as large as
>>> BIO_MAX_PAGES, under the current implementation, will grow to.
>>>
>>>
>>
>> but you said:
>>
>> "In any case, BIO_MAX_PAGES is defined to be 256"
>>
>> Now I am confused.
>>
>> We should use the same macro defining our limit as the underlying
>> layer uses.  What macro is that called?
>>
>>
>
> Right, it would be far better to do min(BIO_MAX_PAGES, ...); rather
> than using 256 directly.  It's defined in include/linux/bio.h which is
> already included in wander.c.
>
>
ok, well, vs, please fix this and put the fix into our next release to
andrew if you can.

Re: Reiser4 SCSI Bug?

[Michael James]

On Sat, 29 Oct 2005 03:49 am, Steve Olivieri wrote:
> Greetings!
> 
> I have a Maxtor Atlas II 15k, 147GB SCSI hard disk
> and an LSI Logic LSI21320 Ultra320 SCSI Host Bus Adapter
> for PCI-X (though it's running in a PCI slot).
> I have partitioned it and installed a temporary Gentoo 
> system with the reiserfs filesytem.
> My boot partition uses ext2.
> These partitions seem perfectly stable.
> I have booted this temporary system multiple times
> and I have attempted to use it to install a permanent 
> system with the reiser4 filesystem.
> 
> After making the fileystems on each partition and mounting them, I was
> able to download two tarballs (the stage and portage snapshot).  While
> extracting the first, the terminal seems to hang.
> 
> I switched to another terminal to see what was wrong.
> Everything works great until I try to do anything at all
> on a reiser4 partition.  Then, this terminal also hangs.
> Repeat until I'm out of terminals. 

There seems to be a complete incompatibility
 between reiser4 and LSI fusion drivers.

I tried to get a reiser4 data partition on Dell Blade servers
 (PE1655MC) with the same results you had.
(Search the archives for "Suse9.3")
Lots of people reporting, "It works fine."
 and my reiser4 wouldn't accept data.
The suggestion then was, "Try a different disk controller."
But the blades don't even have the possibility,
 so I went back to reiserfs 3.6.

I haven't heard any news to suggest it's worth trying again yet.

michaelj

-- 
Michael James                         michael.james@csiro.au
System Administrator                    voice:  02 6246 5040
CSIRO Bioinformatics Facility             fax:  02 6246 5166

No matter how much you pay for software,
 you always get less than you hoped.
Unless you pay nothing, then you get more.

Re: Reiser4 SCSI Bug?

[Steve Olivieri]

Hey guys,

I had a system running on reiser4 with Isaac's patch yesterday and all we
going well.  Of course, then I deleted /var/db and portage went crazy and
I decided to build the system again.

I attempted to do so today, using the same kernel as yesterday, but now
I'm getting the same error as before.  To be a bit more specific,

reiser4[pdflush(218)]: writeout (fs/reiser4/vfs_ops.c:197)[nikita-31001):
code: -12 at fs/reiser4/wander.c:1250
WARNING: Flush failed: -12

I used to get a number of these errors (in fact, they continued until I
would reboot with SysRq keys) but now I only seem to get one before
everything hangs and I'm forced to reboot.

Hope to see a good fix soon,

 Steve

> Isaac Chanin wrote:
>
>> Hans Reiser wrote:
>>
>>> Isaac Chanin wrote:
>>>
>>>
>>>> Hans Reiser wrote:
>>>>
>>>>
>>>>> It should be not 256, but BIO_MAX_PAGES, yes?   Defining limits in
>>>>> two
>>>>> places is bad, yes?
>>>>>
>>>>>
>>>>
>>>> Yeah, I think the code is running into two different limits here.
>>>> Reiser4 wants it to be nr, but limits it to BIO_MAX_PAGES.  However,
>>>> apparently, the BIO_MAX_PAGES limit does not take into consideration
>>>> the underlying 256 limit imposed by bio_alloc.
>>>>
>>>> I'm not quite sure if having the two different limits is a bad thing
>>>> in this case, unless BIO_MAX_PAGES can be made to (or is supposed to,
>>>> and there's a bug) take into account the 256 limit.
>>>>
>>>> I suppose the other solution is to not use bio_alloc et al due to the
>>>> 256 limit, and find another method that allows values as large as
>>>> BIO_MAX_PAGES, under the current implementation, will grow to.
>>>>
>>>>
>>>
>>> but you said:
>>>
>>> "In any case, BIO_MAX_PAGES is defined to be 256"
>>>
>>> Now I am confused.
>>>
>>> We should use the same macro defining our limit as the underlying
>>> layer uses.  What macro is that called?
>>>
>>>
>>
>> Right, it would be far better to do min(BIO_MAX_PAGES, ...); rather
>> than using 256 directly.  It's defined in include/linux/bio.h which is
>> already included in wander.c.
>>
>>
> ok, well, vs, please fix this and put the fix into our next release to
> andrew if you can.
>

Re: Reiser4 SCSI Bug?

[Isaac Chanin]

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

Steve Olivieri wrote:
> Hey guys,
> 
> I had a system running on reiser4 with Isaac's patch yesterday and all we
> going well.  Of course, then I deleted /var/db and portage went crazy and
> I decided to build the system again.
> 
> I attempted to do so today, using the same kernel as yesterday, but now
> I'm getting the same error as before.  To be a bit more specific,
> 
> reiser4[pdflush(218)]: writeout (fs/reiser4/vfs_ops.c:197)[nikita-31001):
> code: -12 at fs/reiser4/wander.c:1250
> WARNING: Flush failed: -12
> 
> I used to get a number of these errors (in fact, they continued until I
> would reboot with SysRq keys) but now I only seem to get one before
> everything hangs and I'm forced to reboot.
> 
> Hope to see a good fix soon,
> 
>  Steve
> 
> 


Hey Steve,

Not sure why that error would crop up again.  In any case, the attached 
patch uses the macro, moves the min check out of the loop, and fixes all 
of the occurances - so, it may be worth giving a try.

Isaac

[-- Attachment #2: biofix.patch --]
[-- Type: text/plain, Size: 856 bytes --]

--- linux-2.6.13-ck5/fs/reiser4/wander.c.old	2005-10-30 22:38:00.771463160 -0500
+++ linux-2.6.13-ck5/fs/reiser4/wander.c	2005-10-30 22:37:47.952411952 -0500
@@ -763,9 +763,10 @@
 		 nr, (unsigned long long)block);
 
 	max_blocks =
-	    bdev_get_queue(super->s_bdev)->max_sectors >> (super->
-							   s_blocksize_bits -
-							   9);
+	    min(BIO_MAX_PAGES,
+		bdev_get_queue(super->s_bdev)->max_sectors >> (super->
+							      s_blocksize_bits -
+							      9));
 
 	while (nr > 0) {
 		struct bio *bio;
@@ -1235,9 +1236,10 @@
 
 	block = *block_p;
 	max_blocks =
-	    bdev_get_queue(super->s_bdev)->max_sectors >> (super->
-							   s_blocksize_bits -
-							   9);
+	    min(BIO_MAX_PAGES,
+		bdev_get_queue(super->s_bdev)->max_sectors >> (super->
+							      s_blocksize_bits -
+							      9));
 
 	while (nr > 0) {
 		struct bio *bio;

Re: Reiser4 SCSI Bug?

[Alexander Zarochentsev]

Hi,

On Sunday 30 October 2005 02:13, Isaac Chanin wrote:
> Hi Hans,
>
> I don't think it's a device driver problem.  My fix derived simply from
> noticing that the function where the problem originates is bvec_alloc_bs
> in fs/bio.c.
>
> To trace, the problem goes something like:
> (fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
> bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs
>
> In any case, BIO_MAX_PAGES is defined to be 256 in include/linux/bio.h,
> thus bvec_alloc_bs returns null, likewise bio_alloc_bioset does the
> same, as does bio_alloc.  And thus the error in wander.c.
>
> Looking at the problem from the other direction, the max_blocks check
> that was already in wander.c looks like:
>
> max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >>
> (super->s_blocksize_bits - 9);
>
> I'd look into the construction of the super block around
> s_blocksize_bits, or however max_sectors is derived, to see if there're
> any problems there (I suppose a device driver very well could be giving
> a bad value that gets used somewhere in that code), but I really don't
> know the reiser4 code well enough to do so.  In any case, as a temporary
> (or perhaps permanent, as it seems that the limit is hardcoded in the
> kernel anyways) solution it would probably be better to put the min(256,
> ...) check around where max_blocks is set rather than around nr_blocks
> inside the while loop.

fs/mpage.c  uses bio.h:bio_get_nr_vecs() as below:
...
alloc_new:
	if (bio == NULL) {
		bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
			  	min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
				GFP_KERNEL);
		if (bio == NULL)
			goto confused;
	}
...

would you please check whether the following patch helps as your one does:

-----------------------------------------
diff --git a/wander.c b/wander.c
index 4038000..b606063 100644
--- a/wander.c
+++ b/wander.c
@@ -731,9 +731,7 @@ static int write_jnodes_to_disk_extent(
 	assert("zam-570", nr > 0);
 
 	block = *block_p;
-	max_blocks =
-		bdev_get_queue(super->s_bdev)->max_sectors >> 
-		(super-> s_blocksize_bits - 9);
+	max_blocks = bio_get_nr_vecs(super->s_bdev);
 
 	while (nr > 0) {
 		struct bio *bio;
======================

>
>
> Isaac
>
> Hans Reiser wrote:
> > Thanks Isaac!
> >
> > Does IDE have a different maximum?  Is there a non-hack way to discover
> > the maximum of the device driver underneath?
> >
> > Hans
> >
> > Isaac Chanin wrote:
> >>Steve Olivieri wrote:
> >>>Greetings!
> >>>
> >>>I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
> >>>LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running
> >>> in a PCI slot).  I have partitioned it and installed a temporary Gentoo
> >>> system with the reiserfs filesytem.  My boot partition uses ext2. 
> >>> These partitions seem perfectly stable.  I have booted this temporary
> >>> system multiple times and I have attempted to use it to install a
> >>> permanent system with the reiser4 filesystem.
> >>>
> >>>After making the fileystems on each partition and mounting them, I was
> >>>able to download two tarballs (the stage and portage snapshot).  While
> >>>extracting the first, the terminal seems to hang.
> >>>
> >>>I switched to another terminal to see what was wrong.  Everything works
> >>>great until I try to do anything at all on a reiser4 partition.  Then,
> >>>this terminal also hangs.  Repeat until I'm out of terminals.
> >>>
> >>>I've been able to repeat this problem a number of times.  The only
> >>>messages in my log file claimed that a flush failed (with code -12, if I
> >>>remember correctly).  I do not have access to the logs at this time but
> >>> I will try to get them soon.
> >>>
> >>>I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4
> >>> patchset. Patitions were made using the 1.0.5 reiser4progs/libaal.  In
> >>> the past, I have also replicated this problem using a 2.6.12-gentoo
> >>> kernel with the 2.6.12 patchset and 1.0.5 reiser4progs/libaal.
> >>>
> >>>Is there something that I can do to fix this problem?  Is it a known
> >>> bug?
> >>>
> >>>Also, I am not on the mailing list and I would appreciate it if I could
> >>> be cc'd with any information about this problem.
> >>>
> >>>Thanks,
> >>>Steve
> >>
> >>Hey Steve,
> >>
> >>The problem appears to be in the fs/reiser4/wander.c file.  In short,
> >>nr_blocks passed to bio_alloc ends up being too big; in my testing 1024,
> >>whereas the maximum the called functions will properly deal with is 256.
> >>
> >>The attached patch adds a hacky fix for this problem, but perhaps someone
> >>who knows the code better should go through and take a look why
> >> max_blocks and nr in write_jnodes_to_disk_extent in wander.c do not
> >> always have a shared minimum of no greater than 256.
> >>
> >>Hope this helps,
> >>Isaac
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>--- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c	2005-10-28
> >> 19:27:02.301541280 -0400 +++ linux/fs/reiser4/wander.c	2005-10-28
> >> 19:29:37.000000000 -0400 @@ -1241,7 +1241,7 @@
> >>
> >>	while (nr > 0) {
> >>		struct bio *bio;
> >>-		int nr_blocks = min(nr, max_blocks);
> >>+		int nr_blocks = min(min(nr, max_blocks), 256);
> >>		int i;
> >>		int nr_used;

-- 
Alex.

Re: Reiser4 SCSI Bug?

[Alexander Zarochentsev]

On Monday 31 October 2005 09:24, Alexander Zarochentsev wrote:
> Hi,
>
> On Sunday 30 October 2005 02:13, Isaac Chanin wrote:
> > Hi Hans,
> >
> > I don't think it's a device driver problem.  My fix derived simply from
> > noticing that the function where the problem originates is bvec_alloc_bs
> > in fs/bio.c.
> >
> > To trace, the problem goes something like:
> > (fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
> > bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs
> >
> > In any case, BIO_MAX_PAGES is defined to be 256 in include/linux/bio.h,
> > thus bvec_alloc_bs returns null, likewise bio_alloc_bioset does the
> > same, as does bio_alloc.  And thus the error in wander.c.
> >
> > Looking at the problem from the other direction, the max_blocks check
> > that was already in wander.c looks like:
> >
> > max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >>
> > (super->s_blocksize_bits - 9);
> >
> > I'd look into the construction of the super block around
> > s_blocksize_bits, or however max_sectors is derived, to see if there're
> > any problems there (I suppose a device driver very well could be giving
> > a bad value that gets used somewhere in that code), but I really don't
> > know the reiser4 code well enough to do so.  In any case, as a temporary
> > (or perhaps permanent, as it seems that the limit is hardcoded in the
> > kernel anyways) solution it would probably be better to put the min(256,
> > ...) check around where max_blocks is set rather than around nr_blocks
> > inside the while loop.
>
> fs/mpage.c  uses bio.h:bio_get_nr_vecs() as below:
> ...
> alloc_new:
> 	if (bio == NULL) {
> 		bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
> 			  	min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
> 				GFP_KERNEL);
> 		if (bio == NULL)
> 			goto confused;
> 	}
> ...
>
> would you please check whether the following patch helps as your one does:
>
> -----------------------------------------
> diff --git a/wander.c b/wander.c
> index 4038000..b606063 100644
> --- a/wander.c
> +++ b/wander.c
> @@ -731,9 +731,7 @@ static int write_jnodes_to_disk_extent(
>  	assert("zam-570", nr > 0);
>
>  	block = *block_p;
> -	max_blocks =
> -		bdev_get_queue(super->s_bdev)->max_sectors >>
> -		(super-> s_blocksize_bits - 9);
> +	max_blocks = bio_get_nr_vecs(super->s_bdev);
>
>  	while (nr > 0) {
>  		struct bio *bio;
> ======================

I understood, mpage_writepages() has no such a problem because it 
submits not more than PAGEVEC_SIZE pages by one BIO.  It does not need to 
limit bio size by BIO_MAX_PAGES but reiser4 does.

Thanks a lot, Isaac.

I agree with Hans that we should use a constant from the public bio interface 
rather than a number.

-------------------------------------------
--- a/wander.c
+++ b/wander.c
@@ -731,9 +731,7 @@ static int write_jnodes_to_disk_extent(
        assert("zam-570", nr > 0);

        block = *block_p;
-       max_blocks =
-               bdev_get_queue(super->s_bdev)->max_sectors >>
-               (super-> s_blocksize_bits - 9);
+       max_blocks = min(bio_get_nr_vecs(super->s_bdev), BIO_MAX_PAGES);

        while (nr > 0) {
                struct bio *bio;

=======================

-- 
Alex.

Re: Reiser4 SCSI Bug?

[Hans Reiser]

Alexander Zarochentsev wrote:

>On Monday 31 October 2005 09:24, Alexander Zarochentsev wrote:
>  
>
>>Hi,
>>
>>On Sunday 30 October 2005 02:13, Isaac Chanin wrote:
>>    
>>
>>>Hi Hans,
>>>
>>>I don't think it's a device driver problem.  My fix derived simply from
>>>noticing that the function where the problem originates is bvec_alloc_bs
>>>in fs/bio.c.
>>>
>>>To trace, the problem goes something like:
>>>(fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
>>>bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs
>>>
>>>In any case, BIO_MAX_PAGES is defined to be 256 in include/linux/bio.h,
>>>thus bvec_alloc_bs returns null, likewise bio_alloc_bioset does the
>>>same, as does bio_alloc.  And thus the error in wander.c.
>>>
>>>Looking at the problem from the other direction, the max_blocks check
>>>that was already in wander.c looks like:
>>>
>>>max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >>
>>>(super->s_blocksize_bits - 9);
>>>
>>>I'd look into the construction of the super block around
>>>s_blocksize_bits, or however max_sectors is derived, to see if there're
>>>any problems there (I suppose a device driver very well could be giving
>>>a bad value that gets used somewhere in that code), but I really don't
>>>know the reiser4 code well enough to do so.  In any case, as a temporary
>>>(or perhaps permanent, as it seems that the limit is hardcoded in the
>>>kernel anyways) solution it would probably be better to put the min(256,
>>>...) check around where max_blocks is set rather than around nr_blocks
>>>inside the while loop.
>>>      
>>>
>>fs/mpage.c  uses bio.h:bio_get_nr_vecs() as below:
>>...
>>alloc_new:
>>	if (bio == NULL) {
>>		bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
>>			  	min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
>>				GFP_KERNEL);
>>		if (bio == NULL)
>>			goto confused;
>>	}
>>...
>>
>>would you please check whether the following patch helps as your one does:
>>
>>-----------------------------------------
>>diff --git a/wander.c b/wander.c
>>index 4038000..b606063 100644
>>--- a/wander.c
>>+++ b/wander.c
>>@@ -731,9 +731,7 @@ static int write_jnodes_to_disk_extent(
>> 	assert("zam-570", nr > 0);
>>
>> 	block = *block_p;
>>-	max_blocks =
>>-		bdev_get_queue(super->s_bdev)->max_sectors >>
>>-		(super-> s_blocksize_bits - 9);
>>+	max_blocks = bio_get_nr_vecs(super->s_bdev);
>>
>> 	while (nr > 0) {
>> 		struct bio *bio;
>>======================
>>    
>>
>
>I understood, mpage_writepages() has no such a problem because it 
>submits not more than PAGEVEC_SIZE pages by one BIO.  It does not need to 
>limit bio size by BIO_MAX_PAGES but reiser4 does.
>
>Thanks a lot, Isaac.
>
>I agree with Hans that we should use a constant from the public bio interface 
>rather than a number.
>
>-------------------------------------------
>--- a/wander.c
>+++ b/wander.c
>@@ -731,9 +731,7 @@ static int write_jnodes_to_disk_extent(
>        assert("zam-570", nr > 0);
>
>        block = *block_p;
>-       max_blocks =
>-               bdev_get_queue(super->s_bdev)->max_sectors >>
>-               (super-> s_blocksize_bits - 9);
>+       max_blocks = min(bio_get_nr_vecs(super->s_bdev), BIO_MAX_PAGES);
>
>        while (nr > 0) {
>                struct bio *bio;
>
>=======================
>
>  
>
Please put a thank you to Isaac in the source, and put some solution of
your choice in the patch collection for us to send to akpm.

Re: Reiser4 SCSI Bug?

[Steve Olivieri]

> Steve Olivieri wrote:
>> Hey guys,
>>
>> I had a system running on reiser4 with Isaac's patch yesterday and all
>> we
>> going well.  Of course, then I deleted /var/db and portage went crazy
>> and
>> I decided to build the system again.
>>
>> I attempted to do so today, using the same kernel as yesterday, but now
>> I'm getting the same error as before.  To be a bit more specific,
>>
>> reiser4[pdflush(218)]: writeout
>> (fs/reiser4/vfs_ops.c:197)[nikita-31001):
>> code: -12 at fs/reiser4/wander.c:1250
>> WARNING: Flush failed: -12
>>
>> I used to get a number of these errors (in fact, they continued until I
>> would reboot with SysRq keys) but now I only seem to get one before
>> everything hangs and I'm forced to reboot.
>>
>> Hope to see a good fix soon,
>>
>>  Steve
>>
>>
>
>
> Hey Steve,
>
> Not sure why that error would crop up again.  In any case, the attached
> patch uses the macro, moves the min check out of the loop, and fixes all
> of the occurances - so, it may be worth giving a try.
>
> Isaac
>

Hallo!

Isaac, that patch works much better.  My system seems to be as stable as
ever with reiser4.  I'll test the new patch that was sent to me later today
and get back to you guys with some results.

Thanks again for the fix.
Steve