CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
So I decided I wanted to back up my Windows drive, which is NTFS. Since
there are very big files there, very deep directories, crazy filenames,
etc. I figure UDF is the way to go. The total size was 37GB. I've got a
Blu-Ray burner and so I figure I'll buy a BD-R DL disc and do it. Since
I didn't want a very expensive coaster I figured I'll "master" the UDF
filesystem first, then burn it. I use mkudffs:
mkudffs -r 0x0201 --vid="Old C" --media-type=hd --utf8
/video/oldc_backup.udf 20971520
Then I mount this filesystem, and copy all of the files into the
filesystem. Unmount the filesystem, now I'm ready to go. Now I run:
growisofs -Z /dev/sr1=/video/oldc_backup.udf
This runs for a long time, so I return later and find at the end of the
output:
42919985152/42949672960 (99.9%) @0.7x, remaining 0:09 RBU 88.5% UBU 98.3%
42930864128/42949672960 (100.0%) @0.7x, remaining 0:06 RBU 56.1% UBU 98.3%
42941349888/42949672960 (100.0%) @0.7x, remaining 0:02 RBU 24.8% UBU 98.3%
builtin_dd: 20971520*2KB out @ average 0.7x4390KBps
/dev/sr1: flushing cache
/dev/sr1: closing track
/dev/sr1: closing session
:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output
error
So now I try to mount the disc. Well, this is where things really go
weird. Mount works ok:
smally$ sudo mount -t udf -o ro /dev/sr1 /mnt
smally$ echo $?
0
However, there doesn't seem to be anything there:
smally$ ls -a /mnt
.
smally$
Gack! Could there be something wrong with the file image? It would seem
not, because I can mount the UDF image just fine:
smally$ sudo mount -t udf -o loop,ro /video/oldc_backup.udf /mnt
smally$ ls /mnt
ADOBEAPP favorite.way PMig.Log
AUTOEXEC.BAT Garmin Program Files
bdb-4.2.52 I386 Python23
bin Inetpub Python24
Boost inferno.log Python25
boot.ini IO.SYS RECYCLER
BOOTSECT.DOS j2sdk1.4.1_02 svn-win32-1.0.2
Config.Msi LogiSetup.log svn-win32-1.1.2
CONFIG.SYS lost+found SWIG-1.3.21
[...]
So I figure I'll find out what is on the media:
smally$ sudo dvd+rw-mediainfo /dev/sr1
INQUIRY: [HL-DT-ST][BD-RE GGW-H20N ][XJ03]
GET [CURRENT] CONFIGURATION:
Mounted Media: 41h, BD-R SRM+POW
Media ID: MEI/T01
Current Write Speed: 2.0x4495=8991KB/s
Write Speed #0: 2.0x4495=8991KB/s
GET [CURRENT] PERFORMANCE:
Write Performance: 2.0x4495=8991KB/s@[0 -> 12088319]
2.0x4495=8991KB/s@[12088320 -> 24307711]
Speed Descriptor#0: 02/24307711 R@2.0x4495=9158KB/s W@2.0x4495=8991KB/s
BD SPARE AREA INFORMATION:
Spare Area: 65088/65536=99.3% free
POW RESOURCES INFORMATION:
Remaining Replacements:16843296
Remaining Map Entries: 0
Remaining Updates: 0
READ DISC INFORMATION:
Disc status: appendable
Number of Sessions: 1
State of Last Session: incomplete
"Next" Track: 1
Number of Tracks: 2
READ TRACK INFORMATION[#1]:
Track State: partial incremental
Track Start Address: 0*2KB
Free Blocks: 0*2KB
Track Size: 20971680*2KB
READ TRACK INFORMATION[#2]:
Track State: invisible incremental
Track Start Address: 20971680*2KB
Next Writable Address: 20971680*2KB
Free Blocks: 3336032*2KB
Track Size: 3336032*2KB
FABRICATED TOC:
Track#1 : 14@0
Track#AA : 14@24307712
Multi-session Info: #1@0
READ CAPACITY: 24307712*2048=49782194176
smally$
Looking at the track size it is in fact just a bit bigger than the udf
image file. I fired up an interactive python session and opened up
/dev/sr1 to see if I could seek around and read stuff, which I could.
So could anyone help me understand what's going on? If there's some way
to "fix" the written session that would be great. Or at least I'd like
to figure out what is happening so I can avoid making any further $40
coasters. I'm using dvd+rw-tools 7.1-4 (ubuntu version) in ubuntu
version 9.10. Kernel is:
smally$ uname -a
Linux smally 2.6.30 #1 SMP Sun Nov 1 18:56:42 SGT 2009 i686 GNU/Linux
built locally from git tag for 2.6.30.
Thanks in advance for any help.
--
Jens B. Jorgensen
jbj1@ultraemail.net
Reply to: