Hi, 25.10.2007 16:34,, 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? >
That's just below 4k, which is the normal memory page size in x86 hardware. If that's the issue, you probably ran into a driver bug. Bacula, as far as I know, is writing much more quickly (you might also say aggressively) to the tape driver, so it might overrun the driver somewhere. I think this should probably be reported to the iSCSI driver maintainer. Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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
