- Joined
- Feb 15, 2014
- Messages
- 20,194
Huh, if you need proof that the forum structure needs work is that I missed this airing of grievances. I have so much to air!
Like the idiots who decided to use LTO tapes for backups in 2007 (not idiots, just weirdos), then decided to write a new Table of Contents file after each real file they'd write to tape (I guess...?), then decided that a specific ustar variant supported by GNU tar but not supported by BSD tar was what they'd use (Oh, these Linux folk...) and finally, the pièce de résistance:
They wrote each file in an individual tar archive with zero compression.
Yes, they had multiple files to write at once. From two to like 10 per satellite image, depending on the satellite. One big image plus tiny metadata images, but oops, there go another 128 kB of the tape for that 10 kB XML file. Plus another 128 kB for a new copy of the ToC. Plus EOF markers. That's 25x write amplification! And extra tape wear! And worse manageability!
And getting the damned drives to even work... They'd been sitting for 10 years and the heads were stuck like they were glued in place, so there I sat for hours carefully lubricating the head bearings (six of them times two drives!), boring local high schoolers on a work experience thing with Abe Simpsonesque stories about the distant year 1999 at the same time they make feel old ("You guys know about VHS?" "Oh yeah, my grandfather has one!" - emphasis mine). I get one drive done, we stick it back into the monster tape library (HP MSL6000 series double decker with two LTO-3 tape drives installed and room for two more, parallel SCSI version - not the fancy Fibre Channel stuff - for those following along at home), it feeds the tape and makes noise... but the drive errors out again. I repeat the process for the second drive, but break a little ferrite stick attached to the head, which goes into a coil and must be used to read the head's position on its vertical axis.
Somewhat defeated, a few days later, we went back and set up the drive on the bench, outside of the tape library. The year being 2022, we don't have an assortment of parallel SCSI cables with different connectors lying around to directly wire up the trusty Broadcom/LSI (I guess Broadcom/LSI still write the Linux driver for these things?) Fusion-MPT Ultra320 SCSI HBA to the drive's internal-style connector, so we precariously balance the drive's sled (it's just a standard internal full-height 5.25" drive inside a library-specific sled) so that we can attach external power via the AMP Mate-N-Lok power connector (don't call them Molex, folks) while using the sled to adapt the drive to the SCSI cable we had on-hand. The expectation was that we'd see what was going wrong with the (not-broken-by-Eric-the-klutz) drive.
Well the drive worked flawlessly. I suspect the tape library's sole functional PSU is less functional than thought and that was keeping the drives from working - and probably why it was abandoned 10 years ago, until we actually needed to read the old tapes. The drive heads would then have seized up simply by virtue of sitting around for a decade. Sure, the room is air conditioned, but salty air in the middle of the ocean still has nasty effect in such a room.
So now I get to deal with the work of someone who apparently never learned in school (Or at work. Or in their free time. Or through a shocked look on their co-workers' faces. Or in any of a million ways.) that tar is best used to archive multiple files in one archive.
What does this have to do with TrueNAS? I have to complain about TrueNAS? Well, I guess TrueNAS could include GNU tar in addition to BSD tar, since it has more features.
Like the idiots who decided to use LTO tapes for backups in 2007 (not idiots, just weirdos), then decided to write a new Table of Contents file after each real file they'd write to tape (I guess...?), then decided that a specific ustar variant supported by GNU tar but not supported by BSD tar was what they'd use (Oh, these Linux folk...) and finally, the pièce de résistance:
They wrote each file in an individual tar archive with zero compression.
Yes, they had multiple files to write at once. From two to like 10 per satellite image, depending on the satellite. One big image plus tiny metadata images, but oops, there go another 128 kB of the tape for that 10 kB XML file. Plus another 128 kB for a new copy of the ToC. Plus EOF markers. That's 25x write amplification! And extra tape wear! And worse manageability!
And getting the damned drives to even work... They'd been sitting for 10 years and the heads were stuck like they were glued in place, so there I sat for hours carefully lubricating the head bearings (six of them times two drives!), boring local high schoolers on a work experience thing with Abe Simpsonesque stories about the distant year 1999 at the same time they make feel old ("You guys know about VHS?" "Oh yeah, my grandfather has one!" - emphasis mine). I get one drive done, we stick it back into the monster tape library (HP MSL6000 series double decker with two LTO-3 tape drives installed and room for two more, parallel SCSI version - not the fancy Fibre Channel stuff - for those following along at home), it feeds the tape and makes noise... but the drive errors out again. I repeat the process for the second drive, but break a little ferrite stick attached to the head, which goes into a coil and must be used to read the head's position on its vertical axis.
Somewhat defeated, a few days later, we went back and set up the drive on the bench, outside of the tape library. The year being 2022, we don't have an assortment of parallel SCSI cables with different connectors lying around to directly wire up the trusty Broadcom/LSI (I guess Broadcom/LSI still write the Linux driver for these things?) Fusion-MPT Ultra320 SCSI HBA to the drive's internal-style connector, so we precariously balance the drive's sled (it's just a standard internal full-height 5.25" drive inside a library-specific sled) so that we can attach external power via the AMP Mate-N-Lok power connector (don't call them Molex, folks) while using the sled to adapt the drive to the SCSI cable we had on-hand. The expectation was that we'd see what was going wrong with the (not-broken-by-Eric-the-klutz) drive.
Well the drive worked flawlessly. I suspect the tape library's sole functional PSU is less functional than thought and that was keeping the drives from working - and probably why it was abandoned 10 years ago, until we actually needed to read the old tapes. The drive heads would then have seized up simply by virtue of sitting around for a decade. Sure, the room is air conditioned, but salty air in the middle of the ocean still has nasty effect in such a room.
So now I get to deal with the work of someone who apparently never learned in school (Or at work. Or in their free time. Or through a shocked look on their co-workers' faces. Or in any of a million ways.) that tar is best used to archive multiple files in one archive.
What does this have to do with TrueNAS? I have to complain about TrueNAS? Well, I guess TrueNAS could include GNU tar in addition to BSD tar, since it has more features.