~ubuntu-branches/ubuntu/gutsy/dvd+rw-tools/gutsy : revision 1

1

<HTML>

2

3

<HEAD>

4

5

<TITLE>DVD+RW/+R/-R[W] for Linux</TITLE>

6

<META NAME="keywords" CONTENT="dvd, recording, burning, rewritable,

7

dvd+rw, dvd+r, dvdplusrw, dvd-rw, dvd-r, dvd-ram,

8

linux, netbsd, openbsd, solaris, freebsd, hp-ux, irix, unix,

9

hp, ricoh, philips, sony, nec, plextor, benq,

10

optorite, lite-on, pioneer, lg, panasonic, matshita,

11

multi-session, growisofs">

12

<META NAME="description" CONTENT="DVD+RW/+R/-R[W] support for Linux, NetBSD, Solaris, FreeBSD, HP-UX:

13

user-land utilities and optional Linux

14

kernel patch">

15

16

17

18

</HEAD>

19

20

<BODY BGCOLOR="#C0C0C0" TEXT="#000000"

21

LINK="#0000D0" VLINK="#502090" ALINK="#FF0000">

22

23

<HR>

24

<H1 ALIGN="CENTER"><A HREF="http://www.dvdplusrw.org/">DVD+RW</A>/+R/<A

25

HREF="-RW/">-R[W]</A> for Linux</H1>

26

<H5 ALIGN="CENTER">by <appro@fy.chalmers.se>,

27

April 2004</H5>

28

<HR>

29

30

31

32

<TH>Q. <TH ALIGN="left">What is this page (not) about?</TR>

33

34

<TD>A.

35

<TD>Maybe to your disappointment it is not about

36

video(*). The scope of this page is primarily

37

computer storage applications of DVD±RW/±R,

38

things like backup, archiving, data exchange... The

39

downloadable files are an optional <A

40

HREF="linux-2.4.patch">Linux 2.4 kernel DVD+RW patch</A> and a

41

couple of user-land utilities dubbed as <A

42

HREF="tools/?M=A">dvd+rw-tools</A>.

43

44

45

46

<TD>(*)

47

<TD>Though it doesn't mean that you can't burn

48

DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video

49

is "molded" in an ordinary data file system and

50

therefore no explicit support by the burning program is

51

actually required. In other words it is the DVD-Video

52

content preparation which is beyond the scope of this

53

page.</TR>

54

</TABLE>

55

</TR>

56

</TABLE>

57

58

59

60

<TH>Q. <TH ALIGN="left">Kernel patch? This sounds too complicated

61

already! Can't I just use cdrecord?

62

63

</TR>

64

65

<TD>A. <TD>It should be explicitly noted that the user-land

66

utilities, dvd+rw-tools, do suffice for DVD recording

67

without explicit kernel support. So if they <A

68

HREF="#tutorial">fulfill your requirements</A>, then

69

patching the kernel is by all means optional. As

70

for cdrecord, DVD+RW/+R recording strategies are somewhat

71

different from the one supported by cdrecord, so it simply

72

doesn't work (nor does dvdrecord<A

73

HREF="http://www.freesoftware.fsf.org/dvdrtools/">,</A> despite

74

what <A

75

HREF="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/release-notes/x86/">RedHat

76

7.3 Release Notes</A> say).</TR>

77

</TABLE>

78

79

80

81

<TH>Q. <TH ALIGN="left">What is the kernel patch good for then?

82

</TR>

83

84

<TD>A. <TD>DVD+RW (but not DVD+R) is a true random write access media

85

and therefore is suitable for housing of an arbitrary file

86

system, e.g. udf, vfat, ext2, etc. This, and this alone,

87

qualifies DVD+RW support for kernel implementation.

88

However, I have to recommend to deploy it with

89

caution, see <A HREF="#udf">tutorial</A> for further

90

details. Also note that not all OEMs seem to live up to the

91

promise of true random write access. As for the moment of this

92

writing apparenly only 2nd generation Ricoh-based units (see <A

93

HREF="http://www.dvdplusrw.org/">dvdplusrw.org</A> for

94

generation listings) equipped with later firmware can sustain

95

I/O fragmentation (see Technical Ramblings below for further

96

details) and perform reliably.

97

</TABLE>

98

99

100

101

<TH>Q. <TH ALIGN="left">What are the dvd+rw-tools for?</TR>

102

103

<TD>A. <TD>As implied/already mentioned - to master the DVD media,

104

both +RW/+R and <A HREF="-RW/">-R[W]</A>. I could simply

105

refer to the tutorial below, but figured that couple of words

106

about the [original] design ideas behind growisofs, the

107

principal burning utility, wouldn't harm. Even though a

108

modified kernel can let you put for example an ext2 file system

109

on DVD+RW, it's probably not very practical, because you most

110

likely want to access the data on an arbitrary computer.

111

Or in other words you most likely want ISO9660. The trouble is

112

that you might as well want to add data now and then.

113

And what options do you have in the lack of multiple sessions

114

(no, DVD+RW has no notion of multiple sessions)? Complete

115

re-mastering which takes more and more time as data set grows?

116

Well, yes, unless you employ growisofs! Growisofs

117

provides the way to both lay down and grow an ISO9660

118

file system on (as well as to burn an arbitrary pre-mastered

119

image to) all supported DVD media.</TR>

120

</TABLE>

121

122

123

124

<TH>Q. <TH ALIGN="left">But if they support both + and - recording

125

strategies, why are they called dvd+rw-tools?</TR>

126

127

<TD>A. <TD>For historical/nostalgical reasons, as originally they did

128

support exclusively DVD+plus. On the other hand now, when the

129

vast majority of DVD burners that are being introduced to the

130

market today are DVD+capable, the name most likely refers to

131

your unit in either case. And you can always consider the plus

132

in the name as notion of some unique quality, such as

133

"seamless" multi-sessioning, not as reference to some

134

particular format:-)</TR>

135

</TABLE>

136

137

138

139

<TH>Q. <TH ALIGN="left">Do I still need <A

140

HREF="http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html">cdrtools</A>?

141

</TR>

142

143

<TD>A. <TD>Yes. It should be explicitly noted that growisofs is a

144

front-end to mkisofs, i.e. invokes mkisofs to perform the

145

actual ISO9660 file system layout. Secondly, the DVD burners

146

available on the market can burn even CD-R[W] media and

147

cdrecord is the tool for this job [and this job only].</TR>

148

</TABLE>

149

150

<!--

151

152

153

<TH>Q. <TH ALIGN="left">There are dual-format DVD+RW/-RW units

154

available on the market, e.g. SONY DRU500. Can I use

155

dvd+rw-tools with it/them?

156

</TR>

157

158

<TD>A. <TD>If the question is if you can use dvd+rw-tools to master the

159

DVD+RW/+R media in a ±RW drive, then the answer always

160

was "definitely yes." If the question really is if

161

you can use dvd+rw-tools to burn even DVD-R[W] media,

162

then I have the pleasure to inform you that as of version 5.0

163

dvd+rw-tools provide experimental support even for

164

recording of DVD-R[W] media and refer you to <A HREF="-RW/">a

165

dedicated page</A> for further details.</TR>

166

</TABLE>

167

-->

168

169

170

171

<TH>Q. <TH ALIGN="left">Does it work with my DVD burner?

172

</TR>

173

174

<TD>A. <TD>If your unit is <A

175

HREF="http://www.t10.org/drafts.htm#mmc3">MMC</A> complaint,

176

then the answer is "<A HREF="hcn.html">most likely</A> it

177

just does." Well, as the probability of your unit being

178

non-MMC complaint is virtually zero, the answer in practice is

179

unconditionally "<A HREF="hcn.html">most likely</A>."

180

The [core] tools were reported to work with a wide range of

181

drives, including [but not limited to] HP

182

dvd[1234]00i, Ricoh MP512x, Philips

183

DVDRW[248]xx, SONY DRU-[15]x0, NEC

184

ND-[12]x00, TDK indiDVD 4x0N,

185

Plextor PX-[57]0x, Benq DW[48]00A,

186

OptoRite DD020x, Lite-On LDW-[48]x1S,

187

as well as <A HREF="-RW/">nonplus</A> units such as

188

Pioneer DVR-x0[4567], LG GxA-40[248]0,

189

Toshiba SD-R[56]112, Panasonic UJ-811

190

and LF-D[35]1x...</TR>

191

</TABLE>

192

193

194

195

<TH>Q. <TH ALIGN="left">Is there a GUI front-end available for

196

dvd+rw-tools?

197

</TR>

198

199

<TD>A. <TD><A HREF="http://www.k3b.org/">K3b,</A> version 0.10

200

and later, and <A

201

HREF="http://ftp.gnome.org/pub/GNOME/sources/nautilus-cd-burner/">nautilus-cd-burner,</A>

202

version 0.5.1 and later, are both hiding growisofs behind their

203

pretty buttons and menus:-) Keep in mind that those are not

204

directly related to dvd+rw-tools development

205

effort and GUI users should turn elsewhere for end-user

206

support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for

207

GUI frontends...</TR>

208

</TABLE>

209

210

211

212

<TH>Q. <TH ALIGN="left">I don't run Linux. What are my options?

213

</TR>

214

215

<TD>A. <TD>Version 5.4 adds support for <A

216

HREF="http://www.mosha.net/05-dvdrw/dvdrw.shtml">OpenBSD</A>/NetBSD.

217

Version 5.6 adds support for Solaris 2.x <FONT

218

SIZE=-1>[<A HREF="solaris.com.html">commercial licensing</A>

219

terms for distribution on Solaris are to be settled with <A

220

HREF="http://www.inserve.se/">Inserve Technology</A>].

221

Version 5.8 features FreeBSD port(*)

222

contributed by Matthew Dillon, FreeBSD Development Team

223

alumnus. Hewlett-Packard Company has donated

224

HP-UX 11 support for

225

5.14(**). IRIX 6.x support appears in

226

5.19.

227

228

229

230

<TD>¡

231

<TD>Common usage tip! Whenever

232

separately available [and unless stated otherwise], do use

233

character-type device entry with dvd+rw-tools,

234

e.g. OpenBSD/NetBSD users should stick to <TT>/dev/<FONT

235

COLOR="red">rcdXc</TT>.</TR>

236

237

<TD>(*)

238

<TD>FreeBSD tip! If you have an IDE unit, <A

239

HREF="http://www.cuivre.fr.eu.org/~thomas/atapicam/">atapicam</A>

240

is your mantra! Secondly, if you have <TT>devfs</TT> mounted,

241

you might have to <A HREF="fdescfs.sh">mount</A>

242

<TT>fdescfs</TT> as well.</TR>

243

244

<TD>(**)

245

<TD>As of 5.14 HP-UX support was classified as

246

"initial." Version 5.18 in turn is the one which has

247

undergone <A HREF="tools/HP/">HP quality assurance</A> testing

248

and is delivered on <A HREF="http://www.software.hp.com/">HP

249

software depot</A>.</TR>

250

</TABLE>

251

</TR>

252

</TABLE>

253

254

<HR>

255

256

<H3>Foreword/Disclaimer</H3>

257

258

Given the absolute lack of initial support from

259

vendor(s) dvd+rw-tools arose from guesswork. There still is a couple of

260

fatal failures indicated by vendor-specific error codes (see Technical

261

Ramblings) and I haven't yet figured out the way around them in

262

kernel. User-land utilities on the other hand are

263

considered matured enough to be deployed in "production

264

environment."

265

266

As of May 2003 I've decided to advise users to

267

turn to <<A

268

HREF="mailto:cdwrite@other.debian.org">cdwrite@other.debian.org</A>>

269

on support matters. It's an open list, meaning that you don't have

270

to be <A HREF="http://lists.debian.org/cdwrite/">subscribed</A> to post

271

a problem report. List archives can be found at both <A

272

HREF="http://lists.debian.org/cdwrite/">subscribe page</A> and <A

273

HREF="http://www.mail-archive.com/cdwrite%40other.debian.org/">mail-archive.com</A>.

274

When submitting report, provide versioning information, exact

275

command line, exact output generated by the program and

276

complement it with dvd+rw-mediainfo output for

277

resulting recording. Do check couple of last <A

278

HREF="http://lists.debian.org/cdwrite/">archived months</A>, as the

279

issue might have been discussed recently. If you've chosen to

280

contact me personally and haven't heard back within a week or so, then

281

you most likely overlooked something on this page. Please read it more

282

attentively<A HREF="keys.txt">...</A>

283

284

Special thanks for hardware donations [in

285

chronological order]:

286

287

<A HREF="http://www.inserve.se/"><IMG SRC="inserve.gif"

288

ALT="Inserve Technology" BORDER=0></A>

289

290

<A HREF="http://www.hp.com/"><IMG SRC="hp.gif"

291

ALT="HP" BORDER=0></A>

292

293

<A HREF="http://www.linuxfund.org/"><IMG SRC="linuxfund.gif"

294

ALT="LinuxFund" BORDER=0></A>

295

296

297

298

<H3>Tutorial</H3>

299

300

301

302

<UL>

303

304

<LI>If your burner unit is managed by some

305

Linux(*) removable media

306

automounting/autoplaying facility, such as autofs, supermount,

307

magicdev, autorun or similar, take it out of its control! I

308

can't help you with the latter, check your system documentation (such

309

as google perhaps:-) for specific instructions. <FONT

310

COLOR="brown">Failure to take your unit out of

311

Linux(*) automounting/autoplaying facility

312

control can result in busted recording, a coaster! At the

313

very least you have to make sure your unit is not automounted during

314

recordings. <!-- Linux kernel should have/implement "open for

315

exclusive use," but it doesn't. Therefore the trouble... --->

316

317

318

319

<TD>(*)

320

<TD>dvd+rw-tools support Solaris volume manager and

321

IRIX mediad in more gracious manner and it's safe to leave recorder

322

under their control.</TR>

323

</TABLE>

324

325

<LI>Remember to consult <A

326

HREF="hcn.html">Hardware Compatibility Notes</A> for possible

327

caveats or vendor-specific instructions for your unit. Well, such

328

reminder belongs at the end of tutorial, but I consider it important

329

enough to bring it up already here:-)

330

331

<LI>If you have an IDE unit and run 2.4.x

332

kernel, you most likely want to "route" it through ide-scsi

333

emulation layer by either:

334

335

<UL>

336

<LI>passing "<TT>hdX=ide-scsi</TT>"

337

argument to kernel;

338

<LI>appending following lines to your /etc/modules.conf:

339

340

<PRE>options ide-cd ignore=hdX

341

pre-install sg modprobe ide-scsi

342

pre-install sr_mod modprobe ide-scsi

343

pre-install ide-scsi modprobe ide-cd

344

</PRE></BLOCKQUOTE>

345

</UL>

346

347

Keep in mind that once hdX

348

is routed through ide-scsi, you can no longer refer to <TT>/dev/hd<FONT

349

COLOR="red">X</TT>(*), but to corresponding

350

<TT>/dev/scdN</TT> only.

351

352

353

354

<TD>(*)

355

<TD>well, except as in <TT>hdparm -d [0|1] /dev/hd<FONT

356

COLOR="red">X</TT>. As for DMA settings. Several users of

357

NEC[-based] units have reported that their systems crash during DVD

358

recording. The problem appears to be related to DMA settings, at least

359

switching it off reportedly helps. The problem might be specific to

360

some IDE chipsets...

361

</TR>

362

</TABLE>

363

364

<LI>If you have an external unit, just get

365

it working as CD-ROM first. I myself have no personal experience

366

whatsoever with <A HREF="http://www.linux-usb.org/">USB</A> or <A

367

HREF="http://www.linux1394.org/">IEEE1394/Firewire</A> storage devices

368

of any kind and have to direct you elsewhere for specific instructions.

369

I however am confident that if you manage to get your drive working

370

reliably as CD-ROM and CD-R[W] burner, then you won't

371

have any troubles with DVD recording part. USB connected drives were

372

reported to be working fine since eternity. Firewire connected drives

373

in turn were reported to fail miserably under 2.4.18. The failure

374

didn't seem to be DVD+RW related as it reportedly failed burning even

375

CD-R media. Firewire support was substantially revamped in 2.4.19, and

376

dvd+rw-tools were reported to work with this and later kernels.

377

378

<LI>If you're running 2.4.19 or .20, consider

379

applying <A HREF="sg-2.4.19.patch">this drivers/scsi/sg.c patch</A>.

380

The bug is fixed in .21. I write "consider" and not

381

"do" for the following reasons:

382

383

<UL>

384

<LI>dvd+rw-tools are not affected by this bug (as they don't use SG_IO

385

interface), cdrecord [potentially] is;

386

<LI>I however haven't actually experienced the problem with cdrecord

387

(maybe yet, kernel could have managed to keep buffers neatly aligned

388

while talking to cdrecord those times I tried), it was VMware that has

389

failed miserably on me;

390

</UL>

391

392

As of version 5.6 dvd+rw-tools add support for SG_IO

393

pass-through or in other words support for Linux 2>=5[.43],

394

where "generic" SCSI interface can be bypassed by issuing

395

SG_IO ioctl directly against block device, such as <TT>/dev/hd<FONT

396

COLOR="red">X</TT>. I wish it worked without need for <A

397

HREF="http://marc.theaimsgroup.com/?t=105410790500005&r=1&w=2">interim</A>

398

patches <A HREF="ide-cd-2.5.69.patch">#1</A> and <A

399

HREF="ide-cd-2.5.69.+patch">#2</A>, (the latter is relative to

400

2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in

401

"<A

402

HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=105787192005635&w=2">last

403

minute</A>" prior first 2.6 cut. As for 2.6 in more general sense.

404

As you can imagine this new interface renders ide-scsi layer

405

superfluous and "the[ir] official plan™" is to scrap

406

it. I'm not really fond of the idea, but not for /dev/sg* account. I

407

mean I [personally] would prefer to keep ide-scsi and use SG_IO

408

pass-through with <TT>/dev/scdN</TT>, rather than with

409

<TT>/dev/hdX</TT>:-)

410

411

<LI>Download, unpack and compile the <A

412

HREF="tools/?M=A">the tool-chain</A>. To build the thing do pick the

413

.tar.gz archive, which contains Makefile as well as .spec file. You

414

will need both C and C++ compilers installed. Separate

415

source code files found in the <A HREF="tools/?M=A">download catalog</A>

416

are provided mainly for on-line reference purposes (such as <A

417

HREF="tools/growisofs.c">revision history</A>:-).

418

419

If your Linux kernel supports multiple ABIs (e.g.

420

Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as

421

Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you

422

compile for native 64-bit ABI (which can normally be done with

423

'<TT>make TARGET_ARCH=-m64</TT>'). The problem here is that 64-bit

424

kernel has to explicitly convert ioctl structures passed by 32-bit

425

applications and apparently it does really lousy job when it comes to

426

CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.

427

428

<LI>If you have 1st generation drive (Ricoh

429

MP5120A and derivatives, see <A

430

HREF="http://www.dvdplusrw.org/">dvdplusrw.org</A> for generation

431

listings), do consider upgrading your firmware (see <A

432

HREF="http://ext.ricoh.co.jp/dvd/asia/support/download/mp5120a/">Ricoh</A>

433

page for latest version information). Fixed bug descriptions are vague,

434

but at the very least after upgrade to 1.34 I could no longer reproduce

435

infrequent "random positioning errors" when reading a

436

file system with a lot of small files. 1.34 adds support for Verbatim

437

media and 1.37 apparently for Memorex. Version 1.37 also implements a

438

secret vendor-specific command which <A HREF="#booktype">reportedly

439

improves compatibility</A> with a number of DVD-ROM drives (more about

440

this matter in Technical Ramblings). <!--So for whatever it's worth do

441

consider upgrading...-->

442

443

Several 2nd generation unit (<A

444

HREF="http://ext.ricoh.co.jp/dvd/asia/support/download/mp5125a/">Ricoh

445

MP5125A</A> and derivatives) users have reported that their systems

446

lock up the while recording DVD+R, but not DVD+RW. I myself have never

447

experienced anything similar, but firmware upgrade did help those who

448

has suffered from this. So that apparently even 2nd generation users

449

should be considering firmware upgrade. Firmware upgrade is actually

450

required if you want to burn 4x media in your 2nd generation unit.

451

Well, it will still burn it at 2.4x, but without firmware upgrade you

452

should expect deplorable results.

453

454

As new media products and brands are being

455

introduced to the market all the time, it apparently pays off to

456

periodically check for firmware updates. It's not as simple as

457

"1st" vs. "2nd generation" units anymore, so turn

458

to your vendor to be sure. Special note for HP users. HP no longer

459

posts firmware updates on a web-page. Instead they let some Windows

460

auto-update gizmo to pick firmware updates among

461

<TT>dvd[1-4]00*.exe</TT> files in <A

462

HREF="ftp://ftp.hp.com/pub/information_storage/software/">their FTP

463

directory</A>, so that readers of this page tend to miss them...

464

465

<LI>Formatting the DVD+RW media. Virgin

466

DVD+RW media needs to be initally formatted prior usage. Once again,

467

only virgin DVD+RW media needs to be formatted. As of version

468

5.10 growisofs detects blanks and applies initial formatting procedure

469

automatically. Otherwise same effect can be achieved by passing the

470

device name, e.g. <TT>/dev/scd0</TT>, as an argument to <A

471

HREF="tools/dvd+rw-format.cpp">dvd+rw-format</A>. To make formatting

472

process reasonably fast, less than 1 minute, the media gets formatted

473

only partially, as you can notice by observing a progress indicator

474

displayed by dvd+rw-format. The final indicator value varies from

475

firmware to firmware, values as low as 1.6% were observed. But it does

476

not mean that you can only write that little. The unit keeps formatting

477

transparently, as you add more data. Oh! Do keep in mind that

478

DVD capacity of 4.7GB are salesman's GB, i.e. 10003 and

479

not 10243.

480

481

It was observed that excessive reformats can render

482

media unusable already after 10-20 reformats. It appears to be a

483

firmware deficiency, not some common media defect [at least it was

484

perfectly possible to salvage the media in a unit of different brand],

485

but I don't recommend [enforced] reformat in either case. Note that

486

DVD+RW re-formatting procedure does not substitute for blanking.

487

If you want to nullify the media, e.g. for privacy reasons, do it

488

explicitly with '<TT>growisofs -Z /dev/scd<FONT

489

COLOR="red">N=/dev/zero</TT>'. Otherwise just write over

490

previous recording as it simply wasn't there, no re-formatting is

491

required.

492

493

DVD+R media does not require any formatting

494

procedure applied and is ready to use out-of-the-box. Apparently, a

495

reminder that 1st generation units (Ricoh MP5120A and derivatives)

496

are not capable of burning DVD+R is needed.

497

498

<A NAME="growisofs"></A><LI>Burning with <A

499

HREF="tools/growisofs.c">growisofs</A>. There is hardly a need for

500

manual for growisofs. In a nutshell growisofs just passes all command

501

line arguments to mkisofs and dumps its output directly onto the media.

502

The first part means that you basically can [well, should]

503

consult <A HREF="mkisofs.8.html">mkisofs manual page</A> and

504

accompanying reference documentation (including multi-session related

505

section[s]) and the second part means that you shouldn't expect an

506

ISO-image on the standard output (nor make sure you have enough free

507

temporary storage<TT>:-)</TT>. Differences from mkisofs command line

508

are:

509

510

<UL>

511

<LI>you may not use -o option;

512

<LI>you don't have to specify -C option, growisofs will construct one

513

for you;

514

<LI>there is internal -Z option for initial session recording, this

515

substitutes for originally suggested 'mkisofs | dd of=/dev/scd0';

516

</UL>

517

518

Otherwise everything that applies to

519

[multi-session] mastering with mkisofs applies to growisofs as well. For

520

example just like with mkisofs you should make a note on which options

521

you used to master the initial "session" with and stick to

522

them, e.g.:

523

524

525

growisofs -Z /dev/scd0 -R -J /some/files

526

growisofs -M /dev/scd0 -R -J /more/files

527

</PRE></BLOCKQUOTE>

528

529

Oh! Do make sure you have at least mkisofs <FONT

530

COLOR="red">1.14 on your $PATH (mkisofs 1.14 is part of cdrtools

531

1.10). If you consider passing <TT>/same/files</TT> as argument, or in

532

other words consider deploying growisofs for incremental

533

multi-session backups, then you shall find <A

534

HREF="mkisofs-2.01a16-root.diff">this '-old-root' extension</A> to

535

mkisofs 2<A

536

HREF="mkisofs-2.0-root.diff">.</A>0-2.01 simply indispensable.

537

The idea and implementation by <A

538

HREF="http://home.pages.de/~ohly/#mkisofs-root">Patrick Ohly</A> is to

539

"graft" recording sessions as separate directories. Each

540

backup increment/directory is ment to contain both updated files and

541

references to previously backed up ones, which facilitates

542

comparison between increments as well as fine-graded restore.

543

544

In addition to intuitive -Z interpretation,

545

growisofs [version 3.3 and later] recognizes special form of -Z command

546

line option which permits burning of arbitrary pre-mastered images. The

547

"magic" command is:

548

549

550

growisofs -Z /dev/scd0=image.iso

551

</PRE></BLOCKQUOTE>

552

553

where <TT>image.iso</TT> represents an arbitrary

554

object in the file system, such as file, named pipe or device

555

entry. No, nothing is "growing" here and command name is

556

counter-intuitive in this particular context. And here is even less

557

intuitive<TT>:-)</TT> If you wish to burn down output generated by an

558

arbitrary program, you can use:

559

560

561

dumpsomething | growisofs -Z /dev/scd0=/dev/fd/0

562

</PRE></BLOCKQUOTE>

563

564

Burning DVD±R implies extra limitations:

565

566

<UL>

567

568

<LI>Needless to say that you have only one shot with -Z

569

option<TT>:-)</TT>

570

571

<!---

572

<LI>Apparently media needs to be manually reloaded [ejected and pushed

573

back again] after every burning session (well, if you haven't patched

574

the kernel that is<TT>:-)</TT>

575

--->

576

577

<LI>Unlike DVD+RW, DVD±R media does have notion of multiple

578

sessions. However! Not all legacy units can "see"

579

beyond the first one. Few DVD-ROM units are capable of DVD-R

580

multi-border playback, even fewer support DVD+R multi-sessioning. In

581

other words your DVD burner might be the only unit in your vicinity

582

capable to access data added at different occasions.

583

584

<LI>Even if your DVD unit does "sense" multiple sessions,

585

Linux kernel sometimes fails to pull that information from the

586

drive<TT>:-(</TT> Till the problem is looked into and resolved you can

587

work it around by reloading corresponding driver, most likely

588

'<TT>rmmod sr_mod</TT>'.

589

590

<LI>If you go for DVD±R multi-sessioning, you have to use

591

mkisofs from <A HREF="ftp://ftp.berlios.de/pub/cdrecord/">cdrtools-2.0

592

or later</A> or apply <A HREF="multi.diff">this patch</A>. </UL>

593

594

And once again, do keep in mind that 4.7GB are

595

salesman's GB, i.e. 10003 and not 10243. If

596

translated to "real" GB, DVD±R[W]

597

capacity is not larger than 4.4GB! It should also be noted that earlier

598

growisofs versions did not check if there is enough space on media to

599

accommodate the data set to be burned, meaning that it was your sole

600

responsibility to make sure "overburn" condition is not

601

raised. As of version 5.2 growisofs performs the necessary checks

602

for you and refuses to start recording if "overburn"

603

condition appears to be unavoidable. This behaviour can be overridden

604

with <TT>-overburn</TT> command-line option.

605

606

<LI>If you're satisfied with growisofs, then you

607

should just proceed to <A HREF="#compat">the next chapter</A>

608

and abstain from applying the optional 2.4.x kernel patch. If

609

you haven't stopped reading beyond this line, <A

610

HREF="linux-2.4.patch">download</A> the patch, apply it, rebuild the

611

kernel or modules and re-install (kernel or cdrom.o and sr_mod.o

612

modules, whichever appropriate), but don't ask me <A

613

HREF="http://www.linuxhq.com/patch-howto.html">how</A>. As you could

614

have noticed, patch targets SCSI CD-ROM module. This means that you

615

have to "route" your IDE unit through ide-scsi to get this one

616

working. To see it in action, insert formatted DVD+RW media and try to

617

access it, '<TT>dd if=/dev/scdN count=0</TT>'

618

would do. Then verify that kernel logs "<TT>sr<FONT

619

COLOR="red">N: mmc-3 profile: 1Ah</TT>&quot. You should now be

620

able to '<TT>mkisofs -pad . | dd of=/dev/scdN

621

obs=32k</TT>' or even '<TT>mke2fs -b 2048 /dev/scd<FONT

622

COLOR="red">N</TT>' and observe kernel logging "<TT>sr<FONT

623

COLOR="red">N: dirty DVD+RW media</TT>.&quot

624

625

<!--If you have previous patch version applied, then you

626

have to back it out first. The simplest way is probably to restore

627

<TT>drivers/scsi/sr*.[ch]</TT> and <TT>drivers/cdrom/cdrom.c</TT> from

628

your original Linux source code ditribution.-->

629

630

Linux 2.6 DVD+RW kernel support is planned in

631

line with DVD+MRW kernel support. This [unfortunately] means that

632

industry has to deliver a DVD+MRW capable unit first. Yes, the last

633

sentence means that despite all the promises, there are no such units

634

available on the market yet. As of the 1st of August 2003, Ricoh MP5240A,

635

Philips DVDRW416K or BenQ DW400A do not actually implement

636

Mt.Rainier/EasyWrite support. It remains to be seen if they will offer

637

it in form of firmware upgrade. In either case, the [original] project

638

goal is not only read-write support for DVD+[M]RW capable units

639

themselves, but even playback of DVD+MRW formatted media in legacy

640

DVD-ROM units (when defect list will be read and interpreted by OS

641

software in opposite to Mt.Rainier firmware).

642

643

<A NAME="udf"><LI></A>Even though kernel now

644

permits to build and mount arbitrary file system, there is one thing you

645

must keep in mind before you just proceed, no matter how

646

tempting it might appear.

647

648

As you might know DVD+RW media can sustain only

649

around 1000 overwrites. The thing about fully fledged file systems

650

is that every read [or tight bunch of 'em] is accompanied by

651

corresponding i-node update or in other words a write! Now, let's say

652

you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This

653

gives you a 100 days lifetime on your mountpoint and therefore media.

654

Not really much, huh? So do use <TT>noatime</TT> mount option with

655

DVD+RW media or have it mounted read-only most of the time. However!

656

Every read-write mount "costs" a super-block update. So that

657

if you remount the media say 3 times a day, it would last for about a

658

year [<A

659

HREF="http://people.mandrakesoft.com/~quintela/supermount/">supermount</A>

660

would exhaust the "budget" way sooner]... Defect management

661

[in firmware, a.k.a. <A

662

HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier</A>,

663

or at file system level] would improve the situation, but ideally

664

file system driver should definitely refrain from modifying the

665

super-block [marking it dirty] if nothing was actually written since

666

last mount. Given the development status of <A

667

HREF="http://sourceforge.net/projects/linux-udf/">Linux UDF</A> the

668

chances for seeing the latter implemented [for UDF] are more than just

669

conceivable. The request is already filed and even possible solution is

670

being discussed. But why not give UDF a shot already then? By default

671

UDF write support is unfortunately disabled and you might have to

672

reconfigure the kernel and rebuild modules. Alternatively [my preferred

673

option actually] fetch the code at <A

674

HREF="http://sourceforge.net/projects/linux-udf/">SourceForge</A> and

675

build the module separately. Of course you will have to fetch and build

676

udftools as well. But once it's done just type:

677

678

679

mkudffs --spartable=2 --media-type=cdrw /dev/scdN

680

mount -o rw,noatime /dev/scdN /mnt/cdrom

681

</PRE></BLOCKQUOTE>

682

683

<TT>mkudffs</TT> command line options were suggested

684

by UDF maintainer, Ben Fennema.

685

686

<LI>Performance optimization. This paragraph

687

applies only if you've patched the kernel. As some of you might

688

remember the original recommendation was "do use <TT>obs=32k</TT>

689

for optimal performance." Well, it was rather naive of me to say

690

so, as common block device layer completely reorganizes the

691

stream so that '<TT>>/dev/scd0</TT>' is as good as '<TT>|dd

692

of=/dev/scd0 obs=32k</TT>'. It should also be noted that dumping to

693

/dev/scd0 puts quite a pressure on VM subsystem, as the data passes

694

through block buffer cache. To minimize the pressure and improve

695

overall system performance bind the cdrom device to a raw device, e.g.

696

'<TT>raw /dev/raw/raw1 /dev/scd0</TT>', growisofs will locate and use

697

it automatically. obs=32k makes perfect sense with /dev/raw devices,

698

but dd (as well as most other programs, e.g. tar) won't work as

699

/dev/raw expects specifically aligned buffer... As temporary

700

workaround, just to get you going so that you can start figuring things

701

out, consider <A

702

HREF="http://fy.chalmers.se/~appro/LD_*-gallery/index.html?aligned_io#aligned_io">this

703

"hacklet"</A>...

704

705

</UL>

706

707

708

709

<H3>Compatibility: caveat lector</H3>

710

711

712

713

This paragraph discusses "DVD-ROM

714

compatibility," or playability of already recorded media in legacy

715

units. Blank media compatibility issues, or cases such as failure to

716

start or fulfill recording because of poor media support by burner

717

firmware, are beyond the current scope. Turn to your vendor for list of

718

supported media and/or to the <A

719

HREF="mailto:cdwrite@other.debian.org">public</A> to share your

720

experience.

721

722

In order to optimize seek times DVD[-ROM] players

723

calibrate their mechanics every time the media is loaded by sliding

724

the optical head some place, picking up the signal and noting the

725

physical block address underneath the lens. In order for this procedure

726

to work with re-writable/recordable media, that particular spot has to

727

be written to [or de-iced in DVD+RW case]. Some units slide the head to

728

30mm [radial] to calibrate, some to 35mm. In order to keep such players

729

"happy," make sure that at least 1GB is written [before you

730

attempt to mount it in DVD-ROM unit].

731

732

Other units attempt to seek to lead-out [or vicinity

733

of it] for calibration purposes. Now the catch is that it's perfectly

734

possible to produce a DVD+RW disc without lead-out. Most notably media

735

initially formatted with dvd+rw-format [apparently] doesn't have any

736

lead-out, not to mention that practically whole surface remains virgin.

737

If you fail to mount/play DVD+RW media, attempt to

738

739

<BLOCKQUOTE><PRE>dvd+rw-format -lead-out /dev/scd<FONT

740

COLOR="red">N</PRE></BLOCKQUOTE>

741

742

which relocates the lead-out next to outermost

743

written sector as well as makes sure there is no virgin surface before

744

it. Previously written data is not affected by this operation.

745

<!-- "Should" is a reminder of the project status,

746

"experience gathering." I mean the best I can do is to state

747

that my hp dvd200i unit doesn't wipe any data when relocating the

748

lead-out.-->

749

750

Then non-finalized DVD+R and Sequential DVD-R[W]

751

discs don't have lead-out either(*). If you fail to

752

mount/play DVD+R media and wish to sacrifice the remaining space for

753

immediate compatibility, just fill the media up(**).

754

Alternatively if you master volume in a single take and don't plan to

755

use it for multi-sessioning(***), you have the option to

756

invoke growisofs with <TT>-dvd-compat</TT> option and cut the real

757

lead-out directly after the first session.

758

759

760

761

762

<TD>(*)

763

<TD>Well, there are lead-outs at the session edges, but

764

the problem is that "End Physical Sector Number of Data Area"

765

field in "Control Data Zone" of the lead-in contains address

766

of the largest media sector, which makes affected DVD[-ROM] players

767

calibrate at the outermost edge instead of the first session. Actually

768

I fail to understand why don't they burn the address of last sector of

769

the first session in the lead-in even on multi-session discs...

770

</TR>

771

772

773

<TD>(**)

774

<TD>But beware the <A HREF="#isofs4gb">4GB limit</A>!

775

If 4GB is already an issue, or if you don't feel like throwing

776

unrelated data on the media in question, then invoke '<TT>growisofs

777

-M /dev/scd0<FONT

778

COLOR="red">=/dev/zero</TT>' (supported by 5.6 and later).

779

Alternative is to re-master the whole volume, naturally with

780

<TT>-dvd-compat</TT> option.

781

<!-- then the easiest way is to create couple of holey

782

files with '<TT>touch hugeM.void</TT>' and

783

'<TT>perl -e 'truncate ("huge<FONT

784

COLOR="red">M.void", 0x7ffffffe)'</TT>', and finally to

785

'<TT>growisofs -overburn -M /dev/scdN ...

786

huge*.void</TT>'. Otherwise you might have to re-master the volume with

787

<TT>-dvd-compat</TT> option.--></TR>

788

789

790

<TD>(***)

791

<TD>E.g. when mastering DVD-Video disc:-) Note that

792

<TT>-dvd-video</TT> option [passed to mkisofs] engages

793

<TT>-dvd-compat</TT> automatically.</TR>

794

</TABLE>

795

796

797

798

Then we have logical format compatibility

799

issue(s). Probably the very ground for all the controversy around

800

DVD+RW, rather around DVD+RW media not being playable in a whole range

801

of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even

802

claiming that they deliberately block playback. But the fact is that

803

format specifications don't explicitly say that unrecognized format

804

[designated by "Book Type" field in "Control Data

805

Zone" of the lead-in] should be treated as DVD-ROM and [in my

806

opinion] it was rather naive of them to claim and expect that the media

807

will be playable in "virtually all players." This deficiency

808

was recognized by practically all DVD+RW vendors [well, apparently by

809

"traditional" DVD+RW vendors and not "latest

810

generation" vendors such as Sony, NEC, TDK...] and a <A

811

HREF="tools/dvd+rw-booktype.cpp">secret</A> vendor-specific command

812

manipulating this "Book Type" field was implemented. So if

813

you fail to mount/play DVD+RW media, you might have an option to

814

815

<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -media /dev/scd<FONT

816

COLOR="red">N</PRE></BLOCKQUOTE>

817

818

Once again. Not all vendors support this and you

819

can't expect this utility to work with all recorders.

820

821

It's naturally not possible to manipulate the

822

"Book Type" field on DVD+R media, that is not after the

823

lead-in is written [which takes place at the moment the first session

824

gets closed]. But it might be possible to control how it [lead-in] is

825

going to be branded by programming the drive in advance:

826

827

<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -unit+r /dev/scd<FONT

828

COLOR="red">N</PRE></BLOCKQUOTE>

829

830

Meaning that if you fail to play DVD+R media, you

831

can attempt to burn another disc with more appropriate unit settings.

832

For more background information about dvd+rw-booktype, see <A

833

HREF="http://www.dvdplusrw.org/resources/bitsettings.html">"Compatibility

834

Bitsettings" article at dvdplusrw.org</A>.

835

836

There [potentially] are other logical

837

DVD+RW(*) format incompatibilities, but the "Book

838

Type" issue discussed above is the only one "officially"

839

recognized. Well, it's actually understandable as it's the only one

840

that can be recognized and addressed by a DVD+RW vendor alone.

841

Recognition of other incompatibilities would require cooperation from

842

DVD[-ROM] player vendors and that's something they apparently are not

843

willing to show referring to the fact that DVD+RW format is not

844

approved [and apparently never will be] by <A

845

HREF="http://www.dvdforum.org/">DVD Forum</A>(**).

846

847

848

849

850

<TD>(*)

851

<TD>Finalized DVD+R media branded with DVD-ROM

852

"Book Type" is virtually identical to DVD-ROM.</TR>

853

854

<TD>(**)

855

<TD>To which I say "so what?" DVD Forum is an

856

alliance of manufacturers just like DVD+RW Alliance is. It [or any

857

other party for that matter] has no authority to deny a technology

858

development initiative.</TR>

859

</TABLE>

860

861

862

863

Finally there is a physical incompatibility issue.

864

They claim that there are optical pick-ups out there not being capable

865

to decode the track because of low reflectivity of DVD+RW media

866

surface. I write "they claim," because in the lack of

867

cooperation from DVD[-ROM] vendors it's not possible to distinguish

868

physical from logical format incompatibility, which I find important to

869

tell apart in order to make sure at least logical format

870

incompatibility issues don't persist over time. It might be as trivial

871

as following. As you surely know [already], DVD+RW has same

872

reflectivity as dual-layer DVD-ROM. Now the catch is that the linear

873

pit density in turn is same as of single-layer one. Meaning that if

874

player makes assumptions about linear pit density based on

875

reflectivity, then it won't be able to trace the track... But either

876

way, there is very little you can do about this one, but to try another

877

player...

878

879

<HR>

880

881

<H3>Technical Ramblings</H3>

882

883

884

885

<A NAME="isofs4gb"><IMG SRC="isofs4gb.gif" WIDTH=144 HEIGHT=315

886

ALIGN="RIGHT"></A>

887

888

As for multi-session ISO9660 [DVD]

889

recordings! Unfortunately, Linux ISOFS implementation has certain

890

deficiency which limits interoperability of such recordings. In order

891

to understand it, have a look at sample ISO9660 layout to the right...

892

Now, the problem is that isofs i-nodes(*) are 32 bits wide

893

(on a 32-bit Linux) and represent offsets of corresponding directory

894

entries (light-greens), byte offsets from the beginning of media. This

895

means that no directory (green areas) may cross 4GB boundary without

896

being effectively corrupted<TT>:-(</TT> It should be noted that in

897

reality it's a bit better than it looks on the picture, as mkisofs

898

collects all the directories in the beginning of any particular session

899

(there normally are no blues between greens). The first session

900

is therefore never subject to i-node wrap-around, but not the

901

subsequent ones! Once again, files

902

themselves may reside beyond the 4GB

903

boundary, but not the directories, in

904

particular not in further sessions. Having noted that directory entries

905

are actually specified to start at even offsets, I figured that

906

it's <A HREF="isofs-2.4.patch">perfectly possible</A> to

907

"stretch" the limit to 8GB. But in order to assure the

908

maximum interoperability, you should not let any session

909

start past 4GB minus space required for directory

910

structures, e.g. if the last session is to fill the media up, it

911

has to be >400MB. As of version 5.3 growisofs refuses to append

912

a new session beyond 4GB-40MB limit, where 40MB is pretty much

913

arbitrary chosen large value, large for directory catalogs that is. Yet

914

it doesn't actually guarantee that you can't suffer from i-node

915

wrap-around. The <A HREF="isofs-2.4.patch">fs/isofs kernel patch</A> is

916

addressed to those who have actually ran into the problem and have to

917

salvage the data.

918

919

920

921

<TD>(*)

922

<TD>i-node is a number uniquely identifying a single

923

file in a file system

924

</TR>

925

</TABLE>

926

927

928

929

Why media reload is performed after every

930

recording with growisofs? Well, it's performed only if you didn't

931

patch the kernel:-) But no, I'm not insisting on patching the kernel!

932

All I'm saying is that in the lack of kernel support, media reload is

933

performed for the following reason. In order to optimize file access

934

kernel maintains so called block cache, so that repetitive requests for

935

same data are met directly from memory and don't result in multiple

936

physical I/O. Now the catch is that block cache layer remains totally

937

unaware of growisofs activities, growisofs bypasses the block

938

cache. This means that block cache inevitably becomes out of sync,

939

which in turn might appear to you as corrupted data. Media reload is

940

performed to flush/resync the block cache.

941

942

943

944

What does [kernel] "DVD+RW support"

945

really mean? Even though DVD+RW has no notion of [multiple]

946

sessions, to ensure compatibility with DVD-ROM it's essential to issue

947

"CLOSE TRACK/SESSION (5Bh)" <A

948

HREF="http://www.t10.org/scsi-3.htm">MMC</A> command to

949

terminate/suspend background formatting (if any in progress) whenever

950

you intend to eject the media or simply stop writing and want better

951

read performance (e.g. remount file system read-only). This is what the

952

patch is basically about: noting when/if media was written to and

953

"finalizing" at unlock door.

954

955

Secondly, whenever you employ fully fledged

956

file system, I/O requests get inevitably fragmented.

957

"Fragmented" means following. Even though you can address the

958

data with 2KB granularity, it [data] is physically laid out in 32KB

959

chunks. This in turn means that for example writing of 2KB block

960

involves reading of 32KB chunk, replacing corresponding 2KB and writing

961

down of modified 32KB chunk. "Fragmented requests" are those

962

that are smaller than 32KB or/and cross the modulus 32KB boundaries. In

963

order to optimize the process certain caching algorithm is implemented

964

in unit's firmware. Obviously it can't adequately meet all possible

965

situations. And so in such unfortunate situations the drive apparently

966

stops processing I/O requests returning "COMMAND SEQUENCE ERROR

967

(2Ch)" ASC. This is the second essential of "DVD+RW

968

support," namely injecting of "SYNCHRONIZE CACHE (35h)"

969

MMC command in reply to the error condition in question. The command

970

flushes the cached buffers which makes it possible to resume the data

971

flow.

972

973

Unfortunately the above paragraph doesn't

974

seem to apply to the 1st generation drives, Ricoh MP5120A and

975

derivatives<TT>:-(</TT> "SYNCHRONIZE CACHE (35h)" doesn't

976

seem to be sufficient and the unit keeps replying with "COMMAND

977

SEQUENCE ERROR (2Ch)" going into end-less loop. This makes it

978

impossible to deploy arbitrary file system. I'm open for

979

suggestions... Meanwhile the I've chosen to simply suspend I/O till the

980

media is unmounted. Even 2nd gen unit were reported to exhibit similar

981

[but not the same] behaviour under apparently extremely rare

982

circumstances. At least I failed to reproduce the problem... The problem

983

reportedly disappears with firmware upgrade...

984

985

Then some [most?] of post-2nd gen units, from

986

most vendors, seem to not bother about complying with

987

DVD+RW specification, "true random write with 2KB

988

granularity" part in particular. Instead they apparently expect

989

host to apply procedure pretty much equivalent to DVD-RW

990

Restricted Overwrite. To be more specific host seems to be expected to

991

coalesce 2KB requests and perform aligned writes at native DVD ECC

992

blocksize, which is 32KB. Formally this should not be required, but

993

it's the reality of marketplace:-(

994

995

This one really beats me. Sometimes the unit

996

simply stops writing signaling a vendor specific positioning error,

997

03h/15h/82h to be specific. Especially if the media is newly formatted.

998

Couple of work theories. One is that block buffer cache reorders

999

requests so that they are not sequential anymore, "FLUSH

1000

CACHE" might do the trick. Another one is that under

1001

"underrun" condition background formatting kicks off and has

1002

to be explicitly stopped. "Underrun" is in quotes because

1003

the unit is supposed to handle temporary data stream outages

1004

gracefully. If you run into this (you most likely will), try to

1005

complement growisofs command line with [undocumented]

1006

<TT>-poor-man</TT> option (which has to be first in the command line).

1007

This option eliminates request reorders and minimizes possibility for

1008

"underrun" condition (by releasing the pressure off VM

1009

subsystem).

1010

1011

1012

1013

The original idea was to implement DVD+RW support in

1014

drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private

1015

"writeable" flag controlling the ability to issue WRITE

1016

commands. The flag is impossible to reach for from the Unified CD-ROM

1017

driver. But why am I talking about SCSI when there are only IDE units

1018

out there (at least for the time being)? Well, as you most likely want

1019

to occasionally burn even CD-R[W] with cdrecord you want it to go

1020

through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM

1021

driver is the one to aim for even for DVD+RW.

1022

1023

Unfortunately it was not possible to implement it

1024

completely in sr_mod.o<TT>:-(</TT> Minor drivers/cdrom/cdrom.c

1025

modification was required to sense the media before decision about

1026

whether or not to permit write open. That's because DVD+RW drives are

1027

morphing their behaviour after currently mounted media and it's

1028

essential to identify newly inserted media.

1029

1030

Special comment about "what a dirty

1031

hack!!!" To my great surprise it turned out that time-out value you

1032

pass in cdrom_generic_command is simply ignored and time-out is set to

1033

pre-compiled value of 30 seconds. Unfortunately it's way too low for

1034

formatting purposes and I had to do something about it. Alternative to

1035

"the dirty hack" was to add another argument to sr_do_ioctl

1036

and modify all the calls to it... I've chosen to take over those 31

1037

unused bits from the "quiet" argument instead of modifying

1038

all the calls (too boring).

1039

1040

But even if time-out value passed down to kernel

1041

(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into

1042

consideration, it's apparently not interpreted as user-land code

1043

expects it to. As I figured... There is no documentation on

1044

CDROM_SEND_PACKET, but following the common sense most programmers

1045

(including myself:-) expect it to be interpreted in at least

1046

platform-independent manner, such as milliseconds maybe? SG_IO timeout

1047

in turn is <A

1048

HREF="http://www.torque.net/sg/p/sg_v3_ho.html#AEN215">documented</A>

1049

to be measured in milliseconds... Neither of this holds true! Kernel

1050

treats these values as "jiffies," which is a

1051

platform-dependent value representing time elapsed between timer

1052

interrupts. But if we attempt to send down "jiffies," it

1053

might turn out wrong too [at least for the moment of this writing]. The

1054

catch is that [IA-32] kernel developers figured it's cool to shorten

1055

"jiffy," but didn't care to provide user-land with actual

1056

value (well, not of actual interest, too much legacy code to deal with)

1057

nor <A HREF="scsi_ioctl-2.5.69.patch">scale</A> timeouts

1058

accordingly in respect to the legacy value of 10ms.

1059

1060

There is another kernel "deficiency" I ran

1061

into while working on the (original version of) dvd+rw-format utility.

1062

The drive provides background formatting progress status, but

1063

unfortunately it's impossible to access it. That's because progress

1064

counter is returned [in reply to "TEST UNIT READY"] as

1065

"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense

1066

bytes but with "GOOD" status. Apparently any sense data with

1067

"GOOD" status is discarded by the common SCSI layer.

1068

1069

<!--

1070

As you might have noticed the time-out value for

1071

"CLOSE SESSION" is 3000 seconds. Does it really take that

1072

long? It might... Disappointed? Don't be! It might happen only

1073

when reformatting used media. Formatting of the blank

1074

media doesn't take longer than a couple of minutes. Reformatting

1075

in turn takes as long as it takes to nullify whatever you had on the

1076

media which requires corresponding time-outs. But do you have to

1077

reformat? Well, only if media contains sensitive data, the new data set

1078

is smaller than the current one and (for some reason) will be easier

1079

for potentially rival party to get hold of it (in other words when

1080

there is a risk for sensitive data to get exposed). Another reason is

1081

when you want to reuse the media as a master copy for DVD-ROM

1082

manufacturing and want formatted capacity to reflect data set size.

1083

Otherwise there is no reason to reformat and as long as you

1084

don't you won't be disappointed with how long does it take to

1085

"finalize" the media.

1086

-->

1087

1088

It was pointed out to me that DVD+RW units work with

1089

Acard <A HREF="http://www.acard.com/eng/product/scside.html">SCSI to

1090

IDE bridges</A>.

1091

1092

1093

1094

What does <A

1095

HREF="http://www.cdfreaks.com/article/113">plus</A> in DVD+RW/+R

1096

stand for? Originally this paragraph started as following:

1097

1098

<BLOCKQUOTE>The key feature of DVD+RW/+R media is

1099

high [spatial] frequency wobbled [pre-]groove with addressing

1100

information modulated into it. This makes it possible to resume

1101

interrupted [or deliberately suspended] burning process with accuracy

1102

high enough for DVD[-ROM] player not to "notice" anything at

1103

playback time. Recovery from buffer underrun condition in DVD-RW/-R

1104

case in turn is way less accurate procedure, and the problem is that

1105

the provided accuracy is very much what average player can tolerate.

1106

Now given that both provided and tolerated inaccuracies are

1107

proportional to respectively writing and reading velocities there

1108

basically no guarantee that DVD-RW/-R recording that suffered from

1109

buffer underrun will be universally playable.</BLOCKQUOTE>

1110

1111

Well, it turned out that I was wrong about one

1112

thing. <!--About projecting CD-R[W] buffer underrun recovery procedure

1113

to DVD-R[W] to be specific.--> I failed to recognize that DVD-R[W]

1114

groove also provides for adequately accurate recovery from

1115

buffer underrun condition/lossless linking. Not as accurate as DVD+RW,

1116

but accurate enough for splices to be playable in virtually any

1117

DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording you

1118

apparently have to choose between

1119

1120

<UL>

1121

<LI>buffer underrun protection and

1122

<LI>full DVD-ROM/-Video compatibility.

1123

</UL>

1124

1125

The latter is achieved only in Disc-at-once

1126

recording mode and only if data-stream was maintained uninterrupted

1127

throughout whole recording. Once again. Even though most vendors

1128

implement lossless linking in DAO mode(*), full

1129

DVD-ROM/-Video compatibility is achieved only if recording didn't

1130

suffer from buffer underruns. The problem is that "offended"

1131

sectors are denoted with certain linking chunk appearing as degraded

1132

user data, few bytes, which are supposed to be "corrected

1133

away" by ECC procedure(**). DVD+ splices are in turn

1134

only few bits large and are "accounted" to sync patterns,

1135

not to user data area. So that even if suffered from buffer

1136

underrun, DVD+ sector is logically indistiguishable from DVD-ROM. Which

1137

is why it's commonly referred to that DVD+RW/+R combine DVD-ROM/-Video

1138

compatibility with [unconditional] buffer underrun protection.

1139

1140

As already mentioned, DVD+ groove has

1141

"addressing information modulated into it," ADIP (ADress In

1142

Pre-groove). This gives you an advantage of writing DVD+RW in truly

1143

arbitrary order, even to virgin surface and practically instantly

1144

(after ~40 seconds long initial format procedure). In addition, DVD+RW

1145

can be conveniently written to with 2KB granularity(***).

1146

DVD-RW in turn can only be overwritten in arbitrary order.

1147

Meaning that it either has to be completely formatted first (it takes

1148

an hour to format 1x media), or initially written to in a sequential

1149

manner. And it should also be noted that block overwrite is

1150

never an option if DVD-RW media was recorded in [compatible]

1151

Disc-at-once or even Incremental mode, only whole disc blanking is.

1152

1153

Unlike DVD-R[W], DVD+R[W] recordings can be

1154

suspended at any time without any side effects. Consider following

1155

scenario. You have a lot of data coming in [at lower rate], which is to

1156

be recorded into one file. Meanwhile it turns out that you have to

1157

retrieve previously recorded data. This would naturally require

1158

suspention of recording. Most notably in DVD-R [and naturally DVD-RW

1159

Sequential] case it would result in a hole in the file being recorded.

1160

So called linking area, most commonly 32KB gap, has to be introduced.

1161

So that you either have to wait till the file is complete or figure out

1162

how to deal with holey files. Thanks to ADIP, DVD+R recording is

1163

resumed from the very point it was suspended at. In DVD-RW Restricted

1164

Overwrite case no gaps are introduced, but if the media was formatted

1165

only minimally, suspension/resuming procedure has to be applied and it

1166

takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming

1167

is instant regardless media state.

1168

1169

What does all of the above mean in practice? Well, I

1170

was actually hoping that readers would [be able to] figure it out by

1171

themselves. Apparently a couple of "guiding" words are

1172

needed... It means that it's trivial to employ DVD+RW for housing of

1173

live and arbitrary file system, no special modifications to target file

1174

system driver are required. Real-time VBR (Variable Bit Rate) Video

1175

recordings are children's game.

1176

1177

Sometimes DVD+RW/+R recording strategy is referred

1178

to as packet writing. I myself am reluctant to call it so (or

1179

TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W]

1180

provides for lossless linking (within a packet/extent only),

1181

packets/extents are still denoted with certain linking information

1182

which distinguishes it (recording mode in question) from e.g.

1183

Disc-at-once. Now the point is that written DVD+RW/+R media, rather its

1184

Data Zone, does not contain any linking information and is

1185

logically indistinguishable from one written in DVD-R[W] Disc-at-once

1186

mode (or DVD-ROM for that matter).

1187

1188

It's maintained that signal from DVD+ groove (the

1189

one essential for recording, not reading) is much stronger, which makes

1190

it quite resistant to dust, scratches, etc.

1191

1192

1193

1194

1195

<TD>(*)

1196

<TD>According to <A

1197

HREF="ftp://ftp.avc-pioneer.com/Mtfuji5/Spec/">Mt. Fuji draft</A>

1198

buffer underrun protection is not even an option in DVD-R DAO. It's

1199

defined in Incremental Sequential mode and DVD-RW context. By the way,

1200

note that this draft also discusses DVD+RW. You should be aware that

1201

they refer to abandoned version which has very little to do with

1202

DVD+RW/+R implementation being discussed here.</TR>

1203

1204

<TD>(**)

1205

<TD>ECC redundancy does permit for more degradation,

1206

more that this linking chunk that is, so that it hadly affects the

1207

playability.</TR>

1208

1209

<TD>(***)

1210

<TD>DVD "native" block size is 32KB, and 2KB

1211

granularity is nothing but a trick, but you're excused from playing it,

1212

i.e. reading 32KB, replacing corresponding 2KB and writing 32KB

1213

back.</TR>

1214

</TABLE>

1215

1216

<HR>

1217

1218

1219

1220

</BODY>

1221

</HTML>