Subject: Re: The demise of DEV_BSIZE
To: None <firstname.lastname@example.org>
From: Ross Harvey <email@example.com>
Date: 10/07/1999 11:10:24
> From: John Kohl <firstname.lastname@example.org>
> I'm don't completely buy Ross Harvey's description of non-addressibility
> of audio blocks. My experience with my old SCSI Toshiba 3401-XA drive
> is that it was absolutely reliable in getting to the same audio frames
> when commanded.
> From: email@example.com (Wolfgang Solfrank)
> > Can someone propose a possible application for sector size != 2**n?
> Well, I was going to write something about it anyway, especially since it
> doesn't fit with the model that's currently discussed :-(.
> What I have in mind is the "CD/ROM XA Mixed Mode" format. These do have
> a form of ISO9660 filesystem. At least the directory structure is
> recorded in logical 2048 byte sectors (albeit the recording is a tiny
> little bit different from the standard CD/ROM 2048 byte sectors), and
> can have ordinary files recorded in this part of the disk, too. In
> addition to that, the format supports recording of "multimedia data".
> These are recorded with a blocksize of 2332 bytes (if I remember
> correctly, don't have the standard handy right now), since you don't
> need the same amount of error correction for this kind of data.
> This files maybe recorded with some interleaving, so you can for
> instance mix a video file and the corresponding audio file).
> I'm not sure, but I think that CDI disks are recorded in this format.
> What this means for the problem at hand is that support for this type
> of media would require a more dynamic handling of the blocksize.
> PS: BTW, there _are_ CD drives that can address audio sectors reliably.
Plextor drives are supposed to be really good at this, too.
OK, then let me ask you: Why would you ever want to go through the
bio/filesystem layer for this? Because your performance was too high and
you wanted an initial handicap due to the copying and the cache thrashing?
AFAIK, there are no players, no kernels, and no applications anywhere that
want to access any of the audio and video data in CD-DA, CD-i, CD-ROM/XA,
Photo CD, Karaoke CD, or Video CD via a bio or filesystem layer.
That is, I don't see any association between support for these (mostly dead)
formats and the bio/filesystem layer in the first place.
1. I don't understand why people are worrying about the one or two
36-bit DEC-10/20 disks (etc) that aren't six feet underground.
Quality requires focus, and you simply must decide to leave things
out when their value is less than some epsilon. Duhh.
2. I now think supporting sector size != 2^n is a good thing, as long
as it's defopt'ed out, defined away in cpp, and off by default.
I'm confused by the proposal to make it the **default** configuration.
I suppose it would let people format certain drives for funny sector
lengths. Question: is value > epsilon?
If, in the future, we start to support some bizarre device that no one
has yet identified, and also decide to be the only kernel in the world
that supports it through the bio/filesystem layer, THEN on that day we
could turn on the defopt! If someone wants to go through the trouble
of formating 1,837 byte sectors on their martian-mfr'ed hard drive, they
should have no trouble turning on a defopt. Focus! Value > e?
3. Idea: it might be kind of a cool security measure. Think of the problem
a hostile agent, who probably knows only windows, would have trying
to read your 439-byte sectors. :-)