Hi,
I first found mention of this .omnirc tunable in Daniel's best practice guide and tried it on a DP6.11 MA. Now that OB2MACHECKCAPACITY is even "documented" in omnirc.tmpl I tried it again on 9.04. So apparently, LTO drives allow the host to query the used up and/or remaining capacity of a particular medium. Great stuff in times of compressing drives, as it would allow to fly less blindly into an approaching EOM. Apparently the query is even used for some time now when labeling a tape (what DP calls "Format"), irrespective of the value of this variable: I wondered how exactly it gets to the 2499053 "Available Space(MB)" value it shows for my LTO6 media after formatting, until finding that is exactly the value a Scan also retrieves for said media with OB2MACHECKCAPACITY enabled. But now for the issues:
- Obviously with this enabled, the retrieved (natively used) capacity replaces the true user data written capacity of the medium, thus destroying any track of that value. I want to know both of them.
- Due to replacing the actual capacity with the compressed one in the IDB, even the Pool's "Usage" statistic will now show the sum of native tape capacities only. You no longer can deduce in any way the total user data written to that pool, only what is left of it after compression.
- The media that are already filled up completely don't show a remaining capacity of 0. Instead, with LTO3 there is always something like 17GB supposedly remaining, while on LTO6 I've seen anything from 80GB to 115GB. The used capacity varies accordingly, on LTO3 it's typically 382GB, on LTO6 from 2384GB to 2411GB. What does this signify? See below for a theory, but in any way, it now seems like these media have (significant) capacity remaining when they clearly don't, given they are marked FULL.
I can't shed the feeling that the whole issue of the remaining capacity is a wonderful example of why IEC prefixes for powers of 2 capacities exist and abusing SI prefixes for them was a very bad idea. The classic "1.44MB floppy" comes to mind, and one day we will lose spacecraft for this nonsense. Could it be that said 2384GB, which are actually shown as 2384498MB, are actually 2384498 MiB which means 2500327374848 Bytes, so it is slightly more than the guaranteed native capacity of LTO6? And is 2411321MB actually 2411321 MiB and thusly 2528453328896 Bytes, way over the 2500GB I can expect? If so, where is the supposedly remaining capacity coming from, is there someone just subtracting the read out value from 2500 GiB? This would explain a lot, but it would render the 2499053 value somewhat fishy. If that were MiB too, it would mean 2620446998528 Bytes - that may be planned overcapacity of LTO6 for quality-induced rewrites and filemarks, but I'm not convinced. It may of course all be more bad math, like the 1.44MB floppy all over again, but I don't have the code to check. If anyone out there has more insight into how these perplexing numbers fit together, I'm all ears.
So far and with all these issues, though, I don't think activating that tunable makes a lot of sense. Am I missing something?
TIA,
Andre.