sa(4) 9.2->10.1, nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split request

[Harald Schmalzbauer]

 Bezüglich Kenneth D. Merry's Nachricht vom 25.10.2014 01:07 (localtime):
…
>> When btape(8) starts to read the label, the _subject's error is reported_:
>> *nsa0.0: request ptr 0x803135040 is not on a page boundary; cannot split
>> request*
> What blocksize are you using with btape(8)?
>
> What kind of controller are you using?

Hello and thanks a lot for your very avaluable explanations!

had no block size set in the bacula(-sd) configuration. Btape(8)
consults the same config file, so I thought it's probably bacula's
default of 64512, but if I correctly understood your explanation later,
it's more likely it's starting with kern.cam.sa.0.maxio, which doesn't
work because of the non-page-aligned address!?!

My LTO4 is connected via a mps(4), LSISAS2008.


> The reason you get that error message is that the sa(4) driver goes through
> physio(9) to get buffers from userland into the kernel.  physio(9) relies
> on the vmapbuf()/vunmapbuf() routines to map buffers in and out of the
> kernel.
>
> vmapbuf() operates with a page granularity.  The address to be mapped has
> to start on a page boundary.  It also uses kernel virtual address segments
> that are MAXPHYS in size.  On x86 boxes at least, MAXPHYS is 128KB.

So is it correct that kern.cam.sa.0.maxio = MAXPHYS?


> So if you use a blocksize of 128KB, but pass in a pointer that doesn't
> start on a page boundary, vmapbuf() will have to map 33 pages instead of
> 32.  In your case, it will have to start at page address 0x803135000, and
> will need 33 4KB pages, which is greater than 128KB.
>
> This behavior obviously isn't very user friendly. 
>
> If you want to avoid the problem, try setting your blocksize in Bacula to
> 4K less than what is reported in kern.cam.sa.0.maxio.  If it's 131072, then
> set the blocksize to 126976.
>
> Another way to avoid the problem is to increase MAXPHYS.  Increasing it
> beyond kern.cam.sa.0.cpi_maxio won't help anything.  If you increase
> it too much, you can run into other problems.
>
> That said, though, you can probably bump it to 512K without much worry.
> Put this in your kernel config file and recompile/reinstall your kernel:
>
> options         MAXPHYS="(512*1024)"
> options         DFLTPHYS="(512*1024)"
>
> The same thing applies, though -- you'll want to set your blocksize to 1
> page less than kern.cam.sa.0.maxio, since Bacula isn't using page-aligned
> buffers.

Ah, ok – “unaligned buffers”. I think I understood the reason for the
message.
That's enough for me for now; probably btape(8) attempts acessing the
tape with kern.cam.sa.0.maxio, not bacula's default of 64512.

What I haven't understood entirely is DFLTPHYS and the whole physio(9)
chain down to the magnetic tape :-(
But at least now I have an idea and your advise to increase DFLTPHYS, so
I did that and will do some tests.
I knew of that options before, but I didn't want to tune anything I
can't estimate it's impact…


Thanks a lot,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141025/861c962b/attachment.sig>