Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> > But it has to go somewhere, and 2.4 right now is unusable on two of my boxes > > with M/O drives. > > Reads can be pretty easily padded, but writes are a bit harder. Maybe > push it to some helper before the device queue sees it? For 2.4 the > best sd solution is probably to just make it able to handle these > requests. For M/O drives you can do it in the scsi layer. Doing it right in the block layer is not easy. Doing it cleanly and right I cant currently visualise a setu for. But I agree it belongs in the queueing layers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Mon, Feb 19 2001, Alan Cox wrote: > > So put 0 and sure anyone can submit I/O on the size that they want. > > Now the driver has to support padding reads, or gathering data to do > > a complete block write. This is silly. Sr should support 512b transfers > > just fine, but only because I added the necessary _hacks_ to support > > it. sd doesn't right now for instance. > > It is silly to be in the block layer, it is silly to be in each file system. > Perhaps it belongs in the block queueing/handling code or the caches > > But it has to go somewhere, and 2.4 right now is unusable on two of my boxes > with M/O drives. Reads can be pretty easily padded, but writes are a bit harder. Maybe push it to some helper before the device queue sees it? For 2.4 the best sd solution is probably to just make it able to handle these requests. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: > > Strange. The twelve or so CD readers I have here are all > > able to read 512-byte sectors. I am quite willing to believe > > I think most Plextor and Yamaha do, but it's not guaranteed to > be supported. And it definitely won't for ATAPI with ide-scsi. > > Strange. I just used ATAPI with ide-scsi as test. It works. Yeah it works because sr does read padding on drives that can't dish out 512b sectors... This is my point. > Setting hardsect_size to 2048 means: this hardware is unable > to use smaller blocks, give an error to whoever asks for > something smaller. Which is the case for some drives. The error now occurs when ext2 forcibly tries to set the block size. > Not setting hardsect_size at all means: I have no idea what this > hardware can do. Now it is up to the user. If the user tries > something the hardware cannot do, she will get EIO. > Limiting the user in advance is a bad idea. Ok agreed, just forcing 2048 is a bit harsh but it was nicer than letting sr bomb on 512b requests at the time. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> So put 0 and sure anyone can submit I/O on the size that they want. > Now the driver has to support padding reads, or gathering data to do > a complete block write. This is silly. Sr should support 512b transfers > just fine, but only because I added the necessary _hacks_ to support > it. sd doesn't right now for instance. It is silly to be in the block layer, it is silly to be in each file system. Perhaps it belongs in the block queueing/handling code or the caches But it has to go somewhere, and 2.4 right now is unusable on two of my boxes with M/O drives. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: > > A value of hardsect_size[] means: this is the smallest size > > the hardware can work with. It is therefore a serious mistake > > just to come with "a good guess". This value is used only > > You are defeating the entire purpose of having a hardware sector > size independently from the software block size. And 2kB is a > valid guess, apart from the drives that do 512 byte transfers too > 2kB is really the smallest transfer we can do. > > : And 2kB is a valid guess > > Strange. The twelve or so CD readers I have here are all > able to read 512-byte sectors. I am quite willing to believe I think most Plextor and Yamaha do, but it's not guaranteed to be supported. And it definitely won't for ATAPI with ide-scsi. Did you verify that changing block size works? Just curious. > that hardware exists that is unable to, but it is a bad idea > to refuse to mount filesystems just because of some "good guess" > that was not so good at all. By far most media used will be 2kB based, so it is a good guess. Of course we change it if we switch the block size. > So put 0 and sure anyone can submit I/O on the size that they want. > Now the driver has to support padding reads, or gathering data to do > a complete block write. This is silly. Sr should support 512b transfers > just fine, but only because I added the necessary _hacks_ to support > it. sd doesn't right now for instance. > > Please calm down. Removing this sr_hardsizes nonsense I'm perfectly calm. > is a good idea today. No padding reads involved. > If you disagree, please go slowly and state very explicitly > why you think I should be unable to mount ext2 filesystems with > a block size smaller than 2048 on my SCSI CD drive. I don't think you should be unable to, of course we would want to support 1kB ext2 and other file systems that want to change the block size. We are just disagreeing on how to do it. I don't think counting on being able to change the block size of a device at will always be reliable. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
> A value of hardsect_size[] means: this is the smallest size > the hardware can work with. It is therefore a serious mistake > just to come with "a good guess". This value is used only You are defeating the entire purpose of having a hardware sector size independently from the software block size. And 2kB is a valid guess, apart from the drives that do 512 byte transfers too 2kB is really the smallest transfer we can do. : And 2kB is a valid guess Strange. The twelve or so CD readers I have here are all able to read 512-byte sectors. I am quite willing to believe that hardware exists that is unable to, but it is a bad idea to refuse to mount filesystems just because of some "good guess" that was not so good at all. > to reject impossible sizes, and everywhere the kernel accepts 0 > meaning "don't know". [Minor correction to my previous note: hardsect_size[MAJOR_NR] = NULL; is fine, putting 512 is fine as well, but putting 0 does not work because of the get_hardsect_size() that doesnt check for 0.] So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. Please calm down. Removing this sr_hardsizes nonsense is a good idea today. No padding reads involved. If you disagree, please go slowly and state very explicitly why you think I should be unable to mount ext2 filesystems with a block size smaller than 2048 on my SCSI CD drive. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
> Someone has added
> /*
> * These are good guesses for the time being.
> */
> for (i = 0; i < sr_template.dev_max; i++) {
> sr_blocksizes[i] = 2048;
> sr_hardsizes[i] = 2048;
> }
> blksize_size[MAJOR_NR] = sr_blocksizes;
> hardsect_size[MAJOR_NR] = sr_hardsizes;
> setting of hardsect_size to drivers/scsi/sr.c.
>
> A value of hardsect_size[] means: this is the smallest size
> the hardware can work with. It is therefore a serious mistake
> just to come with "a good guess". This value is used only
You are defeating the entire purpose of having a hardware sector
size independently from the software block size. And 2kB is a
valid guess, apart from the drives that do 512 byte transfers too
2kB is really the smallest transfer we can do.
> to reject impossible sizes, and everywhere the kernel accepts 0
> meaning "don't know".
So put 0 and sure anyone can submit I/O on the size that they want.
Now the driver has to support padding reads, or gathering data to do
a complete block write. This is silly. Sr should support 512b transfers
just fine, but only because I added the necessary _hacks_ to support
it. sd doesn't right now for instance.
In my oppinion we are always going to have hacks like this unless we
add some generic support for < hardware submission of I/O. Simply
ignoring this issue only makes it worse.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
From: Jon Forsberg <[EMAIL PROTECTED]>
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024, fragment size = 1024
And the other:
Block size = 4096, fragment size = 4096
What happens:
# mount -t ext2 /dev/cdrom /cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/cdrom,
or too many mounted file systems
kern.log:
Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0).
I'm pretty sure both worked with 2.2.17.
You are being bitten by two bugs. By some coincidence I sent a
patch for the first one to Linus and Alan yesterday.
(That was fs/ext2/super.c - the same bug occurs in both 2.2 and 2.4.)
However, the second one will then still prevent you from mounting,
and it occurs only in 2.4.
Someone has added
/*
* These are good guesses for the time being.
*/
for (i = 0; i < sr_template.dev_max; i++) {
sr_blocksizes[i] = 2048;
sr_hardsizes[i] = 2048;
}
blksize_size[MAJOR_NR] = sr_blocksizes;
hardsect_size[MAJOR_NR] = sr_hardsizes;
setting of hardsect_size to drivers/scsi/sr.c.
A value of hardsect_size[] means: this is the smallest size
the hardware can work with. It is therefore a serious mistake
just to come with "a good guess". This value is used only
to reject impossible sizes, and everywhere the kernel accepts 0
meaning "don't know".
So, probably all will work fine if you change the second
2048 here to say 512 or 0. Or, if you, more drastically,
remove all references to sr_hardsizes[] from sr.c.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PROBLEM] 2.4.1 can't mount ext2 CD-ROM
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I can't. Both are ok according to debugfs and e2fsck and if I do 'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works. The one that doesn't work have a blocksize of 1024 according to debugfs: Block size = 1024, fragment size = 1024 And the other: Block size = 4096, fragment size = 4096 What happens: # mount -t ext2 /dev/cdrom /cdrom mount: block device /dev/cdrom is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/cdrom, or too many mounted file systems kern.log: Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0). I'm pretty sure both worked with 2.2.17. Please CC me. --zzed Feb 17 15:01:13 pc1 syslogd 1.3-3#33.1: restart. Feb 17 15:01:14 pc1 kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Feb 17 15:01:14 pc1 kernel: Inspecting /boot/System.map-2.4.1 Feb 17 15:01:14 pc1 kernel: Loaded 16115 symbols from /boot/System.map-2.4.1. Feb 17 15:01:14 pc1 kernel: Symbols match kernel version 2.4.1. Feb 17 15:01:14 pc1 kernel: No module symbols loaded. Feb 17 15:01:14 pc1 kernel: Linux version 2.4.1 (zzed@pc1) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 ons feb 14 12:35:41 CET 2001 Feb 17 15:01:14 pc1 kernel: BIOS-provided physical RAM map: Feb 17 15:01:14 pc1 kernel: BIOS-e820: 000a @ (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 000f (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 07deb000 @ 0010 (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 4000 @ 07eeb000 (ACPI data) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 07eef000 (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 1000 @ 07eff000 (ACPI NVS) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ (reserved) Feb 17 15:01:14 pc1 kernel: On node 0 totalpages: 32491 Feb 17 15:01:14 pc1 kernel: zone(0): 4096 pages. Feb 17 15:01:14 pc1 kernel: zone(1): 28395 pages. Feb 17 15:01:14 pc1 kernel: zone(2): 0 pages. Feb 17 15:01:14 pc1 kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=302 BOOT_FILE=/boot/vmlinuz hda=13410,15,63 hdc=scsi bttv.radio=1 hisax=36,2 Feb 17 15:01:14 pc1 kernel: ide_setup: hda=13410,15,63 Feb 17 15:01:14 pc1 kernel: ide_setup: hdc=scsi Feb 17 15:01:14 pc1 kernel: Initializing CPU#0 Feb 17 15:01:14 pc1 kernel: Detected 668.194 MHz processor. Feb 17 15:01:14 pc1 kernel: Console: colour VGA+ 80x25 Feb 17 15:01:14 pc1 kernel: Calibrating delay loop... 1333.65 BogoMIPS Feb 17 15:01:14 pc1 kernel: Memory: 125032k/129964k available (1364k kernel code, 4548k reserved, 604k data, 180k init, 0k highmem) Feb 17 15:01:14 pc1 kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Feb 17 15:01:14 pc1 kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Feb 17 15:01:14 pc1 kernel: CPU: Before vendor init, caps: 0383f9ff , vendor = 0 Feb 17 15:01:14 pc1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Feb 17 15:01:14 pc1 kernel: CPU: L2 cache: 128K Feb 17 15:01:14 pc1 kernel: Intel machine check architecture supported. Feb 17 15:01:14 pc1 kernel: Intel machine check reporting enabled on CPU#0. Feb 17 15:01:14 pc1 kernel: CPU: After vendor init, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: After generic, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Common caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Intel Celeron (Coppermine) stepping 03 Feb 17 15:01:14 pc1 kernel: Enabling fast FPU save and restore... done. Feb 17 15:01:14 pc1 kernel: Enabling unmasked SIMD FPU exception support... done. Feb 17 15:01:14 pc1 kernel: Checking 'hlt' instruction... OK. Feb 17 15:01:14 pc1 kernel: POSIX conformance testing by UNIFIX Feb 17 15:01:14 pc1 kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Feb 17 15:01:14 pc1 kernel: mtrr: detected mtrr type: Intel Feb 17 15:01:14 pc1 kernel: PCI: PCI BIOS revision 2.10 entry at 0xf0960, last bus=1 Feb 17 15:01:14 pc1 kernel: PCI: Using configuration type 1 Feb 17 15:01:14 pc1 kernel: PCI: Probing PCI hardware Feb 17 15:01:14 pc1 kernel: PCI: Discovered primary peer bus fe [IRQ] Feb 17 15:01:14 pc1 kernel: PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0 Feb 17 15:01:14 pc1 kernel: Linux NET4.0 for Linux 2.4 Feb 17 15:01:14 pc1 kernel: Based upon Swansea University Computer Society NET3.039 Feb 17 15:01:14 pc1 kernel: DMI 2.3 present. Feb 17 15:01:14 pc1 kernel: 45 structures occupying 1293 bytes. Feb 17 15:01:14 pc1 kernel: DMI table at 0x000F24C0. Feb 17 15:01:14 pc1 kernel: BIOS Vendor: Award Software, Inc. Feb 17 15:01:14 pc1
[PROBLEM] 2.4.1 can't mount ext2 CD-ROM
I have two ext2 CD-ROMs. One of them I can mount the normal way, the other I can't. Both are ok according to debugfs and e2fsck and if I do 'mount -t ext2 -o loop /dev/cdrom /cdrom' instead, both works. The one that doesn't work have a blocksize of 1024 according to debugfs: Block size = 1024, fragment size = 1024 And the other: Block size = 4096, fragment size = 4096 What happens: # mount -t ext2 /dev/cdrom /cdrom mount: block device /dev/cdrom is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/cdrom, or too many mounted file systems kern.log: Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0). I'm pretty sure both worked with 2.2.17. Please CC me. --zzed Feb 17 15:01:13 pc1 syslogd 1.3-3#33.1: restart. Feb 17 15:01:14 pc1 kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Feb 17 15:01:14 pc1 kernel: Inspecting /boot/System.map-2.4.1 Feb 17 15:01:14 pc1 kernel: Loaded 16115 symbols from /boot/System.map-2.4.1. Feb 17 15:01:14 pc1 kernel: Symbols match kernel version 2.4.1. Feb 17 15:01:14 pc1 kernel: No module symbols loaded. Feb 17 15:01:14 pc1 kernel: Linux version 2.4.1 (zzed@pc1) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 ons feb 14 12:35:41 CET 2001 Feb 17 15:01:14 pc1 kernel: BIOS-provided physical RAM map: Feb 17 15:01:14 pc1 kernel: BIOS-e820: 000a @ (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 000f (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 07deb000 @ 0010 (usable) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 4000 @ 07eeb000 (ACPI data) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ 07eef000 (reserved) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 1000 @ 07eff000 (ACPI NVS) Feb 17 15:01:14 pc1 kernel: BIOS-e820: 0001 @ (reserved) Feb 17 15:01:14 pc1 kernel: On node 0 totalpages: 32491 Feb 17 15:01:14 pc1 kernel: zone(0): 4096 pages. Feb 17 15:01:14 pc1 kernel: zone(1): 28395 pages. Feb 17 15:01:14 pc1 kernel: zone(2): 0 pages. Feb 17 15:01:14 pc1 kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=302 BOOT_FILE=/boot/vmlinuz hda=13410,15,63 hdc=scsi bttv.radio=1 hisax=36,2 Feb 17 15:01:14 pc1 kernel: ide_setup: hda=13410,15,63 Feb 17 15:01:14 pc1 kernel: ide_setup: hdc=scsi Feb 17 15:01:14 pc1 kernel: Initializing CPU#0 Feb 17 15:01:14 pc1 kernel: Detected 668.194 MHz processor. Feb 17 15:01:14 pc1 kernel: Console: colour VGA+ 80x25 Feb 17 15:01:14 pc1 kernel: Calibrating delay loop... 1333.65 BogoMIPS Feb 17 15:01:14 pc1 kernel: Memory: 125032k/129964k available (1364k kernel code, 4548k reserved, 604k data, 180k init, 0k highmem) Feb 17 15:01:14 pc1 kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Feb 17 15:01:14 pc1 kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Feb 17 15:01:14 pc1 kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Feb 17 15:01:14 pc1 kernel: CPU: Before vendor init, caps: 0383f9ff , vendor = 0 Feb 17 15:01:14 pc1 kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Feb 17 15:01:14 pc1 kernel: CPU: L2 cache: 128K Feb 17 15:01:14 pc1 kernel: Intel machine check architecture supported. Feb 17 15:01:14 pc1 kernel: Intel machine check reporting enabled on CPU#0. Feb 17 15:01:14 pc1 kernel: CPU: After vendor init, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: After generic, caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Common caps: 0383f9ff Feb 17 15:01:14 pc1 kernel: CPU: Intel Celeron (Coppermine) stepping 03 Feb 17 15:01:14 pc1 kernel: Enabling fast FPU save and restore... done. Feb 17 15:01:14 pc1 kernel: Enabling unmasked SIMD FPU exception support... done. Feb 17 15:01:14 pc1 kernel: Checking 'hlt' instruction... OK. Feb 17 15:01:14 pc1 kernel: POSIX conformance testing by UNIFIX Feb 17 15:01:14 pc1 kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Feb 17 15:01:14 pc1 kernel: mtrr: detected mtrr type: Intel Feb 17 15:01:14 pc1 kernel: PCI: PCI BIOS revision 2.10 entry at 0xf0960, last bus=1 Feb 17 15:01:14 pc1 kernel: PCI: Using configuration type 1 Feb 17 15:01:14 pc1 kernel: PCI: Probing PCI hardware Feb 17 15:01:14 pc1 kernel: PCI: Discovered primary peer bus fe [IRQ] Feb 17 15:01:14 pc1 kernel: PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0 Feb 17 15:01:14 pc1 kernel: Linux NET4.0 for Linux 2.4 Feb 17 15:01:14 pc1 kernel: Based upon Swansea University Computer Society NET3.039 Feb 17 15:01:14 pc1 kernel: DMI 2.3 present. Feb 17 15:01:14 pc1 kernel: 45 structures occupying 1293 bytes. Feb 17 15:01:14 pc1 kernel: DMI table at 0x000F24C0. Feb 17 15:01:14 pc1 kernel: BIOS Vendor: Award Software, Inc. Feb 17 15:01:14 pc1
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
From: Jon Forsberg [EMAIL PROTECTED]
I have two ext2 CD-ROMs. One of them I can mount the normal way,
the other I can't. Both are ok according to debugfs and e2fsck
and if I do
'mount -t ext2 -o loop /dev/cdrom /cdrom'
instead, both work.
The one that doesn't work have a blocksize of 1024 according to debugfs:
Block size = 1024, fragment size = 1024
And the other:
Block size = 4096, fragment size = 4096
What happens:
# mount -t ext2 /dev/cdrom /cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/cdrom,
or too many mounted file systems
kern.log:
Feb 18 14:54:34 pc1 kernel: VFS: Unsupported blocksize on dev sr(11,0).
I'm pretty sure both worked with 2.2.17.
You are being bitten by two bugs. By some coincidence I sent a
patch for the first one to Linus and Alan yesterday.
(That was fs/ext2/super.c - the same bug occurs in both 2.2 and 2.4.)
However, the second one will then still prevent you from mounting,
and it occurs only in 2.4.
Someone has added
/*
* These are good guesses for the time being.
*/
for (i = 0; i sr_template.dev_max; i++) {
sr_blocksizes[i] = 2048;
sr_hardsizes[i] = 2048;
}
blksize_size[MAJOR_NR] = sr_blocksizes;
hardsect_size[MAJOR_NR] = sr_hardsizes;
setting of hardsect_size to drivers/scsi/sr.c.
A value of hardsect_size[] means: this is the smallest size
the hardware can work with. It is therefore a serious mistake
just to come with "a good guess". This value is used only
to reject impossible sizes, and everywhere the kernel accepts 0
meaning "don't know".
So, probably all will work fine if you change the second
2048 here to say 512 or 0. Or, if you, more drastically,
remove all references to sr_hardsizes[] from sr.c.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote:
Someone has added
/*
* These are good guesses for the time being.
*/
for (i = 0; i sr_template.dev_max; i++) {
sr_blocksizes[i] = 2048;
sr_hardsizes[i] = 2048;
}
blksize_size[MAJOR_NR] = sr_blocksizes;
hardsect_size[MAJOR_NR] = sr_hardsizes;
setting of hardsect_size to drivers/scsi/sr.c.
A value of hardsect_size[] means: this is the smallest size
the hardware can work with. It is therefore a serious mistake
just to come with "a good guess". This value is used only
You are defeating the entire purpose of having a hardware sector
size independently from the software block size. And 2kB is a
valid guess, apart from the drives that do 512 byte transfers too
2kB is really the smallest transfer we can do.
to reject impossible sizes, and everywhere the kernel accepts 0
meaning "don't know".
So put 0 and sure anyone can submit I/O on the size that they want.
Now the driver has to support padding reads, or gathering data to do
a complete block write. This is silly. Sr should support 512b transfers
just fine, but only because I added the necessary _hacks_ to support
it. sd doesn't right now for instance.
In my oppinion we are always going to have hacks like this unless we
add some generic support for hardware submission of I/O. Simply
ignoring this issue only makes it worse.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
A value of hardsect_size[] means: this is the smallest size the hardware can work with. It is therefore a serious mistake just to come with "a good guess". This value is used only You are defeating the entire purpose of having a hardware sector size independently from the software block size. And 2kB is a valid guess, apart from the drives that do 512 byte transfers too 2kB is really the smallest transfer we can do. : And 2kB is a valid guess Strange. The twelve or so CD readers I have here are all able to read 512-byte sectors. I am quite willing to believe that hardware exists that is unable to, but it is a bad idea to refuse to mount filesystems just because of some "good guess" that was not so good at all. to reject impossible sizes, and everywhere the kernel accepts 0 meaning "don't know". [Minor correction to my previous note: hardsect_size[MAJOR_NR] = NULL; is fine, putting 512 is fine as well, but putting 0 does not work because of the get_hardsect_size() that doesnt check for 0.] So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. Please calm down. Removing this sr_hardsizes nonsense is a good idea today. No padding reads involved. If you disagree, please go slowly and state very explicitly why you think I should be unable to mount ext2 filesystems with a block size smaller than 2048 on my SCSI CD drive. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: A value of hardsect_size[] means: this is the smallest size the hardware can work with. It is therefore a serious mistake just to come with "a good guess". This value is used only You are defeating the entire purpose of having a hardware sector size independently from the software block size. And 2kB is a valid guess, apart from the drives that do 512 byte transfers too 2kB is really the smallest transfer we can do. : And 2kB is a valid guess Strange. The twelve or so CD readers I have here are all able to read 512-byte sectors. I am quite willing to believe I think most Plextor and Yamaha do, but it's not guaranteed to be supported. And it definitely won't for ATAPI with ide-scsi. Did you verify that changing block size works? Just curious. that hardware exists that is unable to, but it is a bad idea to refuse to mount filesystems just because of some "good guess" that was not so good at all. By far most media used will be 2kB based, so it is a good guess. Of course we change it if we switch the block size. So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. Please calm down. Removing this sr_hardsizes nonsense I'm perfectly calm. is a good idea today. No padding reads involved. If you disagree, please go slowly and state very explicitly why you think I should be unable to mount ext2 filesystems with a block size smaller than 2048 on my SCSI CD drive. I don't think you should be unable to, of course we would want to support 1kB ext2 and other file systems that want to change the block size. We are just disagreeing on how to do it. I don't think counting on being able to change the block size of a device at will always be reliable. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. It is silly to be in the block layer, it is silly to be in each file system. Perhaps it belongs in the block queueing/handling code or the caches But it has to go somewhere, and 2.4 right now is unusable on two of my boxes with M/O drives. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Sun, Feb 18 2001, [EMAIL PROTECTED] wrote: Strange. The twelve or so CD readers I have here are all able to read 512-byte sectors. I am quite willing to believe I think most Plextor and Yamaha do, but it's not guaranteed to be supported. And it definitely won't for ATAPI with ide-scsi. Strange. I just used ATAPI with ide-scsi as test. It works. Yeah it works because sr does read padding on drives that can't dish out 512b sectors... This is my point. Setting hardsect_size to 2048 means: this hardware is unable to use smaller blocks, give an error to whoever asks for something smaller. Which is the case for some drives. The error now occurs when ext2 forcibly tries to set the block size. Not setting hardsect_size at all means: I have no idea what this hardware can do. Now it is up to the user. If the user tries something the hardware cannot do, she will get EIO. Limiting the user in advance is a bad idea. Ok agreed, just forcing 2048 is a bit harsh but it was nicer than letting sr bomb on 512b requests at the time. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
On Mon, Feb 19 2001, Alan Cox wrote: So put 0 and sure anyone can submit I/O on the size that they want. Now the driver has to support padding reads, or gathering data to do a complete block write. This is silly. Sr should support 512b transfers just fine, but only because I added the necessary _hacks_ to support it. sd doesn't right now for instance. It is silly to be in the block layer, it is silly to be in each file system. Perhaps it belongs in the block queueing/handling code or the caches But it has to go somewhere, and 2.4 right now is unusable on two of my boxes with M/O drives. Reads can be pretty easily padded, but writes are a bit harder. Maybe push it to some helper before the device queue sees it? For 2.4 the best sd solution is probably to just make it able to handle these requests. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.4.1 can't mount ext2 CD-ROM
But it has to go somewhere, and 2.4 right now is unusable on two of my boxes with M/O drives. Reads can be pretty easily padded, but writes are a bit harder. Maybe push it to some helper before the device queue sees it? For 2.4 the best sd solution is probably to just make it able to handle these requests. For M/O drives you can do it in the scsi layer. Doing it right in the block layer is not easy. Doing it cleanly and right I cant currently visualise a setu for. But I agree it belongs in the queueing layers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
