amanda v 3.5.1, Debian AMD64 Buster, Quantum STO-5, LSI SAS2008 PCIe card I think I've found my problem. Amanda can't write big files to tape.
>From my Debian kernel.log (grep for st0): Dec 13 15:41:34 sbox kernel: [ 2708.331836] st 0:0:2:0: [st0] Block limits 1 - 16777215 bytes. Dec 13 15:44:32 sbox kernel: [ 2885.931242] st 0:0:2:0: [st0] Error e0000 (driver bt 0x0, host bt 0xe). Dec 13 15:44:32 sbox kernel: [ 2885.931245] st 0:0:2:0: [st0] Error on write filemark. Dec 13 15:44:38 sbox kernel: [ 2891.941684] st 0:0:3:0: Attached scsi tape st0 Dec 13 15:44:38 sbox kernel: [ 2891.941687] st 0:0:3:0: st0: try direct i/o: yes (alignment 4 B) Dec 13 15:46:28 sbox kernel: [ 3001.878038] st 0:0:3:0: [st0] Block limits 1 - 16777215 bytes. Dec 14 14:06:33 sbox kernel: [ 2.424988] scsi host0: ata_piix Dec 14 14:06:33 sbox kernel: [ 11.462017] st 3:0:0:0: Attached scsi tape st0 Dec 14 14:06:33 sbox kernel: [ 11.462018] st 3:0:0:0: st0: try direct i/o: yes (alignment 4 B) Dec 14 15:53:45 sbox kernel: [ 6603.276972] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes. Dec 14 16:08:29 sbox kernel: [ 7487.326410] st 3:0:0:0: [st0] Error 40 (driver bt 0inx0, host bt 0x0). Dec 14 16:09:05 sbox kernel: [ 7523.203323] st 3:0:1:0: Attached scsi tape st0 Dec 14 16:09:05 sbox kernel: [ 7523.203326] st 3:0:1:0: st0: try direct i/o: yes (alignment 4 B) and on and on for pages. dmseg says: 16777215 root@sbox:/var/log# dmesg | egrep st0 [ 2.424988] scsi host0: ata_piix [ 11.462017] st 3:0:0:0: Attached scsi tape st0 [ 11.462018] st 3:0:0:0: st0: try direct i/o: yes (alignment 4 B) [ 6603.276972] st 3:0:0:0: [st0] Block limits 1 - 16777215 bytes. [ 7487.326410] st 3:0:0:0: [st0] Error 40 (driver bt 0x0, host bt 0xin0). [ 7523.203323] st 3:0:1:0: Attached scsi tape st0 [ 7523.203326] st 3:0:1:0: st0: try direct i/o: yes (alignment 4 B) [ 7570.604960] st 3:0:1:0: [st0] Block limits 1 - 16777215 bytes. [ 7844.727097] st 3:0:2:0: Attached scsi tape st0 [ 7844.727101] st 3:0:2:0: st0: try direct i/o: yes (alignment 4 B) [ 7955.289508] st 3:0:2:0: [st0] Block limits 1 - 16777215 bytes. [130700.591001] st 3:0:2:0: [st0] Error e0000 (driver bt 0x0, host bt 0xe). [130702.840754] st 3:0:2:0: [st0] Error 10000 (driver bt 0x0, host bt 0x1).16777215 [130706.850766] st 3:0:3:0: Attached scsi tape st0 [130706.850787] st 3:0:3:0: st0: try direct i/o: yes (alignment 4 B) [131166.864674] st 3:0:3:0: [st0] Block limits 1 - 16777215 bytes. It looks to me like amanda's trying to write data that's too big for something in the kernel (there are 1G files in the holding disk). If that's correct, it looks like a simple change in some config should fix it. I've looked for a config to change, but can't find it. grep tells me that '16777215' (aka 0xffffff) isn't in any file in /boot. On the web, it looks like others are having similar troubles in other Linux distributions and with other backup software. That says to me that there was a change in my most recent update of the Linux kernel -- and that (probably) means the size definition is somewhere in the source (or maybe a binary number somewhere in /boot). I've compiled kernels before, so I think I could probably find this setting somewhere in the source, but the source is huge. Does anyone know where that 16777215 number is? Is it accessible in the make config file? Is it in one of the C include files? Do the amanda developers have a patch to deal with this? Is there a more civilized way to do this? Am I looking at the wrong thing? -- Glenn English
