Re: BD-R formatting help
It's just that last- and first-session mounts will be
equivalent.
Apparently we have to rewind the discussion a bit, because there is one
thing I said/implied that was *wrong*. Sorry. Rewind backwards to the
question about if BD-R is like DVD+R. I said "yes, with POW twist" and
then discussion went on to multi-sessioning and I erroneously implied
that all BD-R recordings performed by growisofs are multi-session. Only
SRM and SRM-POW recordings are, SRM+POW recordings are *not*. SRM+POW
recordings are multi-track, but not multi-session. Meaning that even
multi-session aware OS will look for volume descriptor at LBA#16 for
SRM+POW recording. What I implied was that multi-session aware OS would
look for volume descriptor in the last recorded increment, while none
multi-session aware one - at LBA#16, which is wrong. SRM+POW recordings
*performed by growisofs* appear single-session to all OSes. There was a
number of factors affecting this decision and I reckoned this is the
most reliable/sensible way to make whole data accessible in widest range
of OSes [modulo possible bugs]. There are other possible working
options, but the SRM+POW method implemented by growisofs appeared, once
again, *most sensible*.
Yes. And thus the real first session will not
be mountable because its volume descriptors
are overwritten.
We simply seem to assign different meanings to "mountable" in the
context. To me mountable is mere validity/sanity of volume descriptor
and to you is access to first recording. Let's call it "muted" instead,
in which case answer is "yes, 1st recording will become muted." Sanity
is restored.
First session effectively grows and it has nothing to do with drive
recognizing multi-session.
So you leave the track open ?
No. But I leave session open in SRM+POW (as implied in the beginning).
I assumed you fork a new track, write the
session, use POW to patch LBA 0 to 31 and
then close the track.
Right. Except that considering rant in the beginning it might be more
appropriate to refer to recording as "increment", not "session", in
SRM+POW context.
With overwriteables i write the first session
to LBA 32
Cool.
You can do this easily with mkisofs too:
-C 0,32 (but no -M)
Just start writing at LBA 32 and do the LBA 0
patching when the session is done.
More is not needed.
Cool.
Well, maybe a dvd+rw-toc command.
xorriso would do that for growisofs too. It has
an alias name especially for that:
export MKISOFS="xorrisofs"
growisofs -Z /dev/dvd /some/files
growisofs -M /dev/dvd /more/files
Emulation of -C goes up to the -C 16,x bug. :))
Even incremental backups are possible:
growisofs -Z /dev/dvd -- outdev - -update_r /my/files /files
growisofs -M /dev/dvd -- outdev - -update_r /my/files /files
(Btw: would it be possible to lift the ban on
options like "-outdev", "-overwrite",
"-options_from_file", ... ? They all are
mistaken for -o.)
Cool. I have to consider it...
other sessions would have to be identified by
looking at track start addresses instead of volume size round ups.
I assume there is a regular pattern of gaps
between two sessions.
For reference, according to READ TRACK INFORMATION end of any given
track coincides with start of next one. Though it (end of track) does
not necessarily coincides with the end of recording. I don't seem to
have data on sessions... I should have, I'll look...
And even if not:
one can scan for ISO 9660 heads quite effectively.
Rounding up to BD cluster size would also be appropriate.
--------------------------------------------
A remark about
http://fy.chalmers.se/~appro/linux/DVD+RW/Blu-ray/
Your text can make the reader believe that POW
consumes Spares. But it messes up the logical address
space instead. (If you write to an orphan then you
create a new orphan. Cough.) MMC-5 4.5.3.5.4.1:
"When a SRM disc has the POW capability, the Logical
Overwrite of a Cluster is redirected to the NWA of
some open Logical Track"
Only "information about the redirections is
stored in the Defect List."
--------------------------------------------
Busted on spot! To my "defense" I can only say that it does say in the
beginning that it's "somewhat less organized notes":-) But to be serious
the page was never meant to be a 100% accurate technical description and
I deliberately avoided going into very deep details. It admittedly can
create such impression, but it does not actually say it, does it? It
says that Spare Area is required for SRM+POW and is used to support POW.
And it *is* used, because at least the defect list resides in the Spare
Area, i.e. consumes it. But either way, yes, your remark is perfectly
correct and I do appreciate it. I just hope more people do:-) Cheers. A.
Reply to: