Christoph Litauer wrote: > Christoph Litauer schrieb: > >> Josh Fisher schrieb: >> >>> This can happen when ClearPageReserved() is not called for a reserved >>> kernel memory page. Could be an iSCSI driver (included with the Linux >>> kernel) problem or, if you are using a hardware iSCSI adapter, it could >>> be a problem with its driver. >>> >>> >>>> My question is: What is the difference between the tape write actions of >>>> tar and btape? Maybe I will be able to configure the tape device so that >>>> btape doesn't run in kernel panics any more? >>>> >>>> >>> Well, btape is very likely using a different block size than you used >>> with tar. The default block size for btape is 126x512 = 64,512 bytes. >>> The default for tar is 20x512 = 10,240 bytes. Try setting 'Maximum block >>> size = 10240' and 'Minimum block size = 10240' in the bacula-sd.conf >>> config file being used by btape. If that works, then try tar with '-b >>> 64512' and see if tar causes the same problem with large block sizes. If >>> neither wroks with the larger block size, then you will have to use the >>> smaller block size until the iSCSI bug is fixed. >>> >>> >> Thanks Josh, I think the blocksizes are a step in the right direction - >> but no solution yet. In the meantime I changed the iSCSI-Switch and did >> a few more tests: >> >> - tar xv -f /dev/nst0 -b 126 /var => no Problems >> (I think -b 126 is right because - according to the manpage - tar >> multiplies option -b with 512, 126x512 = 64512) >> >> - btape HP-LTO2, rawfill (maximum block size set to 10240) => panic >> Output was: >> *rawfill >> btape: btape.c:2496 Begin writing raw blocks of 10240 bytes. >> + >> >> - btape HP-LTO2, rawfill (maximum block size set to 8192) => panic >> Output was: >> *rawfill >> btape: btape.c:2496 Begin writing raw blocks of 8192 bytes. >> ++ >> >> >> Any further ideas? >> >> > > Update: > > I experimented a little with blocksizes. Up to 4092 works great. More or > equal than 5120 kills the machine. Any ideas, why 4092? > Yes. That is likely the maximum jumbo frame packet size for the iSCSI NIC. If the physical block size exceeds the maximum packet size, then fragmentation is required. Most tape drives are used in variable block mode by st, in which case the physical block size is the size of the data record being written (plus some linked-list pointer data). The st driver must write a physical block in one atomic operation (ie. one SCSI command). So my guess is that when the iSCSI driver receives that SCSI command from the st driver with a physical block size greater than the maximum packet size of the NIC, then the required packet fragmentation is not be handled correctly. A kernel memory block being used as a buffer is perhaps not being freed.
Curious as to why tar worked when btape did not, I found this. For portability reasons, tar appears to always use a physical block size of 512 bytes. See http://www.gnu.org/software/tar/manual/html_section/tar_73.html. Perhaps that explains the difference in how tar writes to tape versus how btape writes to tape. If this is the problem, then it is not really unexpected. It is probably not yet very common to use tape devices over iSCSI. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
