Mailinglist Archive: packet-writing (92 mails)
| < Previous | Next > |
RE: Various problems with packet writing
- From: "Robert Szelepcsenyi" <robert@xxxxxxxxxx>
- Date: Mon, 6 Jan 2003 22:01:05 +0000 (UTC)
- Message-id: <NGBBIFPNCHFBHDDLAHNCKECACGAA.robert@xxxxxxxxxx>
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.
You are right. My mistake.
>Make sure CONFIG_NLS was defined. If not, iocharset doesn't exist as an
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
>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.
You are right. My mistake.
>Make sure CONFIG_NLS was defined. If not, iocharset doesn't exist as an
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
| < Previous | Next > |