Hi,
In a nutshell, I have a server with a Ultrium/LTO-1 tape drive that should give me a 100GB per tape (or 200GB with the advertised 2:1 compression ratio) - and all I can ever get on a tape is about 50GB only!
So now, on with the details that I've managed to piece so far.
The server is a HP/DL380 - I have in addition to the built-in RAID controller an Adaptec 29160 - this is what the HP Ultrium-230 drive is connected to.
The server runs Xubuntu 6.06 (basically, this is Ubuntu LTR 6.06 with an Xfce GUI) - the kernel is a stock 2.6.15-26.
I am reasonnably sure the the problem is not hardware related:
- I can write 15GB uncompresse on a DLT-IIIXT tape (exaclty what I'm supposed to be able to write)
- I don't get any error messages - just a "tape full" after writing only 50GB
- I can read whatever I have written on the tape - so I'm pretty sure there is no data corruption
- as the SCSI controller is both dedicated to the tape drives and not a RAID one, I don't think shoe-shinning is the issue (the drive was originally connected to the RAID controller, but I have taken it off as part of my investigations)
When I originally started, the tape density as reported by "mt -f /nst0 status" was set to code 0x24 (for DDS-2 drives, from memory) - I have changed it to 0x40 (after a bit of goolging I found that this should be the density code for LTO-1 tapes), but still have the same problem.
I have noticed, though, that when running a "mt -f /dev/nst0 densities" there is no 0x40 listed, and that there is no other code for any LTO/Ultrium tapes - now, as far as I can tell, this is more for information purposes than a clear list of what's supported, but you never know.
I have tried to backup both a regular /home partition (with all sorts), a VMWare image which is over 60GB in size, and running "dd if=/dev/urandom" tests and in all instanced, the tape is full after about 50GB - so I'm pretty sure that what happens is not linked to some sort of "side effect" of the backup software struggling with large filesystems / small files, etc. I ahve carried tests using both bacula (backup software), straightforward tar, and even more sraightforward dd, and the same happens time and time again. The tapes themselves I thin can be ruled out as I have used 3 brand new tapes with no difference.
I have a suspicion that the problem is linked to the SCSI layer and/or the st driver which is not quite configured as it should and just stops short before time (or does not use the correct algorithm/blocksize/god knows what else to maximize data density on the tape) - but I just don't know where to look next -
If anyone as either encountered a similar problem, or has an idea, any help will be greatly received!
Olivier
In a nutshell, I have a server with a Ultrium/LTO-1 tape drive that should give me a 100GB per tape (or 200GB with the advertised 2:1 compression ratio) - and all I can ever get on a tape is about 50GB only!
So now, on with the details that I've managed to piece so far.
The server is a HP/DL380 - I have in addition to the built-in RAID controller an Adaptec 29160 - this is what the HP Ultrium-230 drive is connected to.
The server runs Xubuntu 6.06 (basically, this is Ubuntu LTR 6.06 with an Xfce GUI) - the kernel is a stock 2.6.15-26.
I am reasonnably sure the the problem is not hardware related:
- I can write 15GB uncompresse on a DLT-IIIXT tape (exaclty what I'm supposed to be able to write)
- I don't get any error messages - just a "tape full" after writing only 50GB
- I can read whatever I have written on the tape - so I'm pretty sure there is no data corruption
- as the SCSI controller is both dedicated to the tape drives and not a RAID one, I don't think shoe-shinning is the issue (the drive was originally connected to the RAID controller, but I have taken it off as part of my investigations)
When I originally started, the tape density as reported by "mt -f /nst0 status" was set to code 0x24 (for DDS-2 drives, from memory) - I have changed it to 0x40 (after a bit of goolging I found that this should be the density code for LTO-1 tapes), but still have the same problem.
I have noticed, though, that when running a "mt -f /dev/nst0 densities" there is no 0x40 listed, and that there is no other code for any LTO/Ultrium tapes - now, as far as I can tell, this is more for information purposes than a clear list of what's supported, but you never know.
I have tried to backup both a regular /home partition (with all sorts), a VMWare image which is over 60GB in size, and running "dd if=/dev/urandom" tests and in all instanced, the tape is full after about 50GB - so I'm pretty sure that what happens is not linked to some sort of "side effect" of the backup software struggling with large filesystems / small files, etc. I ahve carried tests using both bacula (backup software), straightforward tar, and even more sraightforward dd, and the same happens time and time again. The tapes themselves I thin can be ruled out as I have used 3 brand new tapes with no difference.
I have a suspicion that the problem is linked to the SCSI layer and/or the st driver which is not quite configured as it should and just stops short before time (or does not use the correct algorithm/blocksize/god knows what else to maximize data density on the tape) - but I just don't know where to look next -
If anyone as either encountered a similar problem, or has an idea, any help will be greatly received!
Olivier