Hi, Sreyan Chakravarty wrote: > Okay, so what you are doing is actually against convention. It's fully compliant. Just moving apart the default mountable superblock from the chain of session superblocks which need an extra option to mount(8) in order to get mounted. > Essentially, the OS assumes that since the device is > rewritable multi-session does not need to keep old records. The drive maintains the table-of-content on sequential media. The operating system inquires this table by SCSI commands. SCSI On overwritable media, the commands will report of one single track in one single session, the formatted area. > What you have done is emulated the TOC of sequential media on rewritable > media. Yes. > Is there a limit to the number of sessions a media can store ? I mean is > that a fixed number or that is dependent on the capacity itself ? On overwritable media, data files, or block devices it is only the medium capacity which limits the number of sessions. I have a backup scheme with compressed files which fits about 400 sessions on one BD-RE before it is full. On sequential media there are limits on the size of the table and also there are substantial gaps wasted between sessions on CD-R, CD-RW, DVD-R, DVD+R, unformatted DVD-RW. Only BD-R store their sessions quite seamlessly. CD is restricted to 99 tracks, because the numbering is two decimal digits beginning at 01. But their capacity of <= 800 MB does not offer enough room for 99 sessions with drive-chosen gaps inbetween. DVD-R and DVD-RW are restricted to 99 sessions, too. DVD+R take at most 153 sessions. With BD-R it depends on the drive. My LG BH16NS40 and Optiarc BD-5300S do 128 sessions before they close the medium automatically. My ASUS BW-16D1HT does 250+ sessions. For now it refused only when the medium had not enough room for the next session's data. > I really don't know how you wrote a program like xorriso or libburn, It needed some endurance. I began in 2005, when it was to fear that quarrels between Linus Torvalds and Joerg Schilling would deprive Linux of the program to write CDs in TAO write mode. (Well, Debian forked wodim from cdrecord in 2006. I could have spared my effort if it was only about CD writing. But since then my scope widened.) > I mean where would you even get the > implementation details for something so obscure. It's publicly specified. SCSI volumes SPC, SBC, MMC for optical drives. ECMA-119 aka ISO 9660 for the filesystem. Joliet, SUSP, RRIP for its extra metadata. El Torito for booting from optical media. UEFI for partition tables. Only MBR boot code is pure oral culture. One has to read Wikipedia. (I invented AAIP on base of SUSP to store ACLs, extended file attributes, and self-invented ISO 9660 metadata. Only libisofs can read it, though.) Hardest part is to find out how to deal with the non-standard features of the various operating systems. Each does SCSI passthrough by a different method. When in doubt, i looked what growisofs does. Its code is fewly structured which makes it quite easy to spot the work flow of SCSI commands. Sometimes i decided to deviate from Andy's decisions after reading the background in MMC specs. I wrote down what i learned in the ./doc directories of my library tarballs. See .txt files in https://dev.lovelyhq.com/libburnia/libburn/tree/master/doc https://dev.lovelyhq.com/libburnia/libisofs/tree/master/doc Have a nice day :) Thomas _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
