Capacity on LTO4 tapes

[darkstormfwm-creator]

Hello

Thank you for your program it is a very powerfull software.
I have old LTO4 drive (800gb) and your program reports 745GB, full capacity of my empty tape.
[19:18:06] Capacity: 799 999 524 864 bytes ~ 745,05 GB
When tape is finished write program report
[21:18:26] 490 succeeded, 744,33 GB written
[21:18:26] 1h 56m 22s, 109,16 MB/s
[21:18:26] Remaining media capacity: 39 914 045 440 bytes ~ 37,17 GB
So i`m confused how to use remaining capacity on that tape ? it is possible to use rest of that.
On Linux i can archive up to 772GB on single tape.
Please guide me if it is possibly how to use remain capacity.

Thank you.

[avk1im]

Hi @darkstormfwm-creator,
Thanks a lot for using TapeNET — I really appreciate your feedback and the detailed report!

What you’re seeing is likely related to how TapeNET currently estimates remaining tape capacity when hardware compression is enabled in single‑partition mode (the only one supported by LTO-4 and earlier). In this mode, TapeNET must ensure that enough space remains at the end of the tape to write the TOC safely.

The challenge is, the older (mostly pre-LTO) drives report the remaining space unreliably. Therefore, TapeNET maintains its own bookkeeping - which for now doesn't account for the hardware compression, much rather errs on the safe side and may declare the tape “full” earlier than the physical limit.

This issue does not occur when using software compression, because TapeNET knows the exact compressed content sizes and can calculate remaining space precisely. When you select software compression, TapeNET automatically disables hardware compression, since combining both is counterproductive.

It also does not occur when using two‑partition tape mode (offered by e.g. LTO-5+ or Sony AIT), where the TOC resides in a dedicated partition and remaining‑capacity estimation is no longer critical. This may be useful information for others reading the issue.

Workaround for now:
Use software compression in TapeNET. The recommended “medium” level is typically more efficient than LTO‑4’s built‑in compression and fast enough to keep the tape streaming. (Feel free to experiment with all 19 compression levels! 😊 ) I'd highly appreciate the feedback on your experience with the workaround!

I’m already working on improving the remaining‑capacity logic for hardware‑compressed backups. The challenge is detecting whether TapeNET can rely on drive’s reported free‑space values. Your report confirms the behavior I’m targeting, so this is very helpful!

I’ll keep this issue updated as I make progress and will point to the new builds here once the improved handling is ready.

Thanks again for taking the time to report this — it genuinely helps improve TapeNET!

Thanks,
Alex

[darkstormfwm-creator]

Hello Alex

I have analyzed your information about workaround and created simply bypass.
As my expirience with a lot LTO3 and LTO4 tapes i have know what size is for most good tapes a good solution and not reaching EOT.
You have writed many comments to your code (Thank you), a`m simply write workaround to my solution.
As all LTO4 tapes report size in bytes i have rewrite that size with bigger value.

private void CacheContentMediaParams(in MediaParameters mediaParams) { m_cachedContentCapacity = mediaParams.Capacity; m_cachedContentRemaining = mediaParams.Remaining; if (mediaParams.Capacity == 799999524864) m_cachedContentCapacity = 828950162964; if (mediaParams.Remaining == 799995330560) m_cachedContentRemaining = 828945968660; }

Maybe it in not elegant solution but in my case it worked well.
I`m not using any of compression, my program encrypt my data and compress very well, so in my case any compression will be no usable.

Now all LTO4 tapes report bigger sizes and also with remaining size aviable now i can backup full 770 GB.
[22:53:11] 456 succeeded, 770,75 GB written
[22:53:11] 1h 58m 17s, 111,2 MB/s
[22:53:11] Remaining media capacity: 12 562 989 056 bytes ~ 11,7 GB

Tested so far on HP and Dell tapes, soon i will add LTO3 bigger sizes.
As i`m not planning change to a new format with lto5+ this single partition will be sufficient.
Only what stop my archive is grow is psyhical size what i must get to store these tapes.
Right now i can buy lto tapes for very low price (around 3-4 usd per TiB)

Anyway i`m veryy hapy using your code.
Can i please to add two features to program as write last setting (block size , comression, backup name and autoselect that options with new backup option ?
and option to auto eject tape with write log on disk to get some history to analyze 🗡️

Best regars
Christopher

[avk1im]

Hi Christopher @darkstormfwm-creator,

I've updated the remaining capacity estimation for LTO drives -- please check it out, thank you in advance.

I've also added the button to load the Backup settings from the last backup set (Load from Last), plus the auto-eject option upon completion of Backup and of Restore (Eject media when done, under Options). Thank you for the helpful feature suggestions!

As for writing the log to a file, you can enable that via menu Log | Mirror Log to File.

Thank you once again,
Alex

[darkstormfwm-creator]

Hello Alex

I have tested this new features, all working fine. Big thank you for this !!
Now i`m writed files to tape but i think all tapes got extra capacity on another sofware i can write up to 772GB on LTO4 tape. on previous version my by pass to use full capacity works fine on this new compilation seems not worked.

Here some logs from new program:
[18:21:18] 412 succeeded, 743,26 GB written
[18:21:18] 1h 56m 32s, 108,85 MB/s
[18:21:18] Remaining media capacity: 37 605 081 088 bytes ~ 35,02 GB
[18:21:18] ℹ Multi-volume continuation skipped (no-multivolume mode)
[18:41:35] Capacity: 799 999 524 864 bytes ~ 745,05 GB
[18:41:35] Remaining: 37 450 940 416 bytes ~ 34,87 GB

If you want full log i can provide and test

Best regards
Christopher

[avk1im]

Hi Christopher @darkstormfwm-creator,

I've implemented a yet more elaborative estimation of the remaining capacity for the 1-partition configuration. It ensures ~99% of the media capacity is utilized. The remaining ~1% (e.g. ~7 GB on LTO-4 media) is the necessary safety margin to ensure sufficient space for the TOC (table of content).

Unfortunately, Windows Win32 Tape API doesn't expose the early end-of-media zone warning (EWEOM) mechanism of LTO drives. Hence greater precision would be hard to achieve, esp. for all types of drives / vendors.

Please check it out -- thank you once again!
Alex

[darkstormfwm-creator]

Hello Alex

Im sorry for a long delay on vacation ;).
Now i have test 772 GB i hope all will write.
So far only what i have notice it is a speed, on previous version i have 115mb/s (Full lto4 speed) with 64KB.
No i can speed up to 80MB with 256KB, on 64KB i have only 30MB :(.
I think it is buffer,sector problem but please correct me if i`m wrong.
Later i will report when full bacup end.

Thanks a lot for a huge support.

[darkstormfwm-creator]

Hello Allex

I have tested new revision of your app.
i have writed 767 GB so it is great progress.
[01:11:53] 97 succeeded, 766,93 GB written.
But program write strange speeds
[01:11:53] 2h 45m 44s, 143,84 MB/s.
[01:11:53] Remaining media capacity: 7 933 526 016 bytes ~ 7,38 GB