I agree a 2GB fragment size for an LTO3 / 4 drive is a little on the small size, but rather than choosing the fragment size to fit the tape technology perhaps it would be useful to select fragment size based on the type of the data we are backing up. Large single file data such as image, audio or exported databases etc. would benefit from using the larger fragment sizes. Database Agent orientated backups such as RMAN / MSSQL  could use a fragment size based on their fileset size or multiple thereof. Whilst User home accounts, source code project directories would  use the smaller settings. Of course all this only applies to non NDMP backups.

There is an advantage of using fragment sizing in that’s it a great way of determining tape throughput. It’s easy to calculate the speed of a backup if you know that its taking t minutes to backup a 2 or 20GB fragment rather than  waiting t hours for a terabyte.

Psychology: Nothing is more re-assuring then seeing  the fragment markers  count up in the job details panel. Its  good indicator that all is well with that client.

As to the overhead of fragment  markers in the catalogue  I have no idea.

Just my 2-bits worth.

Gideon Wheeler