# growisofs suddenly wants to reload disc after burn [SOLVED]

## paulbiz

Hi,

I use growisofs to burn DVD ISO for regular system backups. I've been using this method for a couple hundred times, but suddenly tonight after the burn was over it ejected and reloaded the DVD tray! This is bad, because my case (Thermaltake Armor) has these stupid metal "wings" on the front that block the tray, and since my case is on its side gravity prevents them from being left open. This has never been a problem before, because growisofs never ejected the tray when a burn was done, so I was shocked when the burn was complete tonight and I heard a *CLANK* and saw the drive tray stuck halfway out, trapped on the metal wings.   :Shocked: 

I checked the manpage for growisofs and there does not appear to be any options to control this, and from what I can tell I have not emerged a new version of dvd+rw-tools since June. Perhaps growisofs is calling another program that has been changed lately?

Does anyone know what caused this? Is there a way I can burn a disc like growisofs WITHOUT it ejecting the tray afterward?

This is the command I use to burn: 

```
growisofs -dvd-compat -Z /dev/cdrom=/mnt/data/data.iso
```

It is a SATA DVD-RW drive and the burn seems to be okay, it is just the automatic ejecting that is annoying me now.

Thanks for any suggestions  :Smile: Last edited by paulbiz on Wed Feb 06, 2008 4:18 am; edited 1 time in total

----------

## frostschutz

growisofs always wanted to reload the tray, it's just that it didn't work due to some bug / change in kernel or elsewhere, at least that's how it appeared to me.

 *http://fy.chalmers.se/~appro/linux/DVD+RW/ wrote:*   

>  Why media reload is performed after every recording with growisofs? Well, it's performed only if you didn't patch the kernel:-) But no, I do not insist on patching the kernel! All I'm saying is that in the lack of kernel support, media reload is performed for the following reasons. In order to optimize file access kernel maintains so called block cache, so that repetitive requests for same data are met directly from memory and don't result in multiple physical I/O. Now the catch is that block cache layer remains totally unaware of growisofs activities, growisofs bypasses the block cache. This means that block cache inevitably becomes out of sync, which in turn might appear to you as corrupted data. Media reload is performed when flushing the block cache is not an option, e.g. only privileged user is allowed to perform it. Second reason is to force kernel to readjust last addressable block in case it was changed as result of recording. This is done to preclude spurious "attempts to access beyond end of device."

 

So it sounds like there is a kernel patch that prevents growisofs from reloading because it can flush the cache or whatever by some other means?   :Shocked: 

On the other hand, that passage seems to refer to some old 2.4 kernel stuff. Maybe contact the author and ask if there's anything you can do.

----------

## paulbiz

that's interesting, thanks for the info. I'll see what I can find out.

The GUI burning software usually lets you choose to eject after burn or not, for sure K3B has an option "do not eject media after burning". I will have to try it and see if it actually works  :Razz: 

----------

## paulbiz

Well, I burned DVD ISO image using K3B with "eject after burn" disabled, and sure enough it did not eject. The commandline contains some funny things:

```
/usr/bin/growisofs -Z /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=tracksize:2294921 -dvd-compat -speed=18 -use-the-force-luke=bufsize:32m
```

The winner here is "-use-the-force-luke=notray", which is an undocumented command to suppress tray reload. Nice.  :Smile: 

----------

