Hi,
Meillo schrieb:
> Es sind doch in beiden Faellen Sektoren, Tracks und Sessions. Sollte
> es dann nicht auch in beiden Faellen moeglich sein, einfach alle
> Sektoren/Tracks/Sessions nacheinander auszulesen und in eine Datei
> abzulegen?
Es liegt an den Spezifikationen im SCSI Standard. MMC ist zustaendig fuer
optische Laufwerke (nicht zu verwechseln mit "MMC" Memory Cards).
Ein ganz roher CD Sektor (auch "Frame" oder "Block" genannt) besteht aus
98 "Small Frames", von denen jeder 24 Bytes "User Data", 4 Bytes "C2 ECC",
4 Bytes "C1 ECC" und 1 Byte "Sub-channels" enthaelt. (MMC-5 4.2.1.2)
24 mal 98 macht 2352. Das ist die Zahl der Audio Bytes pro Sektor.
Die beiden "ECCs" sind Pruefsummen, die bei leichten Schaeden auch ein
paar wenige falsche Bits korrigieren koennen.
"Sub-channels" sind sehr kleine Datenstroeme, die zB. die aktuelle
Position auf der CD angeben.
Das Ganze stammt vermutlich aus der Entwicklung von digitalen Bandgeraeten
und Videorekordern.
Mit diesen Komponenten kann man sehr seltsame Sektoren zusammensetzen.
Die beiden gebraeuchlisten sind CD-DA, das einfach alle User Data Bytes
fuer die Darstellung von Geraeuschen benutzt, und CD-ROM, das die fuer
Platten ueblichen 2048 Bytes pro Block speichert und die anderen 304 Bytes
User Data fuer die genaue Ansteuerung von Sektoren und fuer massenhaft
Pruefsummen verwendet. Dann gibt's noch CD-ROM XA, das fast wie CD-ROM ist,
und obskure Wolpertinger, die als Kopierschutz dienen.
Nur CD-ROM und CD-ROM XA koennen mit den SCSI Lesebefehlen fuer Platten
oder Baender gelesen werden. Fuer die anderen Sektorformate gibt es in
MMC spezielle Lesebefehle READ CD und READ CD MSF, die aber nicht ueber
die POSIX Systemaufrufe ausfuehrbar sind. Deswegen kann man CD-DA weder
mounten noch mit dd auslesen. (In beiden Faellen versucht es der Linux
Kernel mit dem SCSI Kommando READ(10).)
> Ist das nicht nur eine willkuerliche Festlegung im Treiber?
Es steckt in der Firmware der Laufwerke. Deren Programmierer haben die
SCSI Spezifikationen gelesen. Ebenso machen es die Kernelentwickler
und wir Brennprogrammierer - teilweise mit durchwachsenem Erfolg. (Hust)
> Koennte man nicht auch einen Devicedriver schreiben, der eine Art
> Raw-Device zur Verfuegung stellt, das es erlaubt, alle Sektoren linear
> auszulesen?
Das waere dann das Programm mit dem Clone-Schaf.
Problem ist, wie man dem Benutzer all die Eingeweide praesentiert, sodass er
damit auch was anfangen kann. Beim Klonen ist das klar. Aber beim Lesen
fuers Kopieren in einen Datenfile muesste man entscheiden, was man nicht
im File speichern will.
Die Linux Kernelentwickler haben sich ja schon vor dem Brennen gedrueckt.
Da kann man nicht erwarten, dass sie das Lesen mit allen Eingeweiden in
ihr Geraetemodell quetschen koennen.
> Was das Schreiben betrifft: Sind CD-DA und CD-ROM da grundsaetzlich
> unterschiedliche Formate, die auch technisch nicht in gleicher Weise
> gebrannt werden koennen?
Lustigerweise ist das Brennen da nicht sehr unterschiedlich. In allen
Faellen kann man die Nutzlast mit dem SCSI-Befehl WRITE(10) an den Brenner
schicken, dessen Firmware dann alles noch fehlende Gekroese dazugibt.
Man muss allerdings vorher angemeldet haben, was fuer ein Sektorformat es
werden soll, und bei den exotischen Formaten wissen, wie man selbstgemachtes
Gekroese herstellt.
> Ich verstehe schon, dass bei CD-ROMs ein Dateisystem verwendet wird
Nicht notwendigerweise. Es sind schlichtweg Daten, die mit normalen
Plattenbefehlen gelesen werden koennen. Die hoehere Bedeutung liegt im
Auge des Lesenden. mount(8) will natuerlich in den Daten ein erkennbares
Filesystem finden. Wenn nicht, wird nicht gemountet. dd(1) dagegen nimmt
einfach Daten und hat keine besonderen Ansprueche an ihre Bedeutung.
> bei CD-DA ein TOC mit Adressen auf die einzelnen Tracks.
Die Tracks und Sessions gibt es fuer jedes Sektorformat. Bei CD-DA sind
sie der einzige Hinweis auf die Struktur der Daten auf der CD.
Bei ISO 9660 Filesystemen auf CD, DVD oder BD wird von Linux bei mount(8)
der Superblock aus der ersten Track der letzten Session gelesen. So kann
man eine Scheibe immer wieder auf den neuesten Stand bringen, indem man
neue Sessions hinzufuegt.
Man kann aber auch aeltere Sessions mounten. Meine aktuelle 11 Uhr Backup
BD-R kann zB. jeden Stand zwischen 2. Maerz und heute darstellen:
Code: Alles auswählen
$ xorriso -outdev /dev/sr4 -toc
...
Drive type : vendor 'ASUS' product 'BW-16D1HT' revision '1.01'
...
Media current: BD-R sequential recording
...
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 1992263s , HOME_2021_03_02_110936
ISO session : 2 , 1992416 , 33546s , HOME_2021_03_03_110514
...
ISO session : 102 , 5569728 , 33301s , HOME_2021_06_11_110721
ISO session : 103 , 5603200 , 37851s , HOME_2021_06_12_120532
Media summary: 103 sessions, 5641216 data blocks, 10.8g data, 12.5g free
Mit
kann ich zB. den Backup-Stand von gestern mounten und sehe als vorhandene
Datenmenge 3.8 GB, soviel wie gestern in den gebackupten Directories auf
der Platte war.
Wenn ich aeltere Backups brauche, muss ich eine der alten vollen BD-Rs
aus dem Regal holen. Normalerweise reicht mir eine fuer 200 Tage, wenn ich
den ASUS Brenner nehme, der mehr als 128 Sessions auf BD-R schreibt.
> Inode mit Verweise auf Datenbloecke.
Inodes sind Bestandteile einiger Filesysteme und werden vom Linux Kernel
als innere Darstellung fuer alle Filesysteme benutzt. Bei ISO 9660 werden
sie aus den Directory Records emuliert. Die inode-Nummern entstehen zB.
aus der Byte Adresse des Directory Record geteilt durch 32.
Mit dem Table-Of-Content von optischen Medien haben Inodes nichts zu tun.
> aber wie die Daten dem Betriebssystem praesentiert werden ist doch eine
> freie Entscheidung der Treiber.
Ja, wie oben schon erwaehnt koennte man Treiber in oder neben den Linux
Subsystemen cdrom und sr einbauen, die andere Sektorformate als CD-ROM
als lesbares Blockdevice zugaenglich machen. Man muesste sich nur
entscheiden, welcher Anteil der Sektoren gezeigt werden soll und wie
die Blockgroesse sein soll. (Ein Vielfaches von 512 sollte es wohl sein.)
Aber cdrom und sr sind jetzt schon in einem angefaulten Zustand und die
Kernelentwickler nehmen von uns Userlandern keine Reparaturvorschlaege an.
(
https://lore.kernel.org/linux-scsi/2020 ... x.net/T/#u )
Ein neuer Treiber fuer zB. CD-DA als Blockdevice hat da wenig Chancen.
> ist das nur eine historische Altlast [...] ?
Sehr viel aufeinandergetuermte Historie. Die Industrie hat sich dann auch
bei der Einfuehrung der DVD entschieden, den ganzen Firlefanz in der
Firmware der Laufwerke zu verstecken. Auf DVD und BD gibt's nach aussen
nur noch CD-ROM Sektoren. 2048 Bytes Nutzlast pro Sektor und fertig.
Wer es dem Leser schwer machen will, der verschluesselt einfach die Daten.
Have a nice day
Thomas