* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 13:16 ` Giuliano Pochini
@ 2001-10-23 13:26 ` Alan Cox
2001-10-23 15:24 ` Michael Schmitz
2001-10-23 19:59 ` Benjamin Herrenschmidt
2 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2001-10-23 13:26 UTC (permalink / raw)
To: Giuliano Pochini
Cc: Michael Schmitz, linuxppc-dev, Hollis Blanchard, Alan Cox,
Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 13:16 ` Giuliano Pochini
2001-10-23 13:26 ` Alan Cox
@ 2001-10-23 15:24 ` Michael Schmitz
2001-10-23 15:52 ` Alan Cox
2001-10-23 19:59 ` Benjamin Herrenschmidt
2 siblings, 1 reply; 13+ messages in thread
From: Michael Schmitz @ 2001-10-23 15:24 UTC (permalink / raw)
To: Giuliano Pochini
Cc: Michael Schmitz, linuxppc-dev, Hollis Blanchard, Alan Cox,
Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 15:24 ` Michael Schmitz
@ 2001-10-23 15:52 ` Alan Cox
2001-10-23 16:31 ` Michael Schmitz
0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2001-10-23 15:52 UTC (permalink / raw)
To: Michael Schmitz
Cc: Giuliano Pochini, Michael Schmitz, linuxppc-dev, Hollis Blanchard,
Alan Cox, Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 15:52 ` Alan Cox
@ 2001-10-23 16:31 ` Michael Schmitz
2001-10-23 16:51 ` Alan Cox
0 siblings, 1 reply; 13+ messages in thread
From: Michael Schmitz @ 2001-10-23 16:31 UTC (permalink / raw)
To: Alan Cox
Cc: Giuliano Pochini, Michael Schmitz, linuxppc-dev, Hollis Blanchard,
Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 16:31 ` Michael Schmitz
@ 2001-10-23 16:51 ` Alan Cox
2001-10-23 20:08 ` Michael Schmitz
0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2001-10-23 16:51 UTC (permalink / raw)
To: Michael Schmitz
Cc: Alan Cox, Giuliano Pochini, Michael Schmitz, linuxppc-dev,
Hollis Blanchard, Tom Rini, Martin Costabel
> '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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 16:51 ` Alan Cox
@ 2001-10-23 20:08 ` Michael Schmitz
2001-10-23 20:49 ` Alan Cox
0 siblings, 1 reply; 13+ messages in thread
From: Michael Schmitz @ 2001-10-23 20:08 UTC (permalink / raw)
To: Alan Cox
Cc: Michael Schmitz, Giuliano Pochini, linuxppc-dev, Hollis Blanchard,
Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 20:08 ` Michael Schmitz
@ 2001-10-23 20:49 ` Alan Cox
2001-10-24 7:21 ` Michael Schmitz
0 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2001-10-23 20:49 UTC (permalink / raw)
To: Michael Schmitz
Cc: Alan Cox, Michael Schmitz, Giuliano Pochini, linuxppc-dev,
Hollis Blanchard, Tom Rini, Martin Costabel
> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 20:49 ` Alan Cox
@ 2001-10-24 7:21 ` Michael Schmitz
0 siblings, 0 replies; 13+ messages in thread
From: Michael Schmitz @ 2001-10-24 7:21 UTC (permalink / raw)
To: Alan Cox
Cc: Michael Schmitz, Giuliano Pochini, linuxppc-dev, Hollis Blanchard,
Tom Rini, Martin Costabel
> > 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: hfs cdrom broken in 2.4.13pre
2001-10-23 13:16 ` Giuliano Pochini
2001-10-23 13:26 ` Alan Cox
2001-10-23 15:24 ` Michael Schmitz
@ 2001-10-23 19:59 ` Benjamin Herrenschmidt
2 siblings, 0 replies; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2001-10-23 19:59 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: linuxppc-dev, 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 ?
>
>> 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/
^ permalink raw reply [flat|nested] 13+ messages in thread