Hi Vodochnik,
Looks like the case was just opened, and Support has not had a chance to review the logs yet, so let's wait for their analysis.
I would trust the capacity stats from this line:
[27.03.2025 06:46:26.575] <01> Info (3) [Tape HAI023L8] Updating, Capacity 11999999164416, Remaining 20526923776, PartitionCount 1, IsWriteProtected False, IsWorm False, UsageStatistic {LifetimeRead: 12018MB, LifetimeWritten: 10952693MB, LoadCount: 3, CleaningCyclesLeft: 0}
That will show how much was actually left on the tape, and looks like it's about 20 GiB left:
PS /Users/vvvvvv> 20526923776/1GB
19.1171875
How to explain this? Regrettably can only guess right now but it's possible there are issues when writing to tape and the tape drive has to scroll ahead to section of the tape; this is how tape handles such recoverable write errors, it just moves down the track and continues, and returns offsets from the successful write to the client, meaning that unsuccessful writes are dead space on the track.
I am simplifying this a little, and remember this is just a guess, but it would explain the behavior.
I would wait for Support's analysis of the logs first to get an idea what's happening, maybe they'll see the same or another behavior that explains what you're seeing.
Looks like the case was just opened, and Support has not had a chance to review the logs yet, so let's wait for their analysis.
I would trust the capacity stats from this line:
[27.03.2025 06:46:26.575] <01> Info (3) [Tape HAI023L8] Updating, Capacity 11999999164416, Remaining 20526923776, PartitionCount 1, IsWriteProtected False, IsWorm False, UsageStatistic {LifetimeRead: 12018MB, LifetimeWritten: 10952693MB, LoadCount: 3, CleaningCyclesLeft: 0}
That will show how much was actually left on the tape, and looks like it's about 20 GiB left:
PS /Users/vvvvvv> 20526923776/1GB
19.1171875
How to explain this? Regrettably can only guess right now but it's possible there are issues when writing to tape and the tape drive has to scroll ahead to section of the tape; this is how tape handles such recoverable write errors, it just moves down the track and continues, and returns offsets from the successful write to the client, meaning that unsuccessful writes are dead space on the track.
I am simplifying this a little, and remember this is just a guess, but it would explain the behavior.
I would wait for Support's analysis of the logs first to get an idea what's happening, maybe they'll see the same or another behavior that explains what you're seeing.
Statistics: Posted by david.domask — Mar 31, 2025 9:50 am
