On December 29, 2002 10:39 PM, Ben Fennema wrote:
2.4 behaves very pourly when writing to a very slow device (such as a CD-RW).
I tried to recompile the kernel with the preemtible patch Damjan Bole mentioned on this list (thanks). The performance has improved a lot. Althouth still being rather slow during writing to a CDRW, the machine is at least not completely frozen. In the future I hope for further improvement in this respect, but for now I consider this problem solved to sufficient extent.
The copy can return before all the data is written to disc. Unmounting just forces a sync, so all the rest of the data has to be written out before the disc unmounts.
BTW, if you run a diff with the data on the CD-RW and the original data, are there any differences?
I tried to put three huge files (tar archives) on the disc. After unmounting and remounting I tried to diff the files. It went through without any errors. I have never experienced any data inconsistency or loss unless I made a mistake mounting the disc or the disc developed bad blocks.
Were you using UDF from CVS? If not, you wern't using the latest version.
Make sure CONFIG_NLS was defined. If not, iocharset doesn't exist as an
You are right. My mistake. option. Again, you were right. When I recompiled the 2.4-20 kernel with this NLS, I could use the option again.
Another problem was when I tried to read the CD under MS Windows 2000 (built in UDF reader). Filenames with special characters were mangled and I was unable to open the files. I understand that for the Slovak language Windows uses a 852 codepage while Unix uses ISO-8859-2, but is not UDF supposed to use UTF-16 encoding (and any filename written to a UDF disk appropriately converted)?
UDF uses Unicode (8 or 16 bits, depending). The only testing with foreign languages I've done is using UTF-8 and Japanese, and it seemed to work right.
This is the only problem I have not been able to make any progress on at all. I resorted to experimenting on a hard disk partition, which I formated using UDF, to make sure it had nothing to do with packet writing (and save my burner and CD-RW media). I did the following test: I set the samba server to 825 codepage (client side) and ISO-8859-2 charset (server side). I created files with various national characters in their names in my public_html directory. I listed the contents of the directory on my Windows machine, the web browser being set to ISO-8859-2 encoding. All filenames showed correct. In this way I verified that the samba server had done all the translations correctly and that the files had correct names in the ISO-8859-2 encoding. Next I mounted a UDF volume with iocharset set to ISO-8859-2 and copied the files there. When I listed the contents of the directory, I got back rather different filenames. It seemed to me, that accented characters (that also exist in West European countries) were correct, but most of the other characters were mangled. However, without using the iocharset option I was not able to create some files at all. Another problem was that I was not able to use UTF-8 and iocharset at the same time. I would like to know, what takes care for the ISO-8859-x <-> UTF16 transcoding. It seems to me that the system lacks something for ISO-8859-2 and falls back to ISO-8859-1. Thanks, Robert Szelepcsenyi