Re: hfs cdrom broken in 2.4.13pre

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > > >> The last kernel I'm sure it worked fine is 2.4.7
> > > >
> > > > Mount it over loopback device.
> > >
> > > Why has that become necessary?
> >
> > Primarily because the glue in the middle isnt covering up for your CD-ROM
> > any more.
>
> No, really.  What's changed to break HFS cdrom support?

The cdcom code no longer permitting to fake a nonstandard block size? The
blocksize on CDs is always 2k IIRC, the HFS driver just can't cope with
that.

Besides - hasn't HFS CDROM support been broken since a long time? Or was
that HFS? :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Martin Costabel]

Michael Schmitz wrote:

> Besides - hasn't HFS CDROM support been broken since a long time? Or was
> that HFS? :-)

There was a slightly more informed discussion about this in August 2000
on the linux-kernel list. The bug was found in the scsi code and fixed
shortly afterwards by Jens Axboe, IIRC. This was in the good old days
when people thought the upcoming 2.4 kernel series would be stable and
bleeding-edge development would happen in a 2.5 series.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > Besides - hasn't HFS CDROM support been broken since a long time? Or was
> > that HFS? :-)
>
> There was a slightly more informed discussion about this in August 2000

One would hope so. All I remember about CDROMs is they use a different
blocksize which causes all sorts of funny side effects in generic code
that assumes the only sane blocksize is 512. Not having read l-k since '98
I missed that.

> on the linux-kernel list. The bug was found in the scsi code and fixed
> shortly afterwards by Jens Axboe, IIRC. This was in the good old days

So mounting HFS CDROMs no longer panics? But there's been other reports of
HFS bugs I think. HFS could use a larger overhaul, that might make
integrating HFS+ easier and either do away with the 512 byte blocksize
assumption or hide the conversion inside the HFS driver.
I know nothing about filesystems in general, much less HFS. If there was
another informed discussion on l-k on this topic I'd be happy to know.

> when people thought the upcoming 2.4 kernel series would be stable and
> bleeding-edge development would happen in a 2.5 series.

Ouch.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Giuliano Pochini]

> One would hope so. All I remember about CDROMs is they use a different
> blocksize which causes all sorts of funny side effects in generic code
> that assumes the only sane blocksize is 512.

No. The point is that filesystems should not make assumptions about
hardware block size (except it being power of 2 I believe). If there
was code in block layer to provide broken FS's compatibility and that
code has been removed, then we must fix the FS. Who's HFS maintainer ?

> So mounting HFS CDROMs no longer panics ?

They always worked fine for me.


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Alan Cox]

> > One would hope so. All I remember about CDROMs is they use a different
> > blocksize which causes all sorts of funny side effects in generic code
> > that assumes the only sane blocksize is 512.
>
> No. The point is that filesystems should not make assumptions about
> hardware block size (except it being power of 2 I believe). If there
> was code in block layer to provide broken FS's compatibility and that
> code has been removed, then we must fix the FS. Who's HFS maintainer ?

The hardware block size is 2048. The logical block size of the file system
is 512 bytes, Someone has to do reblocking. So the choices are

1;	We hack crap into the file systems
2:	We hack crap into the drivers
3:	We listen to Al Viro

#3 (using the loopback device) solves everything nicely - it just needs to
be implied automatically

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > One would hope so. All I remember about CDROMs is they use a different
> > blocksize which causes all sorts of funny side effects in generic code
> > that assumes the only sane blocksize is 512.
>
> No. The point is that filesystems should not make assumptions about
> hardware block size (except it being power of 2 I believe). If there
> was code in block layer to provide broken FS's compatibility and that
> code has been removed, then we must fix the FS. Who's HFS maintainer ?

Orphaned I think. But I agree it should be fixed. Using loopback on the
sly doesn't sound a lot cleaner than a reblocking hack in the HFS driver
:-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Alan Cox]

> > was code in block layer to provide broken FS's compatibility and that
> > code has been removed, then we must fix the FS. Who's HFS maintainer ?
>
> Orphaned I think. But I agree it should be fixed. Using loopback on the
> sly doesn't sound a lot cleaner than a reblocking hack in the HFS driver
> :-)

Believe me it is a lot lot cleaner. It isnt just HFS, its almost all file
systems. If you add a generic reblocking layer it ends up looking remarkably
like the loopback driver

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > Orphaned I think. But I agree it should be fixed. Using loopback on the
> > sly doesn't sound a lot cleaner than a reblocking hack in the HFS driver
> > :-)
>
> Believe me it is a lot lot cleaner. It isnt just HFS, its almost all file
> systems. If you add a generic reblocking layer it ends up looking remarkably
> like the loopback driver

'almost all file systems' means with respect to CDROM, or in general?
I can't quite believe something is so fundamentally wrong to affect all
filesystems...

By 'it should be fixed' I meant the HFS driver should be fixed to not
assume a fixed blocksize.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Alan Cox]

> 'almost all file systems' means with respect to CDROM, or in general?
> I can't quite believe something is so fundamentally wrong to affect all
> filesystems...
>
> By 'it should be fixed' I meant the HFS driver should be fixed to not
> assume a fixed blocksize.

The block size of the file system is 512 bytes. The block size of the media
is 2048 bytes. Two totally seperate things

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Benjamin Herrenschmidt]

>
>> One would hope so. All I remember about CDROMs is they use a different
>> blocksize which causes all sorts of funny side effects in generic code
>> that assumes the only sane blocksize is 512.
>
>No. The point is that filesystems should not make assumptions about
>hardware block size (except it being power of 2 I believe). If there
>was code in block layer to provide broken FS's compatibility and that
>code has been removed, then we must fix the FS. Who's HFS maintainer ?
>
>> So mounting HFS CDROMs no longer panics ?
>
>They always worked fine for me.

I don't know if there's still an active HFS maintainer. That is not
the only bugs in HFS. Locking is broken and HFS can easily deadlock
on an SMP box. I've been reported disk corruption with it, and
experienced corrupted file when written from linux occasionally,
I suspect something must be wrong with btree rebalancing.

I have done some work on locking (replacing most broken spinlocks with
semaphores) but never really finished it. Most people rely on HFS tools,
not on the HFS fs. I don't have the time to work more seriously on it,
but it would be an interesting project for someone motivated, especially
since you now have Apple's implementation to use as a reference ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > By 'it should be fixed' I meant the HFS driver should be fixed to not
> > assume a fixed blocksize.
>
> The block size of the file system is 512 bytes. The block size of the media
> is 2048 bytes. Two totally seperate things

Color me confused... It's clear now, thanks for your patience. Shutting
up, hunting for brown paper bag...

One final concern: your solution means we need (most of) loopback in the
kernel at all times, right? Makes it impossibe to build a kernel without
loopback, or with loopback as a module? Am I missing something still?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Alan Cox]

> kernel at all times, right? Makes it impossibe to build a kernel without
> loopback, or with loopback as a module? Am I missing something still?

You would need loopback in kernel or as a module. That isnt a big problem
in the sense that its no bigger than internal glue to do the job and in
fact is pretty small anyway (about 8K)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: hfs cdrom broken in 2.4.13pre

[Michael Schmitz]

> > kernel at all times, right? Makes it impossibe to build a kernel without
> > loopback, or with loopback as a module? Am I missing something still?
>
> You would need loopback in kernel or as a module. That isnt a big problem

And whatever your root filesystem, it better not rely on loopback for any
blocksize mangling. That's what I'm queasy about, mostly (plus the option
to build kernels without any loopback support, in case anyone wants that).

I'm sure that's been hashed out in excruciating detail, and someone's
thought of it.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/