Am Dienstag, den 30.11.2010, 21:53 +0200 schrieb Kai Makisara: > On Tue, 30 Nov 2010, Boaz Harrosh wrote: > > ... > > I looked at enlarge_buffer() and it looks fragile and broken. If you really > > need a pointer eg: > > STbuffer->b_data = page_address(STbuffer->reserved_pages[0]); > > > If you think it is broken, please fix it. > > > Than way not use vmalloc() for buffers larger then PAGE_SIZE? But better yet > > avoid it by keeping a pages_array or sg-list and operate on an aio type > > operations. > > > vmalloc() is not a solution here. Think about this from the HBA side. Each > s/g segment must be contiguous in the address space the HBA uses. In many > cases this is the physical memory address space. Any solution must make > sure that the HBA can perform the requested data transfer. > > > > Kai > > > > But I understand this is a lot of work on an old driver. Perhaps pre-allocate > > something big at startup. specified by user? > > > This used to be possible at some time and it could be made possible again. > But I don't like this option because it means that the users must > explicitly set the boot parameters. > > And it is difficult for me to believe the modern SAS HBAs only support 128 > s/g segments. I'll go ahead and file a bug about this. Maybe this gets it more attention? At the moment, linux 2.6.32-36 is pretty much useless for tape-based backups for us. What's interesting is that when this happens, one of the two tape drives seems to work, where for the second one the system can't allocate large enough buffers. > Kai -- Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
