Re: 2.6.0, cdrom still showing directories after being erased

Re: 2.6.0, cdrom still showing directories after being erased

[Thomas Glanzmann]

Hi,

> now I got the error which I would expect after erasing the CD and trying
> to mount it

> seems to me like some cache should have been invalidated, but was not

I hit at this problem while I was writing an IDE Atapi simulator for
FAUmachine. The problem is that the kernel asks the CDROM if the 'disc
has changed', which means that the disc was ejected and reinserted, and
if this *isn't* the case the vfs or whatever assumes that the media
hasn't changed and so the buffers will not be flushed. You can cirumvent
this problem if you just eject and load the media back again.

And this isn't an issue of the cdrom (because my virtual cdrom on
FAUmachine has no buffer) but an issue of the kernel caching.

The linux kernel atapi layer makes a TEST UNIT READY and if the media
has changed the cdrom does return an ERR_STAT with a UNIT_ATTENTION
which means that the medium has changed. IF that this the case the
kernel flushes it's buffers.

	Thomas

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Thu, Feb 05 2004, Thomas Glanzmann wrote:
> Hi,
> 
> > now I got the error which I would expect after erasing the CD and trying
> > to mount it
> 
> > seems to me like some cache should have been invalidated, but was not
> 
> I hit at this problem while I was writing an IDE Atapi simulator for
> FAUmachine. The problem is that the kernel asks the CDROM if the 'disc
> has changed', which means that the disc was ejected and reinserted, and
> if this *isn't* the case the vfs or whatever assumes that the media
> hasn't changed and so the buffers will not be flushed. You can cirumvent
> this problem if you just eject and load the media back again.
> 
> And this isn't an issue of the cdrom (because my virtual cdrom on
> FAUmachine has no buffer) but an issue of the kernel caching.
> 
> The linux kernel atapi layer makes a TEST UNIT READY and if the media
> has changed the cdrom does return an ERR_STAT with a UNIT_ATTENTION
> which means that the medium has changed. IF that this the case the
> kernel flushes it's buffers.

So the drive ought to report media changed if it knowingly over wrote
the table of contents, for instance.

I still think this is to be expected when mucking in undefined teritory.
Reload the media, it's not hard... Sure you can get around this with
snooping if you really wanted to, but IMO it's wasted effort. Add -eject
to cdrecord command line of default config, how you want so solve it is
not my problem.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[Thomas Glanzmann]

Hi,

> So the drive ought to report media changed if it knowingly over wrote
> the table of contents, for instance.

I am not so sure about this. I can't find anything describing this. But
looking at SPC-2 Section 7.25 talks only about 'becoming ready and media
changed'.

> I still think this is to be expected when mucking in undefined teritory.
> Reload the media, it's not hard... Sure you can get around this with
> snooping if you really wanted to, but IMO it's wasted effort. Add -eject
> to cdrecord command line of default config, how you want so solve it is
> not my problem.

I don't understand why the Linux kernel doesn't simply invalidates the
buffers when a CDROM media is unmounted. If this would be case no such
problems would ever occur.

	Thomas

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Thu, Feb 05 2004, Thomas Glanzmann wrote:
> > I still think this is to be expected when mucking in undefined teritory.
> > Reload the media, it's not hard... Sure you can get around this with
> > snooping if you really wanted to, but IMO it's wasted effort. Add -eject
> > to cdrecord command line of default config, how you want so solve it is
> > not my problem.
> 
> I don't understand why the Linux kernel doesn't simply invalidates the
> buffers when a CDROM media is unmounted. If this would be case no such
> problems would ever occur.

Actually, that would be an acceptable work around to me. The buffers are
invalidated in the block device page cache on last close, should be easy
enough to kill the driver private TOC cache as well.

===== drivers/ide/ide-cd.c 1.68 vs edited =====
--- 1.68/drivers/ide/ide-cd.c	Wed Feb  4 06:37:42 2004
+++ edited/drivers/ide/ide-cd.c	Thu Feb  5 22:28:50 2004
@@ -2860,6 +2860,10 @@
 static
 void ide_cdrom_release_real (struct cdrom_device_info *cdi)
 {
+	ide_drive_t *drive = cdi->handle;
+
+	if (!cdi->use_count)
+		CDROM_STATE_FLAGS(drive)->toc_valid = 0;
 }
 
 

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> > I still think this is to be expected when mucking in undefined teritory.
> > Reload the media, it's not hard... Sure you can get around this with
> > snooping if you really wanted to, but IMO it's wasted effort. Add -eject
> > to cdrecord command line of default config, how you want so solve it is
> > not my problem.
> 
> I don't understand why the Linux kernel doesn't simply invalidates the
> buffers when a CDROM media is unmounted. If this would be case no such
> problems would ever occur.

At a guess, it might be a hack intended to increase performance for CD
jukeboxes where only one disc can be mounted at a time.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Pavel Machek]

hi!

> > The linux kernel atapi layer makes a TEST UNIT READY and if the media
> > has changed the cdrom does return an ERR_STAT with a UNIT_ATTENTION
> > which means that the medium has changed. IF that this the case the
> > kernel flushes it's buffers.
> 
> So the drive ought to report media changed if it knowingly over wrote
> the table of contents, for instance.
> 

Why? Media did not change.

You would need cdrom to report media change on each write,
but that would break packet writing. We should fix
kernel/cdrecord, not break hw.

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: 2.6.0, cdrom still showing directories after being erased

[Thomas Glanzmann]

Hi,

> Okay, we may be dealing with the buggy hardware at this point. Would
> it make sense to tell the drive to flush it caches? If there's no
> other possibility, we might want cdrecord to reset drive at the end of
> blank and/or to make it eject...

It's not the drive, it's the kernel. We have to tell the kernel to
*flush* *it's* buffers when doing an umount. See my other posting.

	Thomas

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Thu, Feb 05 2004, Thomas Glanzmann wrote:
> Hi,
> 
> > Okay, we may be dealing with the buggy hardware at this point. Would
> > it make sense to tell the drive to flush it caches? If there's no
> > other possibility, we might want cdrecord to reset drive at the end of
> > blank and/or to make it eject...
> 
> It's not the drive, it's the kernel. We have to tell the kernel to
> *flush* *it's* buffers when doing an umount. See my other posting.

Partly, I still think the drive should report media changed after
knowingly doing a TOC blank (or change). But see my other post, should
work.

-- 
Jens Axboe

2.6.0, cdrom still showing directories after being erased

[Martin Povolný]

I have debian's 2.6.0-686-smp only with PNP BIOS disabled (fails to
boot with enabled, as described by other people).

I did

$ mount /cdrom/
$ ls /cdrom/

got listing of files and directories on the cdrom
then

$ cdrecord dev=/dev/hdc -blank=fast -v
...
Blanking time:   21.570s
$ mount /cdrom
$ ls /cdrom

got the listing again!
could even 'cd' to a directory, couldn't read files

$ umount /cdrom
$ eject /cdrom; eject -t /cdrom
$ mount /cdrom

now I got the error which I would expect after erasing the CD and trying
to mount it

seems to me like some cache should have been invalidated, but was not

cdrecord:
    Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu)
cdrom:
    0,0,0     0) 'HL-DT-ST' 'RW/DVD GCC-4480B' '1.00' Removable CD-ROM

p.s. sorry if I'm reporting something already repaired, but I have
searched the archive, changelog and asked google before writing here

-- 
Martin Povolný, xpovolny@fi.muni.cz, http://www.fi.muni.cz/~xpovolny

Re: 2.6.0, cdrom still showing directories after being erased

[Måns Rullgård]

Martin Povolný <xpovolny@aurora.fi.muni.cz> writes:

> I have debian's 2.6.0-686-smp only with PNP BIOS disabled (fails to
> boot with enabled, as described by other people).
>
> I did
>
> $ mount /cdrom/
> $ ls /cdrom/
>
> got listing of files and directories on the cdrom
> then
>
> $ cdrecord dev=/dev/hdc -blank=fast -v

It's not very nice to go and erase the CD while it's mounted.  Unmount
first and you'll be fine.

-- 
Måns Rullgård
mru@kth.se

Re: 2.6.0, cdrom still showing directories after being erased

[Richard B. Johnson]

On Tue, 3 Feb 2004, Martin [iso-8859-2] Povolný wrote:

> I have debian's 2.6.0-686-smp only with PNP BIOS disabled (fails to
> boot with enabled, as described by other people).
>
> I did
>
> $ mount /cdrom/
> $ ls /cdrom/
>
> got listing of files and directories on the cdrom
> then
>
> $ cdrecord dev=/dev/hdc -blank=fast -v
> ...
> Blanking time:   21.570s
> $ mount /cdrom
> $ ls /cdrom

Can you really initialize the CDROM while it's mounted? Although
the kernel doesn't care, cdrecord should. Suggest that you
contact the cdrecord author.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: 2.6.0, cdrom still showing directories after being erased

[Tomas Zvala]

Hi,
I believe he meant to write he umounted it.
The problem is that there is still some data left in CDRW's cache and it 
needs to be emptied. That happens when CDRW is ejected and reinserted 
(that is why windows burning software ie. Nero wants to eject the CDR/RW 
when it gets written or erased).
Maybe kernel could flush the buffers/caches or whatever is there when 
CDROM gets mounted. But im afraid about compatibility with broken drives 
such as LG.

Tomas Zvala

Richard B. Johnson wrote:

>On Tue, 3 Feb 2004, Martin [iso-8859-2] Povolný wrote:
>
>  
>
>>I have debian's 2.6.0-686-smp only with PNP BIOS disabled (fails to
>>boot with enabled, as described by other people).
>>
>>I did
>>
>>$ mount /cdrom/
>>$ ls /cdrom/
>>
>>got listing of files and directories on the cdrom
>>then
>>
>>$ cdrecord dev=/dev/hdc -blank=fast -v
>>...
>>Blanking time:   21.570s
>>$ mount /cdrom
>>$ ls /cdrom
>>    
>>
>
>Can you really initialize the CDROM while it's mounted? Although
>the kernel doesn't care, cdrecord should. Suggest that you
>contact the cdrecord author.
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
>            Note 96.31% of all statistics are fiction.
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: 2.6.0, cdrom still showing directories after being erased

[Richard B. Johnson]

On Tue, 3 Feb 2004, Tomas Zvala wrote:

> Hi,
> I believe he meant to write he umounted it.
> The problem is that there is still some data left in CDRW's cache and it
> needs to be emptied. That happens when CDRW is ejected and reinserted
> (that is why windows burning software ie. Nero wants to eject the CDR/RW
> when it gets written or erased).
> Maybe kernel could flush the buffers/caches or whatever is there when
> CDROM gets mounted. But im afraid about compatibility with broken drives
> such as LG.
>
> Tomas Zvala

That's not what he said and, I assure you that if he unmounted
it there would not be any buffers to flush. Execute `man umount`.

The problem is that the cd-burner allowed the read-only file-system
to be modified while it was mounted. That is an applications problem
because the file-system is R/O, but the device is not. The kernel
will correctly prevent writes to the R/O file-system, and will
correctly allow writes to the underlying device. It is up to
the application (cdrecord) to prevent undesired operations.

>
> Richard B. Johnson wrote:
>
> >On Tue, 3 Feb 2004, Martin [iso-8859-2] Povolný wrote:
> >
> >
> >
> >>I have debian's 2.6.0-686-smp only with PNP BIOS disabled (fails to
> >>boot with enabled, as described by other people).
> >>
> >>I did
> >>
> >>$ mount /cdrom/
> >>$ ls /cdrom/
> >>
> >>got listing of files and directories on the cdrom
> >>then
> >>
> >>$ cdrecord dev=/dev/hdc -blank=fast -v
> >>...
> >>Blanking time:   21.570s
> >>$ mount /cdrom
> >>$ ls /cdrom
> >>
> >>
> >
> >Can you really initialize the CDROM while it's mounted? Although
> >the kernel doesn't care, cdrecord should. Suggest that you
> >contact the cdrecord author.
> >
> >Cheers,
> >Dick Johnson
> >Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
> >            Note 96.31% of all statistics are fiction.
> >
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: 2.6.0, cdrom still showing directories after being erased

[Tomas Zvala]

Ok,
Im sorry for misinformation ... I better just keep on reading not 
writing :).
But anyway. The thing that mislead me is that I would expect to get 
"already mounted" message if  I tried to mount the drive to the same 
mountpoint again.(at least i get it if i try to do it with read-only 
mounted xfs. i cant try it with iso9660 on cdr).

Tomas Zvala

Richard B. Johnson wrote:

>On Tue, 3 Feb 2004, Tomas Zvala wrote:
>
>  
>
>That's not what he said and, I assure you that if he unmounted
>it there would not be any buffers to flush. Execute `man umount`.
>
>  
>

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> That's not what he said and, I assure you that if he unmounted
> it there would not be any buffers to flush. Execute `man umount`.

I think the original poster was referring to the cache on the device.

I.E.

mount disc
view contents
unmount disc
erase disc - but don't erase the CD-R drive's cache of the media
mount disc
view old contents of the media from the CD-R drive's cache

However, note that the disc was fast erased - according to the
cdrecord manual page, only the PMA, TOC, and pregap are erased.
Therefore, as long as these are cached by the device, user data could
theoretically still be read directly from the media.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Måns Rullgård]

John Bradford <john@grabjohn.com> writes:

>> That's not what he said and, I assure you that if he unmounted
>> it there would not be any buffers to flush. Execute `man umount`.
>
> I think the original poster was referring to the cache on the device.
>
> I.E.
>
> mount disc
> view contents
> unmount disc
> erase disc - but don't erase the CD-R drive's cache of the media
> mount disc
> view old contents of the media from the CD-R drive's cache

If that's the case, the drive is broken.  We can't help that.

-- 
Måns Rullgård
mru@kth.se

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> John Bradford <john@grabjohn.com> writes:
> 
> >> That's not what he said and, I assure you that if he unmounted
> >> it there would not be any buffers to flush. Execute `man umount`.
> >
> > I think the original poster was referring to the cache on the device.
> >
> > I.E.
> >
> > mount disc
> > view contents
> > unmount disc
> > erase disc - but don't erase the CD-R drive's cache of the media
> > mount disc
> > view old contents of the media from the CD-R drive's cache
> 
> If that's the case, the drive is broken.  We can't help that.

Is it actually a requirement for drives to support anything other than
a full erase properly?  Is the 'fast' erase valid per spec, or does it
just happen to work on 99% of devices?  Is this problem reproducable
if a full erase is done instead of a fast erase?

I've added the original poster to the CC list.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Martin Povolný]

Dne: Tue, Feb 03, 2004 at 04:35:19PM +0000, John Bradford napsal:
> Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> > John Bradford <john@grabjohn.com> writes:
> > 
> > >> That's not what he said and, I assure you that if he unmounted
> > >> it there would not be any buffers to flush. Execute `man umount`.
> > >
> > > I think the original poster was referring to the cache on the device.

I don't know what cache, I don't understand it :-(

> > >
> > > I.E.
> > >
> > > mount disc
> > > view contents
> > > unmount disc
> > > erase disc - but don't erase the CD-R drive's cache of the media
> > > mount disc
> > > view old contents of the media from the CD-R drive's cache

That's it exactly.

> > 
> > If that's the case, the drive is broken.  We can't help that.

That's possible, it's a cheap combo from LG. I have even seen it on the
list of droken drives (the ones that died trying to install mandrake)
[http://archives.mandrakelinux.com/expert/2003-10/msg02116.php], even
though it's a CDRW.

It that case sorry for bothering you with crappy hw problem.

> 
> Is it actually a requirement for drives to support anything other than
> a full erase properly?  Is the 'fast' erase valid per spec, or does it
> just happen to work on 99% of devices?  Is this problem reproducable
> if a full erase is done instead of a fast erase?

Yes, it is:

$ cdrecord dev=/dev/hdc -blank=all -v
Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '/dev/hdc'
devname: '/dev/hdc'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.7'
SCSI buffer size: 64512
atapi: 1
Device type    : Removable CD-ROM
Version        : 0
Response Format: 1
Vendor_info    : 'HL-DT-ST'
Identifikation : 'RW/DVD GCC-4480B'
Revision       : '1.00'
Device seems to be: Generic mmc2 DVD-ROM.
Current: 0x000A
Profile: 0x000A (current)
Profile: 0x0009
Profile: 0x0008
Profile: 0x0002 (current)
Profile: 0x0010
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-2 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1591744 = 1554 KB
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 2
  Reference speed: 6
  Is not unrestricted
  Is erasable
  Disk sub type: High speed Rewritable (CAV) media (1)
  ATIP start of lead in:  -11077 (97:34/23)
  ATIP start of lead out: 359849 (79:59/74)
  1T speed low:  4 1T speed high: 10
  2T speed low:  2 2T speed high: 10
  power mult factor: 2 6
  recommended erase/write power: 5
  A1 values: 24 2C DC
  A2 values: 14 A4 4A
Disk type:    Phase change
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Starting to write CD/DVD at speed 10 in real BLANK mode for single session.
Last chance to quit, starting real write    0 seconds. Operation starts.
Performing OPC...
Blanking entire disk
Blanking time:  514.223s
pie:martin:~
$ mount /cdrom
pie:martin:~
$ ls -l /cdrom/
celkem 64
dr-xr-xr-x    2 root     root        36864 2004-02-03 18:00 Beskydy2003-2004
dr-xr-xr-x    2 root     root         4096 2004-02-03 18:00 Cukl-Leden2004
dr-xr-xr-x    2 root     root         4096 2004-02-03 18:00 unsorted
dr-xr-xr-x    2 root     root        20480 2004-02-03 18:00 Vanoce2003

pie:martin:~
$ eject /cdrom/; eject -t /cdrom/
pie:martin:~
$ LC_ALL=C mount /cdrom/
/dev/cdrom: Input/output error
mount: I could not determine the filesystem type, and none was specified

Could it be also cdrecord problem? Couldn't cdrecord execute some command
to flush the cdrom's cache after erasing?

Thank you all for your interest.

-- 
Martin Povolný, xpovolny@fi.muni.cz, http://www.fi.muni.cz/~xpovolny

Re: 2.6.0, cdrom still showing directories after being erased

[Martin Povolný]

I have to make clear that I did unmount the CD before erasing it.

Sorry for the mistake.

-- 
Martin Povolný, xpovolny@fi.muni.cz, http://www.fi.muni.cz/~xpovolny

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> > > > I.E.
> > > >
> > > > mount disc
> > > > view contents
> > > > unmount disc
> > > > erase disc - but don't erase the CD-R drive's cache of the media
> > > > mount disc
> > > > view old contents of the media from the CD-R drive's cache
> 
> That's it exactly.
> 

[snip]
> > > 
> > > If that's the case, the drive is broken.  We can't help that.
> 
> That's possible, it's a cheap combo from LG. I have even seen it on the
> list of droken drives (the ones that died trying to install mandrake)
> [http://archives.mandrakelinux.com/expert/2003-10/msg02116.php], even
> though it's a CDRW.
> 
> It that case sorry for bothering you with crappy hw problem.
> 
> > 
> > Is it actually a requirement for drives to support anything other than
> > a full erase properly?  Is the 'fast' erase valid per spec, or does it
> > just happen to work on 99% of devices?  Is this problem reproducable
> > if a full erase is done instead of a fast erase?
> 
> Yes, it is:

[snip]

> Could it be also cdrecord problem? Couldn't cdrecord execute some command
> to flush the cdrom's cache after erasing?

Jens said there was no specific command to do this in another post,
although I would have thought that a generic device reset command
should clear the cache, but be sub-optimal for devices which clear the
cache themselves on an erase.

Regardless of specs, I don't know what the majority of devices in the
real world actually do.  Maybe Jens and Alan, (cc'ed), can help.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Måns Rullgård]

John Bradford <john@grabjohn.com> writes:

> Regardless of specs, I don't know what the majority of devices in the
> real world actually do.  Maybe Jens and Alan, (cc'ed), can help.

Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
after doing a fast erase, just like it should.

-- 
Måns Rullgård
mru@kth.se

Re: 2.6.0, cdrom still showing directories after being erased

[Richard B. Johnson]

On Tue, 3 Feb 2004, [iso-8859-1] Måns Rullgård wrote:

> John Bradford <john@grabjohn.com> writes:
>
> > Regardless of specs, I don't know what the majority of devices in the
> > real world actually do.  Maybe Jens and Alan, (cc'ed), can help.
>
> Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
> after doing a fast erase, just like it should.
>
> --
> Måns Rullgård
> mru@kth.se
> -

I had to borrow a R/W CDROM because most everybody uses CR-R only
here. That's why it took so long to check. With SCSI, Linux 2.4.24,
cdrecord fails to umount the drive before it burns it. The result
is that the previous directory still remains at the mount-point.
This, even though cdrecord ejected the drive to "re-read" its
status.

Bottom line: If the CDROM isn't umounted first, you can still
get a directory entry even though the CDROM has been written with
about 500 magabytes of new data.


Script started on Tue Feb  2 02:11:28 2004
# cat cp.iso
if  ! test $1 ; then
    echo "Usage cp.iso <directory>"
    exit 1
fi
DEV=`cdrecord -scanbus | grep ROM | cut -f2,2`
echo Using CD-ROM device, ${DEV}
echo Trying to erase the media
cdrecord dev=${DEV} blank=fast
echo Starting to write the media
nice --18 mkisofs -L -l -R -P Analogic -p rjohnson@analogic.com \
 $1 | cdrecord -v fs=6m dev=${DEV} speed=4 -eject -

# cp.iso platinum
Using libscg version 'schily-0.1'
Using CD-ROM device, 0,4,0
Trying to erase the media
Cdrecord release 1.8a35 Copyright (C) 1995-1999 Jörg Schilling
scsidev: '0,4,0'
scsibus: 0 target: 4 lun: 0
Using libscg version 'schily-0.1'
Device type    : Removable CD-ROM
Version        : 2
Response Format: 2
Capabilities   : SYNC
Vendor_info    : 'YAMAHA  '
Identifikation : 'CRW6416S        '
Revision       : '1.0b'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
cdrecord: Drive needs to reload the media to return to proper status.
Starting to write CD/DVD at speed 1 in write mode for single session.
Last chance to quit, starting real write in 9 seconds.\b\b\b\b\b\b\b\b\b\b8 seconds.\b\b\b\b\b\b\b\b\b\b7 seconds.\b\b\b\b\b\b\b\b\b\b6 seconds.\b\b\b\b\b\b\b\b\b\b5 seconds.\b\b\b\b\b\b\b\b\b\b4 seconds.\b\b\b\b\b\b\b\b\b\b3 seconds.\b\b\b\b\b\b\b\b\b\b2 seconds.\b\b\b\b\b\b\b\b\b\b1 seconds.

[SNIPPED...]
Starting to write the media
Cdrecord release 1.8a35 Copyright (C) 1995-1999 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,4,0'
scsibus: 0 target: 4 lun: 0
Using libscg version 'schily-0.1'
atapi: 0
Device type    : Removable CD-ROM
Version        : 2
Response Format: 2
Capabilities   : SYNC
Vendor_info    : 'YAMAHA  '
Identifikation : 'CRW6416S        '
Revision       : '1.0b'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
Drive buf size : 1566432 = 1529 KB
FIFO size      : 6291456 = 6144 KB
Track 01: data  unknown length
Total size:       0 MB (00:00.00) = 0 sectors
Lout start:       0 MB (00:02/00) = 0 sectors
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 5
  Is not unrestricted
  Is not erasable
  Disk sub type: 2
  ATIP start of lead in:  -11634 (97:26/66)
  ATIP start of lead out: 359848 (79:59/73)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 3
Manufacturer: CMC Magnetics Corporation
Trying to clear drive status.
cdrecord: Drive needs to reload the media to return to proper status.
Using TESTLIBRAW.000;1 for  platinum/firewire/libraw1394-0.9.0/doc/testlibraw.1.in (testlibraw.1)
Using CONFIG.000;1 for  platinum/firewire/libraw1394-0.9.0/config.h.in (config.h)
Using IEEE.000;1 for  platinum/IEEE-database/IEEE.dat.backup (IEEE.dat)
Using LD.000;1 for  platinum/kernel/linux-2.4.18/arch/mips64/ld.script.elf32.S (ld.script.elf64)
Using IPT_TOS.000;1 for  platinum/kernel/linux-2.4.18/include/linux/netfilter_ipv4/ipt_tos.h (ipt_TOS.h)
Using IPT_TCPMSS.000;1 for  platinum/kernel/linux-2.4.18/include/linux/netfilter_ipv4/ipt_tcpmss.h (ipt_TCPMSS.h)
Using IPT_MARK.000;1 for  platinum/kernel/linux-2.4.18/include/linux/netfilter_ipv4/ipt_mark.h (ipt_MARK.h)
Using IP6T_MARK.000;1 for  platinum/kernel/linux-2.4.18/include/linux/netfilter_ipv6/ip6t_mark.h (ip6t_MARK.h)
Using .000;1 for  platinum/kernel/linux-2.4.18/net/ipv4/netfilter/.ipt_TOS.o.flags (.ipt_tos.o.flags)
Using .001;1 for  platinum/kernel/linux-2.4.18/net/ipv4/netfilter/.ipt_MARK.o.flags (.ipt_mark.o.flags)
Using IPT_TOS.000;1 for  platinum/kernel/linux-2.4.18/net/ipv4/netfilter/ipt_TOS.o (ipt_tos.o)
Using IPT_TOS.001;1 for  platinum/kernel/linux-2.4.18/net/ipv4/netfilter/ipt_tos.c (ipt_TOS.c)
Using IPT_TCPMSS.000;1 for  platinum/kernel/linux-2.4.18/net/ipv4/netfilter/ipt_tcpmss.c (ipt_TCPMSS.c)
[SNIPPED...]

Using IPCHAINS.000 for  ./rr_moved/ipchains (ipchains)
Using XXXX.000 for  ./rr_moved/xxxx (xxxx)
  92  6760 platinum
  96  9510 rr_moved
 101   450 xxxx
 102   328 raid
 103   340 ipchains
 104   340 ipfwadm
 105   334 ah
 106   340 limit
 107   340 mac
 108   340 mark
 109   340 multiport
 110   340 owner
 111   340 state
 112   340 tos
 113   340 unclean
 114   340 ftp
 115   338 snmp
 116   340 log
 117   340 mark
 118   340 masquerade
 119   340 mirror
 120   340 redirect
 121   340 reject
 122   340 tos
 123   340 limit
 124   340 mark
 125   340 mark
 126   344 linked
 127   336 max
 128   340 acceleport
 129   340 sio
 130   340 pda
 131   340 u232
 132   450 xxxx
 133   328 raid
 134   340 limit
 135   340 mac
 136   340 mark
 137   340 multiport
 138   340 tos
 139   334 ah
 140   340 reject
 141   340 ipchains
 142   340 ipfwadm
 143   344 linked
 144   336 max
 145  1406 pcibr
 146   336 bits
 147   464 m68k
 148   348 bits
 149   348 bits
 150   838 bits
 151   350 sys
 152   348 bits
 153  1822 bits
 154   464 alpha
 155   338 net
 156   954 sys
 157   466 bits
 158   694 sys
 159   340 i686
 160  1308 sys
 161   586 bits
 162   334 sys
 163   456 bits
 164  2296 bits
 166   968 sys
 167   714 bits
 168   588 sys
 169  4220 sparc32
 172  5380 sparc64
 175   718 sys
 176  1580 bits
 177   336 bits
 178   832 bits
 179  1432 sparc
 180   452 sys
 181   330 sparc32
 182   336 bits
 183   464 sys
 184   606 bits
[SNIPPED...]

Writing  time:    1921.042s
Fixating...
Fixating time:   15.325s
cdrecord: fifo had 1924382 puts and 1924382 gets.
cdrecord: fifo was 0 times empty and 430948 times full, min fill was 100%.
You have new mail in /var/spool/mail/root
# ls /mnt
Presto	altmath
# ls /mnt
Presto	altmath
# ls /mnt/*
/mnt/Presto:

/mnt/altmath:
# ls /mnt/*
Presto	altmath
# exit
exit

Script done on Tue Feb  3 35:16:38 2004


Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> I had to borrow a R/W CDROM because most everybody uses CR-R only
> here. That's why it took so long to check. With SCSI, Linux 2.4.24,
> cdrecord fails to umount the drive before it burns it. The result
> is that the previous directory still remains at the mount-point.
> This, even though cdrecord ejected the drive to "re-read" its
> status.
> 
> Bottom line: If the CDROM isn't umounted first, you can still
> get a directory entry even though the CDROM has been written with
> about 500 magabytes of new data.

You're describing a different problem.  The original poster is
unmounting the disc before erasing it.

It would be nice if cdrecord checked that the device it was about to
write to wasn't already mounted, and complained if it was.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Tue, Feb 03 2004, Richard B. Johnson wrote:
> On Tue, 3 Feb 2004, [iso-8859-1] Måns Rullgård wrote:
> 
> > John Bradford <john@grabjohn.com> writes:
> >
> > > Regardless of specs, I don't know what the majority of devices in the
> > > real world actually do.  Maybe Jens and Alan, (cc'ed), can help.
> >
> > Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
> > after doing a fast erase, just like it should.
> >
> > --
> > Måns Rullgård
> > mru@kth.se
> > -
> 
> I had to borrow a R/W CDROM because most everybody uses CR-R only
> here. That's why it took so long to check. With SCSI, Linux 2.4.24,
> cdrecord fails to umount the drive before it burns it. The result
> is that the previous directory still remains at the mount-point.
> This, even though cdrecord ejected the drive to "re-read" its
> status.
> 
> Bottom line: If the CDROM isn't umounted first, you can still
> get a directory entry even though the CDROM has been written with
> about 500 magabytes of new data.

So what? Just because you can do it, doesn't mean it's a valid thing to
do. You can literally come up with thousands of similar weird things, if
you wanted to.

This whole discussion is silly and pointless.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Wed, 2004-02-04 at 00:40, Jens Axboe wrote:
> On Tue, Feb 03 2004, Richard B. Johnson wrote:
> > On Tue, 3 Feb 2004, [iso-8859-1] Måns Rullgård wrote:
> > 
> > > John Bradford <john@grabjohn.com> writes:
> > >
> > > > Regardless of specs, I don't know what the majority of devices in the
> > > > real world actually do.  Maybe Jens and Alan, (cc'ed), can help.
> > >
> > > Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
> > > after doing a fast erase, just like it should.
> > >
> > > --
> > > Måns Rullgård
> > > mru@kth.se
> > > -
> > 
> > I had to borrow a R/W CDROM because most everybody uses CR-R only
> > here. That's why it took so long to check. With SCSI, Linux 2.4.24,
> > cdrecord fails to umount the drive before it burns it. The result
> > is that the previous directory still remains at the mount-point.
> > This, even though cdrecord ejected the drive to "re-read" its
> > status.
> > 
> > Bottom line: If the CDROM isn't umounted first, you can still
> > get a directory entry even though the CDROM has been written with
> > about 500 magabytes of new data.
> 
> So what? Just because you can do it, doesn't mean it's a valid thing to
> do. You can literally come up with thousands of similar weird things, if
> you wanted to.
> 
> This whole discussion is silly and pointless.

I am assuming its cdrecord's responsibility to check if the device is
not in use?  How difficult will it be to add a kernel side stopper to
this (as it will after all also stop this thread) ?

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

Quote from Martin Schlemmer <azarah@nosferatu.za.org>:
> 
> --=-jU1p/KAdUL1ChKMTod+5
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> On Wed, 2004-02-04 at 00:40, Jens Axboe wrote:
> > On Tue, Feb 03 2004, Richard B. Johnson wrote:
> > > On Tue, 3 Feb 2004, [iso-8859-1] M=C3=A5ns Rullg=C3=A5rd wrote:
> > >=20
> > > > John Bradford <john@grabjohn.com> writes:
> > > >
> > > > > Regardless of specs, I don't know what the majority of devices in t=
> he
> > > > > real world actually do.  Maybe Jens and Alan, (cc'ed), can help.
> > > >
> > > > Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
> > > > after doing a fast erase, just like it should.
> > > >
> > > > --
> > > > M=C3=A5ns Rullg=C3=A5rd
> > > > mru@kth.se
> > > > -
> > >=20
> > > I had to borrow a R/W CDROM because most everybody uses CR-R only
> > > here. That's why it took so long to check. With SCSI, Linux 2.4.24,
> > > cdrecord fails to umount the drive before it burns it. The result
> > > is that the previous directory still remains at the mount-point.
> > > This, even though cdrecord ejected the drive to "re-read" its
> > > status.
> > >=20
> > > Bottom line: If the CDROM isn't umounted first, you can still
> > > get a directory entry even though the CDROM has been written with
> > > about 500 magabytes of new data.
> >=20
> > So what? Just because you can do it, doesn't mean it's a valid thing to
> > do. You can literally come up with thousands of similar weird things, if
> > you wanted to.
> >=20
> > This whole discussion is silly and pointless.
> 
> I am assuming its cdrecord's responsibility to check if the device is
> not in use?  How difficult will it be to add a kernel side stopper to
> this (as it will after all also stop this thread) ?

The problem you are discussing now is completely different to what we
were originally discussing, and almost completely pointless.

Of course you get problems if a raw devices changes underneath a
mounted filesystem, I would expect that.  That is _NOT_ what we were
talking about _AT ALL_.  The point is that the device itself caches
the state of the disc over an erase, so even if the device is
unmounted before an erase, when it is re-mounted, the stale data is
read from the device's own cache, which should have been invalidated
by the erase.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Eduard Bloch]

Moin John!
John Bradford schrieb am Wednesday, den 04. February 2004:

> > > This whole discussion is silly and pointless.
> > 
> > I am assuming its cdrecord's responsibility to check if the device is
> > not in use?  How difficult will it be to add a kernel side stopper to
> > this (as it will after all also stop this thread) ?
> 
> The problem you are discussing now is completely different to what we
> were originally discussing, and almost completely pointless.

Yep, the first part (overwritting mounted media) is pointless, the
second IS NOT.

> Of course you get problems if a raw devices changes underneath a
> mounted filesystem, I would expect that.  That is _NOT_ what we were
> talking about _AT ALL_.  The point is that the device itself caches
> the state of the disc over an erase, so even if the device is
> unmounted before an erase, when it is re-mounted, the stale data is
> read from the device's own cache, which should have been invalidated
> by the erase.

Is it realy a hardware issue? We have a very similar bug in the Debian
BTS (ping-pong issue between kernel and cdrtools maintainers). The
problem there is: 

 you have a session
 you umount the iso9660 there
 you write a second session
 you mount the media without ejecting it
 AND you see the OLD filesystem. And it is large, IMHO this does NOT
 come from the cache. I think there is an ugly bug in kernel's CDROM
 TOC/session management, it caches the TOC data and does not invalidate
 it on mount calls.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93633

Oh, and it is very simple to shout on anyone "Just eject and reload,
there is no issue, everything pointless".

This sucks. It is not a solution, it is a an admited failure. In
most notebooks, the media cannot be reloaded, and in normal PC boxes
with closed front door, you always risk mechanical damage if the door is
closed and you did not notice it.

Regards,
Eduard.
-- 
Du wirst in einer Onlinedatenbank alles finden, nur nicht das, was du suchst.

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> > Of course you get problems if a raw devices changes underneath a
> > mounted filesystem, I would expect that.  That is _NOT_ what we were
> > talking about _AT ALL_.  The point is that the device itself caches
> > the state of the disc over an erase, so even if the device is
> > unmounted before an erase, when it is re-mounted, the stale data is
> > read from the device's own cache, which should have been invalidated
> > by the erase.
> 
> Is it realy a hardware issue?

I originally thought so, but maybe I was wrong.  Jens posted a patch
to invalidate kernel buffers on an umount - if the problem persists
with that patch, I still believe it is a hardware fault.

> Oh, and it is very simple to shout on anyone "Just eject and reload,
> there is no issue, everything pointless".

Well, I never suggested that, and I don't think it's an acceptable
solution, unless the problem is limited to a few broken drives.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Eduard Bloch]

Moin John!
John Bradford schrieb am Friday, den 06. February 2004:

> > > unmounted before an erase, when it is re-mounted, the stale data is
> > > read from the device's own cache, which should have been invalidated
> > > by the erase.
> > 
> > Is it realy a hardware issue?
> 
> I originally thought so, but maybe I was wrong.  Jens posted a patch
> to invalidate kernel buffers on an umount - if the problem persists
> with that patch, I still believe it is a hardware fault.

And I don't. One of the cdrtools Debian maintainers just wrote that the
patch does NOT solve the problem with the scenario described above in
the thread.

Regards,
Eduard.
-- 
Die Strafe des Lügners ist nicht, daß ihm niemand mehr glaubt,
sondern, daß er selbst niemanden mehr glauben kann.
		-- George Bernard Shaw

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Sun, Feb 08 2004, Eduard Bloch wrote:
> Moin John!
> John Bradford schrieb am Friday, den 06. February 2004:
> 
> > > > unmounted before an erase, when it is re-mounted, the stale data is
> > > > read from the device's own cache, which should have been invalidated
> > > > by the erase.
> > > 
> > > Is it realy a hardware issue?
> > 
> > I originally thought so, but maybe I was wrong.  Jens posted a patch
> > to invalidate kernel buffers on an umount - if the problem persists
> > with that patch, I still believe it is a hardware fault.
> 
> And I don't. One of the cdrtools Debian maintainers just wrote that the
> patch does NOT solve the problem with the scenario described above in
> the thread.

Perhaps another program has the device open still? In that case, we
don't invalidate the toc cache.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

Quote from Eduard Bloch <edi@gmx.de>:
> Moin John!
> John Bradford schrieb am Friday, den 06. February 2004:
> 
> > > > unmounted before an erase, when it is re-mounted, the stale data is
> > > > read from the device's own cache, which should have been invalidated
> > > > by the erase.
> > > 
> > > Is it realy a hardware issue?
> > 
> > I originally thought so, but maybe I was wrong.  Jens posted a patch
> > to invalidate kernel buffers on an umount - if the problem persists
> > with that patch, I still believe it is a hardware fault.
> 
> And I don't. One of the cdrtools Debian maintainers just wrote that the
> patch does NOT solve the problem with the scenario described above in
> the thread.

So if the device does cache stale data over an erase, do you think
that's not a hardware fault?

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Måns Rullgård]

mru@kth.se (Måns Rullgård) writes:

> John Bradford <john@grabjohn.com> writes:
>
>> Regardless of specs, I don't know what the majority of devices in the
>> real world actually do.  Maybe Jens and Alan, (cc'ed), can help.
>
> Just tested with an ASUS SCB-2408 in my laptop.  It gives read errors
> after doing a fast erase, just like it should.

FWIW, this was using Linux 2.6.2-rc3, sort of.

-- 
Måns Rullgård
mru@kth.se

Re: 2.6.0, cdrom still showing directories after being erased

[Tomas Zvala]

Martin Povolný wrote:

>>>>I.E.
>>>>
>>>>mount disc
>>>>view contents
>>>>unmount disc
>>>>erase disc - but don't erase the CD-R drive's cache of the media
>>>>mount disc
>>>>view old contents of the media from the CD-R drive's cache
>>>>        
>>>>
>
>That's it exactly.
>  
>
So after all my (s)wag was correct :)

So I took a quick look through ATAPI specification (I have to say I'm a 
user not a developer) and found nothing that would seem to flush that 
damn cache. So the problem is that some CD-R drives (probably the older 
ones) expect you to eject CD after burning (even a buffer/cache clearing 
after burn would seem logical to me) and there is nothing you can do 
about it (except buying different drive). Unfortunately it is not a 
kernel or cdrecord issue (if it was it could have been fixed:) ). I 
guess you'll just have to do with ejecting :). Sorry.


Tomas Zvala

Re: 2.6.0, cdrom still showing directories after being erased

[Derek Foreman]

On Tue, 3 Feb 2004, John Bradford wrote:

> Quote from mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=):
> > John Bradford <john@grabjohn.com> writes:
> >
> > >> That's not what he said and, I assure you that if he unmounted
> > >> it there would not be any buffers to flush. Execute `man umount`.
> > >
> > > I think the original poster was referring to the cache on the device.
> > >
> > > I.E.
> > >
> > > mount disc
> > > view contents
> > > unmount disc
> > > erase disc - but don't erase the CD-R drive's cache of the media
> > > mount disc
> > > view old contents of the media from the CD-R drive's cache
> >
> > If that's the case, the drive is broken.  We can't help that.
>
> Is it actually a requirement for drives to support anything other than
> a full erase properly?  Is the 'fast' erase valid per spec, or does it
> just happen to work on 99% of devices?  Is this problem reproducable
> if a full erase is done instead of a fast erase?
>
> I've added the original poster to the CC list.

"Blank" is a single scsi command, 3 bits of the command specify what type
of blanking to perform.  So cdrecord isn't doing something devious, it's
well defined in the MMC standard.

Just making cdrecord -eject at the end of the process will probably
workaround what is almost certainly a hardware bug.  or just eject the
disc by hand before attempting to re-use it.

I had an old writer that did much the same thing.  After burning a disc,
it would still see it as blank until you ejected and reloaded.

to Martin:
Does cdrecord -toc still show a valid toc after you blank the disc?
(definately buggy hardware)

And does ejecting and reloading the disc make things work as expected?

Re: 2.6.0, cdrom still showing directories after being erased

[Martin Povolný]

Dne: Tue, Feb 03, 2004 at 01:09:45PM -0600, Derek Foreman napsal:
> 
> Just making cdrecord -eject at the end of the process will probably
> workaround what is almost certainly a hardware bug.  or just eject the
> disc by hand before attempting to re-use it.

yes, -eject helps, as well as ejecting manually or ejecting using 'eject'

> 
> I had an old writer that did much the same thing.  After burning a disc,
> it would still see it as blank until you ejected and reloaded.
> 
> to Martin:
> Does cdrecord -toc still show a valid toc after you blank the disc?
> (definately buggy hardware)

no, it does not:

$ cdrecord -dev=/dev/cdrom -toc
Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling
scsidev: '/dev/cdrom'
devname: '/dev/cdrom'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.7'
Device type    : Removable CD-ROM
Version        : 0
Response Format: 1
Vendor_info    : 'HL-DT-ST'
Identifikation : 'RW/DVD GCC-4480B'
Revision       : '1.00'
Device seems to be: Generic mmc2 DVD-ROM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-2 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
cdrecord.mmap: Success. read toc: scsi sendcmd: no error
CDB:  43 00 00 00 00 00 00 00 04 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 4
cmd finished after 0.000s timeout 40s
cdrecord.mmap: Cannot read TOC header
cdrecord.mmap: Cannot read TOC/PMA
pie:martin:~

but I can still mount it, and see the erased data:

pie:martin:~
$ mount /cdrom/
pie:martin:~
$ ls /cdrom/
Beskydy2003-2004
  
> 
> And does ejecting and reloading the disc make things work as expected?

it does

-- 
Martin Povolný, xpovolny@fi.muni.cz, http://www.fi.muni.cz/~xpovolny

Re: 2.6.0, cdrom still showing directories after being erased

[Fox!MURDER]

Can you mount it even after issuing cdrecord -toc?

Tomas Zvala


Martin Povolný wrote:

>Dne: Tue, Feb 03, 2004 at 01:09:45PM -0600, Derek Foreman napsal:
>  
>
>>Just making cdrecord -eject at the end of the process will probably
>>workaround what is almost certainly a hardware bug.  or just eject the
>>disc by hand before attempting to re-use it.
>>    
>>
>
>yes, -eject helps, as well as ejecting manually or ejecting using 'eject'
>
>  
>
>>I had an old writer that did much the same thing.  After burning a disc,
>>it would still see it as blank until you ejected and reloaded.
>>
>>to Martin:
>>Does cdrecord -toc still show a valid toc after you blank the disc?
>>(definately buggy hardware)
>>    
>>
>
>no, it does not:
>
>$ cdrecord -dev=/dev/cdrom -toc
>Cdrecord-Clone 2.01a19 (i686-pc-linux-gnu) Copyright (C) 1995-2003 Jörg Schilling
>scsidev: '/dev/cdrom'
>devname: '/dev/cdrom'
>scsibus: -2 target: -2 lun: -2
>Warning: Open by 'devname' is unintentional and not supported.
>Linux sg driver version: 3.5.27
>Using libscg version 'schily-0.7'
>Device type    : Removable CD-ROM
>Version        : 0
>Response Format: 1
>Vendor_info    : 'HL-DT-ST'
>Identifikation : 'RW/DVD GCC-4480B'
>Revision       : '1.00'
>Device seems to be: Generic mmc2 DVD-ROM.
>Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
>Driver flags   : MMC-2 SWABAUDIO BURNFREE
>Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
>cdrecord.mmap: Success. read toc: scsi sendcmd: no error
>CDB:  43 00 00 00 00 00 00 00 04 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 00
>Sense Key: 0x5 Illegal Request, Segment 0
>Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
>Sense flags: Blk 0 (not valid)
>resid: 4
>cmd finished after 0.000s timeout 40s
>cdrecord.mmap: Cannot read TOC header
>cdrecord.mmap: Cannot read TOC/PMA
>pie:martin:~
>
>but I can still mount it, and see the erased data:
>
>pie:martin:~
>$ mount /cdrom/
>pie:martin:~
>$ ls /cdrom/
>Beskydy2003-2004
>  
>  
>
>>And does ejecting and reloading the disc make things work as expected?
>>    
>>
>
>it does
>
>  
>

Re: 2.6.0, cdrom still showing directories after being erased

[Tomas Zvala]

It could have been just a nice way to make the drive realize that the 
disk is no longer what the drive thinks it is :).

Tomas Zvala
btw. guys im sorry for posting with two names .. I sometimes forget to 
switch to my real name :(

Derek Foreman wrote:

>Sorry, that was really more to satisfy my curiosity than anything else.
>You don't need to read the TOC to mount the disc.
>  
>
>

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Tue, Feb 03 2004, Tomas Zvala wrote:
> Hi,
> I believe he meant to write he umounted it.
> The problem is that there is still some data left in CDRW's cache and it 
> needs to be emptied. That happens when CDRW is ejected and reinserted 
> (that is why windows burning software ie. Nero wants to eject the CDR/RW 
> when it gets written or erased).
> Maybe kernel could flush the buffers/caches or whatever is there when 
> CDROM gets mounted. But im afraid about compatibility with broken drives 
> such as LG.

There's no command to invalidate read cache, you are probably thinking
of the SYNC_CACHE command to flush dirty data to media (which is what LG
fucked up).

IMO, it's a user problem.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[Pavel Machek]

Hi!

> > I believe he meant to write he umounted it.
> > The problem is that there is still some data left in CDRW's cache and it 
> > needs to be emptied. That happens when CDRW is ejected and reinserted 
> > (that is why windows burning software ie. Nero wants to eject the CDR/RW 
> > when it gets written or erased).
> > Maybe kernel could flush the buffers/caches or whatever is there when 
> > CDROM gets mounted. But im afraid about compatibility with broken drives 
> > such as LG.
> 
> There's no command to invalidate read cache, you are probably thinking
> of the SYNC_CACHE command to flush dirty data to media (which is what LG
> fucked up).
> 
> IMO, it's a user problem.

Does not look like so.

mount
umount
cdrecord -blank
mount
see old data

That looks pretty bad. If there's no other solution, we might just
document it, but...
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

> mount
> umount
> cdrecord -blank
> mount
> see old data
> 
> That looks pretty bad. If there's no other solution, we might just
> document it, but...

I think cdrecord should be hacked to complain loudly if the device is
already mounted.  Regardless of the device cache not being cleared,
(which is a firmware bug, in my opinion), blanking a mounted device is
usually not what the user intended.  This is not a kernel problem as
such, and should be dealt with in userspace.

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Pavel Machek]

Hi!

> > mount
> > umount
> > cdrecord -blank
> > mount
> > see old data
> > 
> > That looks pretty bad. If there's no other solution, we might just
> > document it, but...
> 
> I think cdrecord should be hacked to complain loudly if the device is
> already mounted.  Regardless of the device cache not being cleared,
> (which is a firmware bug, in my opinion), blanking a mounted device is
> usually not what the user intended.  This is not a kernel problem as
> such, and should be dealt with in userspace.

But it is _not_ mounted at that point. User did no mistake.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: 2.6.0, cdrom still showing directories after being erased

[John Bradford]

Quote from Pavel Machek <pavel@suse.cz>:
> Hi!
> 
> > > mount
> > > umount
> > > cdrecord -blank
> > > mount
> > > see old data
> > > 
> > > That looks pretty bad. If there's no other solution, we might just
> > > document it, but...
> > 
> > I think cdrecord should be hacked to complain loudly if the device is
> > already mounted.  Regardless of the device cache not being cleared,
> > (which is a firmware bug, in my opinion), blanking a mounted device is
> > usually not what the user intended.  This is not a kernel problem as
> > such, and should be dealt with in userspace.
> 
> But it is _not_ mounted at that point. User did no mistake.

OK, then this proves that this thread has been going on _way_ too
long, because not only have we discussed both scenarios during the
course of it, but I have managed to confuse both of them in the same
post :-).

In the scenario you describe, where the disc is unmounted, there is
nothing for cdrecord to complain about.  All that could really be done
is to hack cdrecord to reset the device afterwards for broken devices,
which would presumably flush the device's own cache.  However, even
this may not be sufficient, as from reading another post in this
thread, it seems that we need to force the drive to report that the
media has changed before the kernel will flush _it's_ buffers.

Obviously, that could be worked around in the kernel, but I would
expect the device to report media changed if it's been erased,
(although whether that is part of the spec or not, I have no idea).

John.

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Thu, Feb 05 2004, Pavel Machek wrote:
> Hi!
> 
> > > I believe he meant to write he umounted it.
> > > The problem is that there is still some data left in CDRW's cache and it 
> > > needs to be emptied. That happens when CDRW is ejected and reinserted 
> > > (that is why windows burning software ie. Nero wants to eject the CDR/RW 
> > > when it gets written or erased).
> > > Maybe kernel could flush the buffers/caches or whatever is there when 
> > > CDROM gets mounted. But im afraid about compatibility with broken drives 
> > > such as LG.
> > 
> > There's no command to invalidate read cache, you are probably thinking
> > of the SYNC_CACHE command to flush dirty data to media (which is what LG
> > fucked up).
> > 
> > IMO, it's a user problem.
> 
> Does not look like so.
> 
> mount
> umount
> cdrecord -blank
> mount
> see old data
> 
> That looks pretty bad. If there's no other solution, we might just
> document it, but...

Nonsense. Even if the above was what the user did (I believe he didn't
umount the device before blanking it), then it'd be a hardware "bug".
It's common to require an eject to completely clear the cache.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[Pavel Machek]

Hi!

> > > > I believe he meant to write he umounted it.
> > > > The problem is that there is still some data left in CDRW's cache and it 
> > > > needs to be emptied. That happens when CDRW is ejected and reinserted 
> > > > (that is why windows burning software ie. Nero wants to eject the CDR/RW 
> > > > when it gets written or erased).
> > > > Maybe kernel could flush the buffers/caches or whatever is there when 
> > > > CDROM gets mounted. But im afraid about compatibility with broken drives 
> > > > such as LG.
> > > 
> > > There's no command to invalidate read cache, you are probably thinking
> > > of the SYNC_CACHE command to flush dirty data to media (which is what LG
> > > fucked up).
> > > 
> > > IMO, it's a user problem.
> > 
> > Does not look like so.
> > 
> > mount
> > umount
> > cdrecord -blank
> > mount
> > see old data
> > 
> > That looks pretty bad. If there's no other solution, we might just
> > document it, but...
> 
> Nonsense. Even if the above was what the user did (I believe he didn't
> umount the device before blanking it), then it'd be a hardware "bug".
> It's common to require an eject to completely clear the cache.

Later in the thread user said he did indeed do umount, and it is
reproducible for him.

Okay, we may be dealing with the buggy hardware at this point. Would
it make sense to tell the drive to flush it caches? If there's no
other possibility, we might want cdrecord to reset drive at the end of
blank and/or to make it eject...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: 2.6.0, cdrom still showing directories after being erased

[Jens Axboe]

On Thu, Feb 05 2004, Pavel Machek wrote:
> Hi!
> 
> > > > > I believe he meant to write he umounted it.
> > > > > The problem is that there is still some data left in CDRW's cache and it 
> > > > > needs to be emptied. That happens when CDRW is ejected and reinserted 
> > > > > (that is why windows burning software ie. Nero wants to eject the CDR/RW 
> > > > > when it gets written or erased).
> > > > > Maybe kernel could flush the buffers/caches or whatever is there when 
> > > > > CDROM gets mounted. But im afraid about compatibility with broken drives 
> > > > > such as LG.
> > > > 
> > > > There's no command to invalidate read cache, you are probably thinking
> > > > of the SYNC_CACHE command to flush dirty data to media (which is what LG
> > > > fucked up).
> > > > 
> > > > IMO, it's a user problem.
> > > 
> > > Does not look like so.
> > > 
> > > mount
> > > umount
> > > cdrecord -blank
> > > mount
> > > see old data
> > > 
> > > That looks pretty bad. If there's no other solution, we might just
> > > document it, but...
> > 
> > Nonsense. Even if the above was what the user did (I believe he didn't
> > umount the device before blanking it), then it'd be a hardware "bug".
> > It's common to require an eject to completely clear the cache.
> 
> Later in the thread user said he did indeed do umount, and it is
> reproducible for him.
> 
> Okay, we may be dealing with the buggy hardware at this point. Would
> it make sense to tell the drive to flush it caches? If there's no
> other possibility, we might want cdrecord to reset drive at the end of
> blank and/or to make it eject...

Just have cdrecord eject the disc, it's pretty common. Resetting the
drive is a bit drastic, imho.

-- 
Jens Axboe

Re: 2.6.0, cdrom still showing directories after being erased

[Pavel Machek]

Hi!

> > Okay, we may be dealing with the buggy hardware at this point. Would
> > it make sense to tell the drive to flush it caches? If there's no
> > other possibility, we might want cdrecord to reset drive at the end of
> > blank and/or to make it eject...
> 
> Just have cdrecord eject the disc, it's pretty common. Resetting the
> drive is a bit drastic, imho.

It is less drastic than having user close the tray... (Many notebook
drives can eject but need human to close).
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]