public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eduard Bloch <edi@gmx.de>
To: John Bradford <john@grabjohn.com>
Cc: Martin Schlemmer <azarah@nosferatu.za.org>,
	Jens Axboe <axboe@suse.de>,
	Linux Kernel Mailing Lists <linux-kernel@vger.kernel.org>,
	alan@redhat.com
Subject: Re: 2.6.0, cdrom still showing directories after being erased
Date: Fri, 6 Feb 2004 00:31:13 +0100	[thread overview]
Message-ID: <20040205233113.GA10254@zombie.inka.de> (raw)
In-Reply-To: <200402040737.i147bJqq000455@81-2-122-30.bradfords.org.uk>

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.

  reply	other threads:[~2004-02-05 23:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-03 13:18 2.6.0, cdrom still showing directories after being erased Martin Povolný
2004-02-03 13:31 ` Måns Rullgård
2004-02-03 13:45 ` Richard B. Johnson
2004-02-03 15:00   ` Tomas Zvala
2004-02-03 15:24     ` Richard B. Johnson
2004-02-03 15:45       ` Tomas Zvala
2004-02-03 16:02       ` John Bradford
2004-02-03 16:17         ` Måns Rullgård
2004-02-03 16:35           ` John Bradford
2004-02-03 17:46             ` Martin Povolný
2004-02-03 18:02               ` Martin Povolný
2004-02-03 18:53               ` John Bradford
2004-02-03 19:03                 ` Måns Rullgård
2004-02-03 20:35                   ` Richard B. Johnson
2004-02-03 20:59                     ` John Bradford
2004-02-03 22:40                     ` Jens Axboe
2004-02-03 23:05                       ` Martin Schlemmer
2004-02-04  7:37                         ` John Bradford
2004-02-05 23:31                           ` Eduard Bloch [this message]
2004-02-06  7:58                             ` John Bradford
2004-02-08 10:15                               ` Eduard Bloch
2004-02-08 10:32                                 ` Jens Axboe
2004-02-08 11:06                                 ` John Bradford
2004-02-03 22:03                   ` Måns Rullgård
2004-02-03 19:31               ` Tomas Zvala
2004-02-03 19:09             ` Derek Foreman
2004-02-03 19:51               ` Martin Povolný
2004-02-03 19:56                 ` Fox!MURDER
     [not found]                   ` <Pine.LNX.4.58.0402031358450.770@uberdeity>
2004-02-03 21:07                     ` Tomas Zvala
2004-02-03 15:28     ` Jens Axboe
2004-02-05 18:23       ` Pavel Machek
2004-02-05 20:04         ` John Bradford
2004-02-05 21:06           ` Pavel Machek
2004-02-05 21:36             ` John Bradford
2004-02-05 20:41         ` Jens Axboe
2004-02-05 21:09           ` Pavel Machek
2004-02-05 21:12             ` Jens Axboe
2004-02-05 21:17               ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2004-02-05 20:33 Thomas Glanzmann
2004-02-05 20:54 ` Jens Axboe
2004-02-05 21:16   ` Thomas Glanzmann
2004-02-05 21:29     ` Jens Axboe
2004-02-05 21:41     ` John Bradford
2004-02-13 23:19   ` Pavel Machek
2004-02-05 21:24 Thomas Glanzmann
2004-02-05 21:31 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040205233113.GA10254@zombie.inka.de \
    --to=edi@gmx.de \
    --cc=alan@redhat.com \
    --cc=axboe@suse.de \
    --cc=azarah@nosferatu.za.org \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox