Skip to contentSkip to conversation

some HFS CD-ROM's can't be read

Bug 13602 [email protected] 2 participants 7 messages Oct 28, 2010 – Jun 12, 2012 1 message not in the archive SCSI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

[email protected]

author
#1 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=13602

Christoph Hellwig <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

          Component|HFS/HFSPLUS                 |SCSI
         AssignedTo|[email protected]                  |[email protected]
            Product|File System                 |IO/Storage
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
#2 lore raw
Quoted 10 lines · On Thu, 2010-10-28 at 12:53 +0000, [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=13602

Christoph Hellwig <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

          Component|HFS/HFSPLUS                 |SCSI
         AssignedTo|[email protected]                  |[email protected]
            Product|File System                 |IO/Storage

Why is this actually a bug? Linux has never supported filesystem block sizes smaller than device ones ... we don't have the necessary RMW code for it. The sr driver supports 512 byte sectors but *only* if the CD was burned with them (which isn't always possible depending on CD burner) and the reader supports them. I'd need the dmesgs to be sure but i'd guess READ_CAPACITY on this cd returns 2048 as the block size.

James

author
#3 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=13602

--- Comment #4 from Anonymous Emailer <[email protected]> 2010-10-28 16:06:44 ---
Reply-To: [email protected]

Quoted 10 lines · On Thu, 2010-10-28 at 12:53 +0000, [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=13602

Christoph Hellwig <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

          Component|HFS/HFSPLUS                 |SCSI
         AssignedTo|[email protected]                  |[email protected]
            Product|File System                 |IO/Storage

Why is this actually a bug? Linux has never supported filesystem block sizes smaller than device ones ... we don't have the necessary RMW code for it. The sr driver supports 512 byte sectors but *only* if the CD was burned with them (which isn't always possible depending on CD burner) and the reader supports them. I'd need the dmesgs to be sure but i'd guess READ_CAPACITY on this cd returns 2048 as the block size.

James

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
author
#4 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=13602

Bill McGonigle <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

     Kernel Version|2.6.29.4-167.fc11.i586      |2.6.34.7-56.fc13.x86_64

--- Comment #5 from Bill McGonigle <[email protected]> 2010-10-28 16:40:30 --- @Christoph: good workaround. I can losetup my /dev/sr0 and mount the discs
(tested 1 anyway). I need to omit the session=1 option on the loopback but it
does mount that way. Just to be sure, I confirmed sr0 won't mount without the session option. Not sure what would happen if the data were on session=2.

For the HFS vs. SCSI question, I'm not clear why 22 out of 25 discs in this set work OK but the remaining 3 would not. They're factory-stamped discs, no idea how they were mastered.

The only dmesg I get is:

hfs: unable to set blocksize to 512
hfs: can't find a HFS filesystem on dev sr0.

This is now kernel 2.6.34.7-56.fc13.x86_64.

Not sure if it's helpful, but here are the /sys sizes:

[bfccomputing@zpm sr0]$ more pwd/queue/*size
::::::::::::::
/sys/block/sr0/queue/hw_sector_size
::::::::::::::
2048
::::::::::::::
/sys/block/sr0/queue/logical_block_size
::::::::::::::
2048
::::::::::::::
/sys/block/sr0/queue/max_segment_size
::::::::::::::
65536
::::::::::::::
/sys/block/sr0/queue/minimum_io_size
::::::::::::::
2048
::::::::::::::
/sys/block/sr0/queue/optimal_io_size
::::::::::::::
0
::::::::::::::
/sys/block/sr0/queue/physical_block_size
::::::::::::::
2048

I can't even say this is a feature implemented in MacOSX for compatibility that linux lacks - for all I know, they do some sort of loopback mount automagically if certain kinds of discs are detected.

I don't know if there are any linux equivalents for doing something similar by the kernel; one could imagine userland machinations that could do the right thing, though perhaps costly.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
author
#5 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=13602

--- Comment #6 from Christoph Hellwig <[email protected]> 2010-10-31 21:17:53 --- Old SGI, SUN and apparently mac systems did support CDROMs with 512 byte sectors. In MMC5 there is only a vague reference to them beeing supported by the deprecated block descriptors taken from older SPC specs in some drives.

Searching on the internet implies you need very specific CDROM drives to use the SGI/SUN 512 byte sector CDROMs.

I think we safely say there is no way to properly support this in Linux and we we can close this bug.

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
author
#6 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=13602

Alan <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
                 CC|                            |[email protected]
         Resolution|                            |WILL_NOT_FIX
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.