[ Patch for 2.0.36 attached. 2.1.131ac4 could be changed similarly. ]
Both 2.0.36 and 2.1.131ac4 may have problems reading some cd-roms with very
large files (> ~68 MB) on them. With a customer-burnt Joliet level 3 cd-rom
on 2.0.36, I got an error message like
isofs_read_level3_size: More than 100 file sections ?!?, aborting...
isofs_read_level3_size: inode=54028 ino=61662
when doing `ls -l /mnt/cdrom', and the resulting listing showed a too small
size of the large file:
-r--r--r-- 1 root root 3249056 dec 1 11:34 kimenu1067.zip
-r--r--r-- 1 root root 68143104 dec 1 13:04 kimenu225.zip
The real size of the large file is 111601228 bytes as evidenced by a fixed
kernel (or reading it on Winblows NT 4.0SP3). Trying to _read_ the large
file with zipinfo(1) on 2.0.36 filled up the kernel message buffer with error
messages like above, hanging for a minute or two, and then an error message
from zipinfo(1) ("End-of-central-directory signature not found [...]").
So both listing and reading a large file is broken in the Linux kernels -- or
they aren't as flexible reading broken cd-roms as they should be, IMHO. I
don't know what program burnt that cd-rom; probably some broken NT app did.
Anyhow, it's quite easy to make the Linux kernel read this cd-rom flawlessly.
The "100" in the kernel error is hardcoded into the printk and the test, and
also appears in another function of the isofs code (isofs_bmap). All of them
should be replaced by a #define'd constant with a value larger than 100. In
the attached patch I introduce the constant MAX_FILE_SECTIONS with value 1000.
That should allow for a file about 10 times larger than the 68143104 bytes
(65.0 MB) listed above, i.e. 650 MB, exactly the size of a normal cheap
cd-rom. On second thought, it probably should be a bit larger, to allow for
newer, higher capacity cd-roms (and DVD's?), but I've only tested the 1000,
and only on this example cd-rom.
Further testing is encouraged, with larger files, and also on 2.1.x kernels...
To complete the test information, both the stock and patched kernel say this
about my test cd-rom:
ISO9660 Extensions: Microsoft Joliet Level 3
Max size:57832 Log zone size:2048
First datazone:33 Root inode number 67584
but only the patched kernel can list and read it correctly without errors.
The patch is gzip'ed and base64-encoded due to very long lines (>80 chars).
What do the ISO standards say on this? If they put a limit of 100 file
sections, then it might be reasonable to give a _warning_ about it. But if
we can handle more without severe problems, then we should do so.
-- Ulrik Dickow, Systems Programmer Snail Mail: Kampsax Technology Phone: +45 36 39 08 00 Stamholmen 112 Fax: +45 36 77 03 01 DK-2650 Hvidovre WWW: http://www.kampsax.dk/technology/ Denmark
--Multipart_Sun_Dec__6_22:05:49_1998-1 Content-Type: application/octet-stream; type=gzip Content-Disposition: attachment; filename="linux-2.0.36-isofs-inode-ukd1.patch.gz" Content-Transfer-Encoding: base64
H4sICMbdajYCA2xpbnV4LTIuMC4zNi1pc29mcy1pbm9kZS11a2QxLnBhdGNoAJ1UXVPaQBR9 Jr/i1I4z4CYBjGYAC2KRWiofHdHah85kQrLITkKWyYdaO/3v3d0Ag6LVNg+b7N6959x7zm4M w0DIouze2DcrpmWXp0mZJVyOEfep6ZnJjC0W1C+MswhDfovqIar1hmU1qpb4qNc0QsjfIVTq KfUAW6Ye1BvVep7absOw9nUbRIwCr93WgL2yhvc+nbKIonc2HF10neuL0fDMGVz1L3vOt1H/ atB1xl+7nbEGjZT3NII9nGDG59SYZHGU4gsPGU0R0lsawoLnGzGf446lM7ioVioYfMQDW2DK QoqZ62POY4p05kYKS+5QoYR6KeNRoiPhIkxFn3OWIpnxLPQxEXM3vqGxypRDagLX4gWf00Qm KLjeeFS37QqS1I18N/aRuD+PgeJVGLMAp8wL+B0+ZIHfDtz5InHvTT9olWRqWSMrJQYn351P vb5ovNu57I2GY1llRSNCKzYVe9Dvnpw7nc/dzrkmmVLmgQkpvBn1AmfuhiH30ETl6JnoJKZC AxWUjtgHtl4DsQ8tva4sKRQKEb1PhZ1ikxiNVmYqhx1mMkeGnKVSjogeqQS2yNKimJXUVDPk 0rRICENLVl7CL7VWWMSijqC4k+NN5u6igcHKjW0ncPzuWIc74bEo58Y0zR/RjqAgm/BbUkky 8jrZrv86l54DIX+2mfLmnyUSYjR3wwwT4UTQVGRxkgrxmrsZEvZA5Xups9yo2LDBpq6T0WJS ZD2H0dcgOopZlLCbiPolCaavoFYlxTQVd2Ptca0mzCV23darldzktb1rEpnJloem4PPcMiHz Ew8fNyvPkqNunuXIQv7ZToW5bPlFTFWmknNDrScK5c2Tdckvnou3N/CWI6Ig/6/+rQr1TbDn usMjZ8Xst/gn/gGyMRmz1QUAAA==
--Multipart_Sun_Dec__6_22:05:49_1998-1--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/