Hi all,
I have found a strange problem using cdrecord from an ext3 partition.
When burning a cd image (about 500Mb), with cdrecord -v to see some info,
after about 150Mb the percentage of fifo filled begins to drop, until the
burning fails. I though it was related to some buffer/cache issue, but
then I just copied the image to an ext2 partition (so the cache still
filled more, just reaching my ram size), and burnt perfect from the
ext2 partition.
So it looks like ext3 can not give a sustained read rate (not so much,
burning was at 8x). Fifo from ext2 never dropped below 99%.
Is this a bug or the answer is just 'never toast from a journaled fs' ?
Kernel: 2.4.13-ac5+bproc, controller is an Adaptec
Controller:
Adaptec AIC7xxx driver version: 6.2.4
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
Drives:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DDYS-T09170N Rev: S96H
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: IBM Model: DCAS-34330W Rev: S65A
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: CREATIVE Model: CD5230E Rev: 1.01
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 01 Lun: 00
Vendor: YAMAHA Model: CRW8424E Rev: 1.0j
Type: CD-ROM ANSI SCSI revision: 02
Settings:
Channel A Target 0 Negotiation Settings
User: 80.000MB/s transfers (40.000MHz, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
(ext2)
Channel A Target 1 Negotiation Settings
User: 80.000MB/s transfers (40.000MHz, offset 255, 16bit)
Goal: 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
Curr: 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
(ext3)
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.13-ac5-beo #1 SMP Tue Oct 30 00:10:00 CET 2001 i686
Interesting. I've burnt just fine with `cdrecord -v speed=20 dev=0,0,0
foo.iso` to an ATAPI Yamaha CRW2200 (2.4.13-ac1+freeswap). Lowest FIFO
reports are ~78%. I gave up my Plexwriter 8/20 a while back, so I'd look
at the aic7xxx driver.
---
Dan Chen [email protected]
GPG key: http://www.cs.unc.edu/~chenda/pubkey.gpg.asc
On Wed, 31 Oct 2001, J . A . Magallon wrote:
> Hi all,
>
> I have found a strange problem using cdrecord from an ext3 partition.
> When burning a cd image (about 500Mb), with cdrecord -v to see some info,
> after about 150Mb the percentage of fifo filled begins to drop, until the
> burning fails. I though it was related to some buffer/cache issue, but
> then I just copied the image to an ext2 partition (so the cache still
> filled more, just reaching my ram size), and burnt perfect from the
> ext2 partition.
>
> So it looks like ext3 can not give a sustained read rate (not so much,
> burning was at 8x). Fifo from ext2 never dropped below 99%.
>
> Is this a bug or the answer is just 'never toast from a journaled fs' ?
>
> Kernel: 2.4.13-ac5+bproc, controller is an Adaptec
>
> Controller:
> Adaptec AIC7xxx driver version: 6.2.4
> aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
> Drives:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: IBM Model: DDYS-T09170N Rev: S96H
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: IBM Model: DCAS-34330W Rev: S65A
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 00 Lun: 00
> Vendor: CREATIVE Model: CD5230E Rev: 1.01
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 01 Lun: 00
> Vendor: YAMAHA Model: CRW8424E Rev: 1.0j
> Type: CD-ROM ANSI SCSI revision: 02
>
> Settings:
> Channel A Target 0 Negotiation Settings
> User: 80.000MB/s transfers (40.000MHz, offset 255, 16bit)
> Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
> Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
> (ext2)
> Channel A Target 1 Negotiation Settings
> User: 80.000MB/s transfers (40.000MHz, offset 255, 16bit)
> Goal: 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
> Curr: 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
> (ext3)
>
>
"J . A . Magallon" wrote:
>
> Hi all,
>
> I have found a strange problem using cdrecord from an ext3 partition.
> When burning a cd image (about 500Mb), with cdrecord -v to see some info,
> after about 150Mb the percentage of fifo filled begins to drop, until the
> burning fails. I though it was related to some buffer/cache issue, but
> then I just copied the image to an ext2 partition (so the cache still
> filled more, just reaching my ram size), and burnt perfect from the
> ext2 partition.
>
> So it looks like ext3 can not give a sustained read rate (not so much,
> burning was at 8x). Fifo from ext2 never dropped below 99%.
>
> Is this a bug or the answer is just 'never toast from a journaled fs' ?
The ext3 read paths are basically identical to ext2. The whole
journalling thing only gets involved with writes.
> Kernel: 2.4.13-ac5+bproc, controller is an Adaptec
>
bproc? scyld distributed process thing, or something else?
Something strange is happening. Could you please investigate
further? For example:
dd if=/dev/zero of=foo bs-1024k count=600
time cat foo > /dev/null
How long does the `cat' take on ext2 and ext3?
-
On 20011031 Andrew Morton wrote:
>"J . A . Magallon" wrote:
>
>> Kernel: 2.4.13-ac5+bproc, controller is an Adaptec
>>
>
>bproc? scyld distributed process thing, or something else?
>
Yep.
>Something strange is happening. Could you please investigate
>further? For example:
>
> dd if=/dev/zero of=foo bs-1024k count=600
> time cat foo > /dev/null
>
>How long does the `cat' take on ext2 and ext3?
>
Tried several times. Basic script is:
rm -f foo
echo ext2 create:
time dd if=/dev/zero of=foo bs=1024k count=600
sync
echo ext2 read:
time cat foo > /dev/null
rm -f foo
and results a similar to this (but read below..):
ext2 create:
600+0 records in
600+0 records out
0.02user 5.73system 0:27.43elapsed 20%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (119major+18minor)pagefaults 0swaps
ext2 read:
0.24user 4.85system 0:27.57elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (100major+17minor)pagefaults 0swaps
ext3 create:
600+0 records in
600+0 records out
0.00user 12.20system 1:12.28elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (119major+18minor)pagefaults 0swaps
ext3 read:
0.19user 6.30system 1:21.73elapsed 7%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (100major+17minor)pagefaults 0swaps
Did you noticed that the ext3 was at 20MHz, and ext2 was at 40MHz ? I
will reformat the 20MHz drive and make 2 slices, one ext2 and one ext3
to be sure not to compare apples and oranges...
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.13-ac5-beo #1 SMP Tue Oct 30 00:10:00 CET 2001 i686
Followup to: <[email protected]>
By author: "J . A . Magallon" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Did you noticed that the ext3 was at 20MHz, and ext2 was at 40MHz ? I
> will reformat the 20MHz drive and make 2 slices, one ext2 and one ext3
> to be sure not to compare apples and oranges...
>
Doesn't work. Low block numbers (outer edge of the disk) is
invariably faster than high block numbers (inner edge of the disk) on
all drives that are even close to recent.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Wed, Oct 31, 2001 at 09:52:40AM -0800, H. Peter Anvin wrote:
> By author: "J . A . Magallon" <[email protected]>
> > Did you noticed that the ext3 was at 20MHz, and ext2 was at 40MHz ? I
> > will reformat the 20MHz drive and make 2 slices, one ext2 and one ext3
> > to be sure not to compare apples and oranges...
>
> Doesn't work. Low block numbers (outer edge of the disk) is
> invariably faster than high block numbers (inner edge of the disk) on
> all drives that are even close to recent.
So unmount and remount as ext2?
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
* Mike Castle <[email protected]> on Wed, Oct 31, 2001:
> On Wed, Oct 31, 2001 at 09:52:40AM -0800, H. Peter Anvin wrote:
> > By author: "J . A . Magallon" <[email protected]>
> > > Did you noticed that the ext3 was at 20MHz, and ext2 was at 40MHz ? I
> > > will reformat the 20MHz drive and make 2 slices, one ext2 and one ext3
> > > to be sure not to compare apples and oranges...
> >
> > Doesn't work. Low block numbers (outer edge of the disk) is
> > invariably faster than high block numbers (inner edge of the disk) on
> > all drives that are even close to recent.
>
> So unmount and remount as ext2?
>
ext2 == ext3
ext3 may as well be called ext2 2.5 if you want to think about it in the
non-marketing sense.
What you'd want to do is do the first test on a vanilla ext2 partition, and
then perform the second test on that same partition, mounted as ext3. That
way you aren't being slowed down by physical properties of the drive.
M. R.
On Wed, Oct 31, 2001 at 05:40:30PM -0600, M. R. Brown wrote:
> * Mike Castle <[email protected]> on Wed, Oct 31, 2001:
> > So unmount and remount as ext2?
> >
>
> ext2 == ext3
>
> What you'd want to do is do the first test on a vanilla ext2 partition, and
> then perform the second test on that same partition, mounted as ext3. That
> way you aren't being slowed down by physical properties of the drive.
That's what I said, just not in so many words.
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
On 20011102 J . A . Magallon wrote:
On 20011031 H. Peter Anvin wrote:
>
>
>That might work, although you might also have primed the cache; I would do
>a reboot in between.
>
I'm redoing the tests to post the numbers, but my question is one other:
could a sysct/proc-entry be added to force a cache cleanup ? I, say to kernel
'clean all the pages that are just cache'...much like sync dumps buffers.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.14-pre6-beo #4 SMP Thu Nov 1 17:30:48 CET 2001 i686