[Bacula-users] st: from_buffer offset overflow. - I/O Error
Hi, one again we have a problem with this Kernel error: st: from_buffer offset overflow. in dmesg. This Error has the effect that Bacula cant access to the Tape drive - reboot helps. Atm this Error comes all 2-3 days. I´ve googled a lot but cant find nothing to fix that. It seems to be a problem with the memory fragmentation or the scsi driver. We use Debian Squeezy and the latest bacula release. Any Idea? Thanks & regards Tobias -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] st: from_buffer offset overflow. - I/O Error
Hi, still the same Kernel and I/O Error: Jun 14 14:26:10 xx kernel: [451873.506638] st0: Can't allocate 199 byte tape buffer. Jun 14 14:31:10 xx kernel: [452173.632081] st: from_buffer offset overflow. Jun 14 14:31:10 xx kernel: [452173.632085] st: from_buffer offset overflow. Jun 14 14:31:10 xx kernel: [452173.632087] st: from_buffer offset overflow. Backup only works after reboot. Any Idea? regards Tobias On 09.06.2011 09:21, Tobias Dinse wrote: > Hi, > > one again we have a problem with this Kernel error: > > st: from_buffer offset overflow. > > in dmesg. This Error has the effect that Bacula cant access to the Tape > drive - reboot helps. Atm this Error comes all 2-3 days. > > I´ve googled a lot but cant find nothing to fix that. It seems to be a > problem with the memory fragmentation or the scsi driver. > > We use Debian Squeezy and the latest bacula release. > > Any Idea? > > Thanks& regards > > Tobias > > > -- > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] st: from_buffer offset overflow. - I/O Error
Dear Tobias Dinse, In message <4df88a7d.1020...@stegbauer.info> you wrote: > > still the same Kernel and I/O Error: > > > Jun 14 14:26:10 xx kernel: [451873.506638] st0: Can't allocate > 199 byte tape buffer. Why are you trying to allocate a 2 MB buffer for your tape driver? Bacula will write in 63 KiB blocks, so you should never need that much. What does your /etc/stinit.def look like? [Or where else do you configure your tape driver to use such buffers?] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Deliver yesterday, code today, think tomorrow." -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] st: from_buffer offset overflow. - I/O Error
Hi Wolfgang,
first thanks for your reply!
bacula-sd.conf
Minimum block size = 199
Maximum block size = 199
This is the only Value that we have changed. With lower Values our
Backup was verry slow. We have LTO4 Tapes. Whats your Values?
here is our stinit.def (only 1 line without comment header):
{buffer-writes read-ahead async-writes}
We made no changes to this File.
regards
Tobias
On 15.06.2011 23:08, Wolfgang Denk wrote:
> Dear Tobias Dinse,
>
> In message<4df88a7d.1020...@stegbauer.info> you wrote:
>> still the same Kernel and I/O Error:
>>
>>
>> Jun 14 14:26:10 xx kernel: [451873.506638] st0: Can't allocate
>> 199 byte tape buffer.
> Why are you trying to allocate a 2 MB buffer for your tape driver?
>
> Bacula will write in 63 KiB blocks, so you should never need that
> much.
>
> What does your /etc/stinit.def look like? [Or where else do you
> configure your tape driver to use such buffers?]
>
> Best regards,
>
> Wolfgang Denk
>
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] st: from_buffer offset overflow. - I/O Error
tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULT3580-HH4 '
Revision: '97F1'
Attached Changer API: No
SerialNumber: '1K10044361'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x48
Density Code: 0x46
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
up too 16MB variable Blocksize
On 16.06.2011 11:51, Tobias Dinse wrote:
> Hi Wolfgang,
>
> first thanks for your reply!
>
> bacula-sd.conf
>
> Minimum block size = 199
> Maximum block size = 199
>
> This is the only Value that we have changed. With lower Values our
> Backup was verry slow. We have LTO4 Tapes. Whats your Values?
>
> here is our stinit.def (only 1 line without comment header):
>
> {buffer-writes read-ahead async-writes}
>
> We made no changes to this File.
>
> regards
>
> Tobias
>
> On 15.06.2011 23:08, Wolfgang Denk wrote:
>> Dear Tobias Dinse,
>>
>> In message<4df88a7d.1020...@stegbauer.info> you wrote:
>>> still the same Kernel and I/O Error:
>>>
>>>
>>> Jun 14 14:26:10 xx kernel: [451873.506638] st0: Can't allocate
>>> 199 byte tape buffer.
>> Why are you trying to allocate a 2 MB buffer for your tape driver?
>>
>> Bacula will write in 63 KiB blocks, so you should never need that
>> much.
>>
>> What does your /etc/stinit.def look like? [Or where else do you
>> configure your tape driver to use such buffers?]
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
> --
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] st: from_buffer offset overflow. - I/O Error
Same Problem now on other Servers
kern.log:
xx kernel: [451873.506638] st0: Can't allocate 199 bytetape
buffer
xx kernel: [452173.632081] st: from_buffer offset overflow.
xx kernel: [452173.632085] st: from_buffer offset overflow.
xx kernel: [452173.632087] st: from_buffer offset overflow.
only a reboot helps :(
bacula-sd.conf
Minimum block size = 199
Maximum block size = 199
This is the only Value that we have changed. With lower Values our
Backup was verry slow. We have LTO4 Tapes. Whats your Values?
here is our stinit.def (only 1 line without comment header):
{buffer-writes read-ahead async-writes}
We made no changes to this File.
tapeinfo -f /dev/st0
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULT3580-HH4 '
Revision: '97F1'
Attached Changer API: No
SerialNumber: '1K10044361'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 0
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: 0x48
Density Code: 0x46
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: -1
Partition 0 Size in Kbytes: -1
ActivePartition: 0
EarlyWarningSize: 0
regards
Kernel Log:
On 15.06.2011 23:08, Wolfgang Denk wrote:
> Dear Tobias Dinse,
>
> In message<4df88a7d.1020...@stegbauer.info> you wrote:
>> still the same Kernel and I/O Error:
>>
>>
>> Jun 14 14:26:10 xx kernel: [451873.506638] st0: Can't allocate
>> 199 byte tape buffer.
> Why are you trying to allocate a 2 MB buffer for your tape driver?
>
> Bacula will write in 63 KiB blocks, so you should never need that
> much.
>
> What does your /etc/stinit.def look like? [Or where else do you
> configure your tape driver to use such buffers?]
>
> Best regards,
>
> Wolfgang Denk
>
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
