public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* HFS bug
@ 2003-11-12 19:26 Charles Mason
  0 siblings, 0 replies; 2+ messages in thread
From: Charles Mason @ 2003-11-12 19:26 UTC (permalink / raw)
  To: zippel, linux-kernel


This may or may not be a bug, but I figured that sending out the message
would do better good than not sending one out at all:

when I run the command:

# mount -t hfs /dev/scd0 /mnt/cdrom 

The kernel gives an Oops that traces back to line buffer.c:2555 (kernel
version 2.4.23-pre1). I'd attach the Oops output, but I'm on a remote
machine now.

The BUG() macro is called because the block size requested to be read by
HFS (512 bytes) is not the same as the hardware block size set by the
SCSI drivers (2048 by default).  grow_buffers() wants whatever called it
to request a blocksize that is a multiple of get_hardsect_size().

I would have bothered myself to write a fix, since I firmly believe that
a CD could have an HFS filesystem, but the kernel code has grown so
complex that writing the code to perform the reads correctly would be
difficult.

My idea was to change buffer.c:2555 to just modify the requested block
size to fit the hardware block size, then return an offset into a buffer
where that requested (sub)block is.  For example, if you're requesting
512 bytes but the hardsect size is 2048.  Read a 2048 block, and offset
the buffer to (block_no % 4) * 512.  This may have worked, but it could
possibly have been slow too.

By the way, the offending code is the hfs/super.c:hfs_read_super() that
traces to hfs/sysdep.c:hfs_buffer_get() which calls sb_bread() and
further then to buffer.c:grow_buffers().  hfs_read_super() sets
mdb->s_blocksize to 512.  sb_bread will use the hardsect_size set by the
SCSI driver (drivers/scsi/sr.c:sr_init()).

Alas, if this information helps out, let me know -- I'm not on any
kernel mailing list.  Further information about my system is attached.

Sincerely,
Charles Mason
mason@csit.fsu.edu


Kernel: Linux 2.4.23-pre1 (generally tained with the nvidia module)
Hardware:  AMD XP 2500+ / 1GB RAM / nVidia mainboard/chipset
Distribution: Debian unstable


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: HFS bug
@ 2003-11-12 20:32 James Pearson
  0 siblings, 0 replies; 2+ messages in thread
From: James Pearson @ 2003-11-12 20:32 UTC (permalink / raw)
  To: Charles Mason, linux-kernel

> This may or may not be a bug, but I figured that sending out the message
> would do better good than not sending one out at all:
> 
> when I run the command:
> 
> # mount -t hfs /dev/scd0 /mnt/cdrom 
> 
> The kernel gives an Oops that traces back to line buffer.c:2555 (kernel
> version 2.4.23-pre1). I'd attach the Oops output, but I'm on a remote
> machine now.

You could try something like:

mount -r -t hfs -o loop /dev/scd0 /mnt/cdrom

Or, have a look at Roman Zippel's new HFS+/HFS driver at:

http://www.ardistech.com/hfsplus/

James Pearson



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-11-12 20:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-12 20:32 HFS bug James Pearson
  -- strict thread matches above, loose matches on Subject: below --
2003-11-12 19:26 Charles Mason

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox