Hi,
i wrote:
> > A UDF filesystem image is supposed to bear at its start 32 KiB of zeros.
B.M. wrote:
> This is indeed the case:
> [...]
> For a readable disk, this look like you said: Only zeros.
So it looks like at least a part of the problem is decryption.
> > If UDF does not work even unencrypted,
> Why should UDF not work correctly without encryption?
It's improbable, i confess.
But for now we are hunting an unexplainable problem. So we have to divide
the situation in order to narrow the set of suspects.
Verifying that your procdure with two UDF images is not the culprit would
help even if the result is boringly ok, as we expect. (Or we are in for
a surprise ...)
After the boring outcome you have the unencrypted images to make the next
step, namely to create /dev/mapper/BDbackup with a new empty image file
as base, to copy the images into it (e.g. by dd), and to close it.
Then try whether the two encrypted image files can be properly openend
as /dev/mapper/BDbackup ans show mountable UDF filesystems.
> it's not only the burned disc which is not readable/mountable, it's
> also the image I created before burning.
So we can exclude growisofs as culprit.
> Might it be possible, that when my UDF filesystem gets filled completely,
> the encryption get damaged?
That would be a bad bug in the device-mapper code and also such a mishap
is hard to imagine. The UDF driver is supposed not to write outside its
filesystem data range. That range would be at most as large as the payload
of the device mapping.
> Multi-disc backups are not
> handled by my script, I have to intervene manually.
That's always a potential source of problems.
(Around 1999 i addressed the multi-disc problem for CDs, after my manually
maintained scripts grew in number from 2 to 3. Regrettably i see no
simple way to let scdbackup handle your special encryption wish. We'd have
to hack it a bit. And it's for ISO 9660 not for UDF, of course.)
> I never expected it to
> harm my process, moved some backup files manually, created another image
> which I burned on a second disc.
Do i get it right, that your script copies files into the mounted UDF
and gets a "filesystem full" error ?
What exactly are you doing next ?
(From where to where are you moving the surplus files ?
Does the first /dev/mapper device stay open while you create the encrypted
device for the second UDF filesystem ? Anything i don't think of ... ?)
> Or is my filesystem too large?
25 "GB" would rather be too small to swim in the swarm of other cryptsetup
users.
-----------------------------------------------------------------------
Slightly off topic: A riddle about your UDF image sizes:
> # There is an old comment in my script at this line, saying:
> # let's try that: 24064000K
> # 24438784K according to dvd+rw-mediainfo but creates at
> # least sometimes INVALID ADDRESS FOR WRITE;
> # alternative according to internet research: 23500M
An unformatted single layer BD-R has 12,219,392 blocks = 23866 MiB =
24,438,784 KiB.
But growisofs formats it by default to 11,826,176 = 23098 MiB =
23,652,352 KiB.
growisofs_mmc.cpp emits a message in function bd_r_format()
fprintf (stderr,"%s: pre-formatting blank BD-R for %.1fGB...\n",
ioctl_device,(f[0]<<24|f[1]<<16|f[2]<<8|f[3])*2048.0/1e9);
Watch your growisofs run for it.
(Note that it talks of merchant's GB = 1 billion, not of programmer's
GiB = 107.3741,824. 23098 MiB = 24.220008448 GB)
> IMGSIZE=24064000K
> truncate -s $IMGSIZE $IMGFILE
The man page of truncate says that it's "K" are 1024, i.e KiB.
So your image has 23500 MiB which is too large for the default format
as normally applied to BD-R by growisofs.
growisofs has a bug to accept burn jobs which fit into unformatted BD-R
but then to spoil them by applying its default format:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699186
So how come that your growisofs run does not fail in the end ?
There is an undocumented growisofs option to suppress BD-R formatting:
-use-the-force-luke=spare=none
There is also
-use-the-force-luke=spare=min
which (i guess) will bring 23610 MiB of payload.
(I take the occasion to point out that xorriso does not format BD-R
by default. I.e. default capacity is 23866 MiB.)
Have a nice day :)
Thomas
