Re: 2.4.19pre3aa2

[Jari Ruusu <jari.ruusu@pp.inet.fi>]

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

Jens Axboe wrote:
> On Fri, Mar 15 2002, Jari Ruusu wrote:
> > If there is any chance of being merged to mainline kernel, I will fix these
> > "hurt the eyes" formatting issues.
> 
> I think there is. At least I can safely say there's no chance it will be
> merged if these things aren't fixed. So take your pick :-)

OK, I have fixed above mentioned formatting issues. A patch is attached.

And, about sleeping in loop_make_request(), I have also changed the code in
such way that it defaults to code that may sleep in loop_make_request(). But
non-sleeping code is still present (but not currently used), like this:

#if 1
    may-sleep-in-loop_make_request-code-here
#else
    non-sleeping-loop_make_request-code-here
#endif

> > > BTW, it looks like you are killing LO_FLAGS_BH_REMAP?! Why? This is a
> > > very worthwhile optimization.
> >
> > Removing it simplified the code a lot. Doing remap direcly from
> > loop_make_request() would probably be more effective. Just remap and return
> 
> LOTS more effective. Please don't kill this functionality. I don't buy
> the simplification argument.

This new patch does not remove LO_FLAGS_BH_REMAP optimization.

> > 1 from loop_make_request() like LVM code does.
> 
> And like loop currently does...

2.4.19-pre3 loop code wanders to loop_get_buffer() and transfer function in
LO_FLAGS_BH_REMAP optimization case.

My version is simpler than yours:

        if (lo->lo_flags & LO_FLAGS_BH_REMAP) {
                rbh->b_rsector += (lo->lo_offset >> 9);
                rbh->b_rdev = lo->lo_device;
                return 1;
        }               
        
Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

[-- Attachment #2: loop-fixes-2.4.19-pre3.diff.gz --]
[-- Type: application/x-gzip, Size: 7170 bytes --]