Hello.
Today I faced an interesting situation while trying to copy iso image from
one CDR to another. This may be a bug in the kernel.
First I grabbed the iso image to a file in /tmp, which is tmpfs on my
system.
Then I tried to write it using cdrecord at speed 24, and got an i/o error
that looked like buffer underrun.
I insered another disk and repeated write attempt. And got i/o error again
almost at the same byte offset (459716608 first time, 459399168 second
time).
Then I turned off DMA for CD recorder (hdparm -d0 /dev/hdc) and tried
again. DMA really was turned off, because CPU load meter on my desktop
started to show high CPU usage in system mode. But again, I got i/o error
almost at that offset.
I was able to write the image only after I copied it from tmpfs to my home
directory on reiserfs (file was copied without any errors).
No other activity was performed on the computer at the same time. Just KDE
desktop was running.
Computer on which it happened has only 256M of RAM, and iso file size was
about 700M. So large parts of the file in tmpfs actually resided in swap.
It seems that several times it took tmpfs unacceptably long to deliver
same part of the file to the reading process. Since it was the same part
of the file, I thought that these particular blocks (located on
particular blocks of the swap partition) could trigger some situation
when tmpfs misbehaves.
In past I also had some i/o errors when writing CDRs from tmpfs at high
speed, but those were much less deterministic.
I realize that the above information is poor to locate a bug (if there is
one). So it will be OK if this mail will be just ignored. But if I can
help, I will provide any needed technical information or run tests (I
can't break dozens of CDRs, but a few is ok).
Please CC: to my e-mail since I am not on the list.
nikita@bliss:~> uname -a
Linux bliss 2.4.21-rc2 #1 ??? ??? 17 11:34:01 MSD 2003 i686 GNU/Linux
<it is a laptop; kernel has ACPI, cpufreq and cd-packet-writing patches
applied>
nikita@bliss:~> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Celeron(R) CPU 1.70GHz
stepping : 3
cpu MHz : 1561.922
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3119.51
nikita@bliss:~> dmesg | grep hd
Kernel command line: auto BOOT_IMAGE=Linux-2.4.21rc2 ro root=302
hdc=ide-scsi
ide_setup: hdc=ide-scsi
ide0: BM-DMA at 0xbc90-0xbc97, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xbc98-0xbc9f, BIOS settings: hdc:DMA, hdd:pio
hda: IC25N040ATCS04-0, ATA DISK drive
hdc: SONY CD-RW/DVD-ROM CRX820E, ATAPI CD/DVD-ROM drive
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63,
UDMA(100)
hdc: attached ide-scsi driver.
Cdrecord 2.01a16 (i686-pc-linux-gnu) Copyright (C) 1995-2003 J?rg
Schilling
cdrecord command line was:
cdrecord dev=0,0,0 -v driveropts=burnfree speed=24 x.iso
cdrecord error was:
cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB: 2A 00 00 03 6C D7 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: F1 00 03 00 03 5C B7 12 00 00 00 00 0C 00 00 00
Sense Key: 0x3 Medium Error, deferred error, Segment 0
Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
Sense flags: Blk 220343 (valid)
cmd finished after 8.998s timeout 40s
write track data: error after 459716608 bytes
On Wed, 3 Sep 2003, Nikita V. Youshchenko wrote:
>
> First I grabbed the iso image to a file in /tmp, which is tmpfs on my
> system.
> Then I tried to write it using cdrecord at speed 24, and got an i/o error
> that looked like buffer underrun.
> I insered another disk and repeated write attempt. And got i/o error again
> almost at the same byte offset (459716608 first time, 459399168 second
> time).
That's curious, I don't have an explanation for why 438MB should be
repeatably significant on your 256MB system. I'm pretty sure tmpfs
itself doesn't have any "438MB" coded into it! Maybe it tended to
to horrible seeking around swap at that point; maybe shrink_cache
got stuck too much on wait_on_page; I'm only guessing.
> I was able to write the image only after I copied it from tmpfs to my home
> directory on reiserfs (file was copied without any errors).
> ...
> Computer on which it happened has only 256M of RAM, and iso file size was
> about 700M. So large parts of the file in tmpfs actually resided in swap.
I'm sure you did the right thing, copying it to a grown-up filesystem.
tmpfs is fine while everything is in memory, and even when a little
overflowed to swap; but with so much on swap it's at the mercy of the
vagaries of the LRU lists, and swap allocation might work out far
from optimal for it. tmpfs use of swap is not something we've ever
tried to optimize for.
Perhaps something exceptionally stupid and avoidable occurs, I'll keep
your mail as reminder to investigate some day. But if most of your
file is going to be on disk, much better to keep it in a filesystem
which allocates disk blocks to files in a well-designed way, than to
rely on tmpfs use of swap.
> It seems that several times it took tmpfs unacceptably long to deliver
> same part of the file to the reading process. Since it was the same part
> of the file, I thought that these particular blocks (located on
> particular blocks of the swap partition) could trigger some situation
> when tmpfs misbehaves.
I'm assuming you ran it two or three times without rebooting or running
swapoff. In which case, I doubt that the same parts of the file got the
same swap blocks each time (the association is not persistent), so I
don't think it would be a problem with your swap partition itself.
Sorry for tmpfs wasting your CDs: trust your reiserfs next time.
Hugh
> tmpfs is fine while everything is in memory, and even when a little
> overflowed to swap; but with so much on swap it's at the mercy of the
> vagaries of the LRU lists, and swap allocation might work out far
> from optimal for it. tmpfs use of swap is not something we've ever
> tried to optimize for.
Hmm...
Until today I thought that it is a good administration style to create a
several gigabyte swap partition (which is normally almost unused, but
just for the case that some program needs much virtual memory), and use
tmpfs for /tmp.
I thought that it is good for two reasons - disk space is not wasted for
/tmp (and /tmp still has several gigabytes of space), and short-living
temporary files such as gcc intermediate files normally reside in memory,
which is more effective than using a filesystem on a disk.
If I understand you correctly, the above is not true at least for a
desktop system with 256M of RAM?
And what about LTSP server with 2 gigabytes of RAM (and 6 gigabytes of
swap) that normally runs 10-15 KDE sessions with mozilla's and
openoffice's?
> Perhaps something exceptionally stupid and avoidable occurs, I'll keep
> your mail as reminder to investigate some day.
Thank you.
On Wed, 3 Sep 2003, Nikita V. Youshchenko wrote:
> Until today I thought that it is a good administration style to create a
> several gigabyte swap partition (which is normally almost unused, but
> just for the case that some program needs much virtual memory), and use
> tmpfs for /tmp.
> I thought that it is good for two reasons - disk space is not wasted for
> /tmp (and /tmp still has several gigabytes of space), and short-living
> temporary files such as gcc intermediate files normally reside in memory,
> which is more effective than using a filesystem on a disk.
>
> If I understand you correctly, the above is not true at least for a
> desktop system with 256M of RAM?
I think it's unusual for a machine with 256M of RAM to use more
than ~512M for swap, but I certainly wouldn't advise you against it.
If you've plenty of spare disk, and you find that sometimes it is
almost all useful for swap, keep it that way. But I can't pretend
that tmpfs is efficient compared with other filesystems once it
gets into using swap.
> And what about LTSP server with 2 gigabytes of RAM (and 6 gigabytes of
> swap) that normally runs 10-15 KDE sessions with mozilla's and
> openoffice's?
Sorry, you'll know much more about configuring such systems than I do.
Hugh