ReadError "No accessrights" as root!
Hallo, Kernel 2.4.18 original, patched with packet2.4.18_patch, udftools 1.0.0.2b, IDE-Writer Teac 524E, Caching enabled in Kernel: I tried to use packetwriting for transporting data from one pc to another on CDRW. Now on 2 different RW's, containing the same data, i get an "access denied" message on some files and directories, when trying to see them with mc or ls (means, this files/dirs aren't to see, i see only the err-mess) - also when logged in as root. I think, this points to defect writing. Could that be because write caching enabled? Greetings-- Email:KOALASOFT@GMX.DE
I also have this problem, with cache enabled, but with cache disabled i don't have this problem. Also i have corrupted files, i think that is the cache option. El Miércoles 05 Junio 2002 19:00, ulrich mensfeld escribió:
Hallo,
Kernel 2.4.18 original, patched with packet2.4.18_patch, udftools 1.0.0.2b, IDE-Writer Teac 524E, Caching enabled in Kernel:
I tried to use packetwriting for transporting data from one pc to another on CDRW. Now on 2 different RW's, containing the same data, i get an "access denied" message on some files and directories, when trying to see them with mc or ls (means, this files/dirs aren't to see, i see only the err-mess) - also when logged in as root.
I think, this points to defect writing. Could that be because write caching enabled?
Greetings--
Email:KOALASOFT@GMX.DE
Hallo Mario Medina Nussbaum ,
I also have this problem, with cache enabled, but with cache disabled i don't have this problem. Also i have corrupted files, i think that is the cache option.
I'm trying Peters advice with 2.4.19-pre4-patch, and will disable caching. I'll write what happens when writing to a fresh formatted cdrw. Do you have the same burner as i?
"access denied" message on some files and directories, when trying to see them with mc or ls (means, this files/dirs aren't to see, i see only the err-mess) - also when logged in as root.
I think, this points to defect writing. Could that be because write caching enabled?
Greetings-- Email:KOALASOFT@GMX.DE
HI [Teac 524E, Kernel 2.4.18]
I'm trying Peters advice with 2.4.19-pre4-patch, and will disable caching. I'll write what happens when writing to a fresh formatted cdrw. Do you have the same burner as i?
OK, here my experience: i patched the kernel with this patch, and some things have changed. When writing to my burner, it's LED's are flickering in complete other mode. Also the recording speed (my other mail) seems to be higher. I've compiled the kernel without caching enabled. But when rereading the written UDF-CDRW from my cdROM, i allways get errors on some files. I would say, about 1 of 100 files is corrupt. If i copy only some large files 1by1, all goes on. If i copy the whole /usr/src/linux, errors are there. I use following scripts to active my UDF-burning, if that's interesting: (i have a sym-link from the pktcvd-device to /dev/packet, which is used in all my scripts; and /dev/cdwriter is the symlink to the burner) script for formatting a cdrw: ---- #!/bin/sh cdrwtool -d /dev/cdwriter -q ----- script for mounting and activating UDF-CDRW: ---- #!/bin/sh pktsetup /dev/packet /dev/cdwriter mount /dev/packet /mnt/cdwriter -t udf -o rw,noatime ----- script for unmounting the UDF-CDRW: ---- #!/bin/sh umount /mnt/cdwriter pktsetup -d /dev/packet -----
On 8 Jun 2002, ulrich mensfeld wrote:
I'm trying Peters advice with 2.4.19-pre4-patch, and will disable caching. I'll write what happens when writing to a fresh formatted cdrw. Do you have the same burner as i?
OK, here my experience:
i patched the kernel with this patch, and some things have changed. When writing to my burner, it's LED's are flickering in complete other mode. Also the recording speed (my other mail) seems to be higher. I've compiled the kernel without caching enabled.
But when rereading the written UDF-CDRW from my cdROM, i allways get errors on some files. I would say, about 1 of 100 files is corrupt. If i copy only some large files 1by1, all goes on. If i copy the whole /usr/src/linux, errors are there.
I did a similar experiment with kernel 2.4.19-pre9 and packet-2.4.19-pre4. I created an ext2 filesystem with block size 2048 on a CDRW disc. I unpacked the 2.4.18 kernel tree to the CDRW disc, built the kernel, then cleaned up with "make mrproper". I then compared the tree on the CDRW with a tree on the hard disk, and 22 files (out of 10006) were corrupted. In all cases the corruption was limited to a 2Kb block beginning either at offset 0x5800 or 0x6000 in the file. In most cases the corrupted data looked like binary junk, but in a few cases the corrupted data consisted of pieces from other kernel source files. So there seems to be something wrong in the pktcdvd code causing corruption. (I doubt the ext2 filesystem is buggy and the udf filesystem wasn't even used.) -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hallo Peter Osterlund ,
I did a similar experiment with kernel 2.4.19-pre9 and packet-2.4.19-pre4. I created an ext2 filesystem with block size 2048 on a CDRW disc. I
? How does that work? Can we use cdrw like a normal ext2 harddrive? How? Greetings-- Email:KOALASOFT@GMX.DE
On 9 Jun 2002, ulrich mensfeld wrote:
Hallo Peter Osterlund ,
I did a similar experiment with kernel 2.4.19-pre9 and packet-2.4.19-pre4. I created an ext2 filesystem with block size 2048 on a CDRW disc. I
? How does that work? Can we use cdrw like a normal ext2 harddrive? How?
Yes, the pktcdvd module makes the cdrw look like a normal block device, so it should be possible to put any filesystem on top of it. The only potential problem is that the block size used by the file system must be supported by the block device. This is what I used for the test: pktsetup /dev/pktcdvd0 /dev/scd0 /sbin/mke2fs -b 2048 /dev/pktcdvd0 mount -t ext2 /dev/pktcdvd0 /mnt/tmp/ -onoatime By the way, the ext2 filesystem seemed to be quite a lot faster than udf when unpacking the kernel source. Is the udf filesystem using synchronous metadata updates or something? -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hallo Peter Osterlund ,
Yes, the pktcdvd module makes the cdrw look like a normal block device, so it should be possible to put any filesystem on top of it. The only potential problem is that the block size used by the file system must be supported by the block device. This is what I used for the test:
pktsetup /dev/pktcdvd0 /dev/scd0 /sbin/mke2fs -b 2048 /dev/pktcdvd0
Here i get allways the error: Input/output error while trying to determine filesystem size What could that be? i deleted the cdrw prior to this try with cdrecord blank=fast speed=4, and it is a 700MB CDRW. my mke2fs is version 1.27 By the way: i'm using MD 8.2 with devfs filesystem, and i have a device /dev/pktcdvd, without the '0'. Could that being an issue? Should i create another blockdevice pktcdvd0? Speed-issues: Yesterday i made another try with udf, on a fresh 700MB 4x CDRW. Copying the kerneltree with cp -a /usr/src/linux /mnt/cdwriter needs about 80 minutes for about 150MB! (and as estimated, there were corrupted files again on the cd) Greetings-- Email:KOALASOFT@GMX.DE
On 9 Jun 2002, ulrich mensfeld wrote:
Hallo Peter Osterlund ,
Yes, the pktcdvd module makes the cdrw look like a normal block device, so it should be possible to put any filesystem on top of it. The only potential problem is that the block size used by the file system must be supported by the block device. This is what I used for the test:
pktsetup /dev/pktcdvd0 /dev/scd0 /sbin/mke2fs -b 2048 /dev/pktcdvd0
Here i get allways the error:
Input/output error while trying to determine filesystem size
What could that be? i deleted the cdrw prior to this try with cdrecord blank=fast speed=4, and it is a 700MB CDRW.
The disc must be formatted for packet writing with cdrwtool before you can put a filesystem on it. If you already have a disc with a udf filesystem, try the mke2fs command without blanking the disc first. (If you later want to go back to the udf filesystem, just use the mkudf program. There is no need for a full reformat.)
Speed-issues: Yesterday i made another try with udf, on a fresh 700MB 4x CDRW. Copying the kerneltree with cp -a /usr/src/linux /mnt/cdwriter needs about 80 minutes for about 150MB! (and as estimated, there were corrupted files again on the cd)
I think the speed issue is caused by two things: The udf filesystem seems to be inefficient at handling many small files. I don't know if that's caused by the current implementation or by something in the udf specification that requires such behaviour. The pktcdvd module is bypassing the the I/O elevator when creating write requests for the CDRW drive. This can make performance really suffer when there is a mixed read/write load. The 2.5 version of pktcdvd has fixed this problem, but a backport is not easy because it relies heavily on the new bio infrastructure in 2.5. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hallo Peter Osterlund ,
The disc must be formatted for packet writing with cdrwtool before you can put a filesystem on it. If you already have a disc with a udf filesystem,
Thanks, now it get it to work making an ext2-fs.
Speed-issues: Yesterday i made another try with udf, on a fresh 700MB 4x
The udf filesystem seems to be inefficient at handling many small files. I
The pktcdvd module is bypassing the the I/O elevator when creating write requests for the CDRW drive. This can make performance really suffer when
i copied the linux source-tree to the cdrw with ext2-fs now. My experiences on 'cp -a /usr/src/linux/* /mnt/cdwriter': After a short time my system 'freezes' nearly completely for about 15 minutes. That means, i couldn't use keyboard nor mouse, even the LED's numlock on the keyboard wouldn't react of the num-key. But the cdrw was blinking and was written obviously; and the system was allways working as an internetrouter for my son's windows-pc. Then at first i get back the mouse (i did that all under kde3, in some xterms); after some additional minutes the keyboard. This freeze never happened when copying to udf-fs. The whole copying-time was about 30 minutes. Another problem (or is that normal using ext2?): mounting the cdrw (after writing to it) in my cdrom instead of the burner, i couldn't see any files. Copying back the source-tree from the cdrw to /tmp/test works perfectly, without any read-errors or breaking the cp. But a diff between the copy in /tmp/test and the orginal in /usr/src/linux gives about 30 files not identically
there is a mixed read/write load. The 2.5 version of pktcdvd has fixed this problem, but a backport is not easy because it relies heavily on the new bio infrastructure in 2.5.
Is the 2.5 kernel worth a try? I'm running no system with special hardware, only a standard-pc with duron 800, matrox 100 and symbios-logic scsi. Would it be stable on this platform? What about the corrupted files? Is that managed in this version? Greetings-- Email:KOALASOFT@GMX.DE
On 9 Jun 2002, ulrich mensfeld wrote:
The udf filesystem seems to be inefficient at handling many small files.
The pktcdvd module is bypassing the the I/O elevator when creating write requests for the CDRW drive. This can make performance really suffer when
i copied the linux source-tree to the cdrw with ext2-fs now. My experiences on 'cp -a /usr/src/linux/* /mnt/cdwriter':
After a short time my system 'freezes' nearly completely for about 15 minutes. That means, i couldn't use keyboard nor mouse, even the LED's numlock on the keyboard wouldn't react of the num-key. But the cdrw was blinking and was written obviously; and the system was allways working as an internetrouter for my son's windows-pc. Then at first i get back the mouse (i did that all under kde3, in some xterms); after some additional minutes the keyboard.
This probably happens because all of your memory is filled up with dirty buffers waiting to be written to the CDRW. This means that all processes that tries to allocate memory may have to wait a very long time before memory becomes available. There was some talk on the linux kernel mailing list some time ago about limiting the amount of dirty data for slow devices, but I don't think any code has been written yet.
This freeze never happened when copying to udf-fs. The whole copying-time was about 30 minutes.
Maybe this is because the udf filesystem is slower for this case so there won't be so many dirty buffers laying around.
Another problem (or is that normal using ext2?): mounting the cdrw (after writing to it) in my cdrom instead of the burner, i couldn't see any files.
I would have thought it would work, but I don't have a CDROM drive to test this. Does the same thing work if you use the udf filesystem? Did the mount command succeed for the ext2 case or did you get some error message?
there is a mixed read/write load. The 2.5 version of pktcdvd has fixed this problem, but a backport is not easy because it relies heavily on the new bio infrastructure in 2.5.
Is the 2.5 kernel worth a try? I'm running no system with special hardware, only a standard-pc with duron 800, matrox 100 and symbios-logic scsi. Would it be stable on this platform?
I don't know if 2.5 will work with this setup. I guess the only way to find out is to try it. I wouldn't run 2.5 on a system containing important data though.
What about the corrupted files? Is that managed in this version?
I don't know what's causing the corruption, so I don't know if it is fixed. What did the corruption look like in your case? In my case the corruption was always a 2Kb block at file offset 0x5800 or 0x6000. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hallo Peter Osterlund ,
i copied the linux source-tree to the cdrw with ext2-fs now. My experiences on 'cp -a /usr/src/linux/* /mnt/cdwriter':
After a short time my system 'freezes' nearly completely for about 15
This probably happens because all of your memory is filled up with dirty buffers waiting to be written to the CDRW. This means that all processes
hmm, i have 512MB Ram and a swapspace of 256MB. Shouldn't that be enough for copying about 170MB?
Another problem (or is that normal using ext2?): mounting the cdrw (after writing to it) in my cdrom instead of the burner, i couldn't see any files.
I would have thought it would work, but I don't have a CDROM drive to test this. Does the same thing work if you use the udf filesystem? Did the mount command succeed for the ext2 case or did you get some error message?
The mount command gave no error, also a df -H says the amount auf used and free! space on /dev/cdrom. But a ls -l /mnt/cdrom gives only an empty dir. With udf there are no problems to have access through the cdrom.
Is the 2.5 kernel worth a try? I'm running no system with special
What about the corrupted files? Is that managed in this version?
I don't know what's causing the corruption, so I don't know if it is fixed. What did the corruption look like in your case? In my case the
How could i determine the art of corruption? In the moment i'd done only the diff. Could you give me some scenarious, what to test and how? Because i'm going out for a week, i can do further testing not before 16. june. Thanks for your feedback Greetings-- Email:KOALASOFT@GMX.DE
On 9 Jun 2002, ulrich mensfeld wrote:
Hallo Peter Osterlund ,
i copied the linux source-tree to the cdrw with ext2-fs now. My experiences on 'cp -a /usr/src/linux/* /mnt/cdwriter':
After a short time my system 'freezes' nearly completely for about 15
This probably happens because all of your memory is filled up with dirty buffers waiting to be written to the CDRW. This means that all processes
hmm, i have 512MB Ram and a swapspace of 256MB. Shouldn't that be enough for copying about 170MB?
Hmm, I guess it depends on how many other programs you are running. I have 1GB RAM and didn't see any freezes during the writing. The amount of available swap will probably not make a difference for this case. The problem is not that you are out of memory, it's just that all RAM is tied up to the cdrw and the only way to free it is to write it out to the excessively slow (compared to hard disks) CDRW device.
Another problem (or is that normal using ext2?): mounting the cdrw (after writing to it) in my cdrom instead of the burner, i couldn't see any files.
I would have thought it would work, but I don't have a CDROM drive to test this. Does the same thing work if you use the udf filesystem? Did the mount command succeed for the ext2 case or did you get some error message?
The mount command gave no error, also a df -H says the amount auf used and free! space on /dev/cdrom. But a ls -l /mnt/cdrom gives only an empty dir. With udf there are no problems to have access through the cdrom.
Are you sure it was really mounted as type ext2? Just run "mount" without arguments to see how it was mounted.
Is the 2.5 kernel worth a try? I'm running no system with special
What about the corrupted files? Is that managed in this version?
I don't know what's causing the corruption, so I don't know if it is fixed. What did the corruption look like in your case? In my case the
How could i determine the art of corruption? In the moment i'd done only the diff. Could you give me some scenarious, what to test and how?
Convert the corrupted and the original file with "hexdump" and diff the hexdump files. If you are using bash, you can do this in a single step like this: diff <(hexdump original_file) <(hexdump corrupted_file) Or just send me the corrupted files and tell me what kernel version you used for the test and I'll analyze this myself. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Sun, Jun 09, 2002 at 08:44:20PM +0200, Peter Osterlund wrote:
On 9 Jun 2002, ulrich mensfeld wrote:
Another problem (or is that normal using ext2?): mounting the cdrw (after writing to it) in my cdrom instead of the burner, i couldn't see any files.
I would have thought it would work, but I don't have a CDROM drive to test this. Does the same thing work if you use the udf filesystem? Did the mount command succeed for the ext2 case or did you get some error message?
The mount command gave no error, also a df -H says the amount auf used and free! space on /dev/cdrom. But a ls -l /mnt/cdrom gives only an empty dir. With udf there are no problems to have access through the cdrom.
Are you sure it was really mounted as type ext2? Just run "mount" without arguments to see how it was mounted.
Another posibility is the CDROM drive doesn't grok fixed packet tracks correctly, so all the blank spaces between the packets show up as valid blocks. UDF detects this and skips the link/lead-in/lead-out blocks, but ext2 wouldn't.. (though if this was the case, I'd be amazed it mounted at all) Ben
Hallo Ben Fennema ,
The mount command gave no error, also a df -H says the amount auf used and free! space on /dev/cdrom. But a ls -l /mnt/cdrom gives only an empty dir. With udf there are no problems to have access through the cdrom.
Are you sure it was really mounted as type ext2? Just run "mount" without arguments to see how it was mounted.
Another posibility is the CDROM drive doesn't grok fixed packet tracks correctly, so all the blank spaces between the packets show up as valid blocks. UDF detects this and skips the link/lead-in/lead-out blocks, but ext2 wouldn't.. (though if this was the case, I'd be amazed it mounted at all)
i mounted with mount -t ext2 /dev/cdrom /mnt/cdrom. Output from df -H: /dev/cdrom 568M 158M 381M 30% /mnt/cdrom Output from mount: /dev/cdrom on /mnt/cdrom type ext2 (ro) but a list -l gives nothing (total 0). Also with mc i can't see anything. If i mount the cdrw in the writer, i can see the files. Greetings-- Email:KOALASOFT@GMX.DE
Hallo Peter Osterlund ,
After a short time my system 'freezes' nearly completely for about 15
Hmm, I guess it depends on how many other programs you are running. I have 1GB RAM and didn't see any freezes during the writing. The amount of
Is the 2.5 kernel worth a try? I'm running no system with special I want to try it, but i get errors on Versions 2.5.18 and 2.5.21 when
Had there been changes between 2.4.18 and 2.4.19-pre10? Today i installed 2.4.19-pre10 with your patch 2.4.19-pre4. Now a 'cp -a linux' goes in about 2 minutes, then the cursor was back on console; and the writing to cdrw goes on in the "background". No temporary freezing of the system. trying patching them with packet-2.5.14. Have i to use Kernel-Version 2.5.14?
How could i determine the art of corruption? In the moment i'd done only the diff. Could you give me some scenarious, what to test and how?
I just copied back the linux-tree from the cdrw to my /tmp, and compared it there with the original: No differences this time! In the moment i'm copying the tree again to cdrw, using udf-format. So let's wait some minutes for the results :-) ..... OK, here are the results: I copied back the linuxtree from udf-cdrw to /tmp/linux. A diff gave about 15 files different. I made a hexdump-diff on 2, on the first diff gave me: 1,2c1,2 and 4,118c4,125 and on the second 510,634c510,634 (i don't know really what that means, but i seems, there is no common offset?). Greetings-- Email:KOALASOFT@GMX.DE
On 16 Jun 2002, ulrich mensfeld wrote:
Is the 2.5 kernel worth a try? I'm running no system with special I want to try it, but i get errors on Versions 2.5.18 and 2.5.21 when trying patching them with packet-2.5.14. Have i to use Kernel-Version 2.5.14?
I have uploaded a new patch for kernel 2.5.21. There are no new features, only keeping up with kernel changes. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (5)
-
Ben Fennema
-
koalasoft@gmx.de
-
koalasoft@onlinehome.de
-
Mario Medina Nussbaum
-
Peter Osterlund