cdrecord from ext3

cdrecord from ext3

[J . A . Magallon]

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:jamagallon@able.es
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

Re: cdrecord from ext3

[Daniel T. Chen]

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                 crimsun@email.unc.edu
GPG key: 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)
> 
> 

Re: cdrecord from ext3

[Andrew Morton]

"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?

-

Re: cdrecord from ext3

[J . A . Magallon]

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:jamagallon@able.es
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

Re: cdrecord from ext3

[H. Peter Anvin]

Followup to:  <20011031155934.A18608@werewolf.able.es>
By author:    "J . A . Magallon" <jamagallon@able.es>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: cdrecord from ext3

[Mike Castle]

On Wed, Oct 31, 2001 at 09:52:40AM -0800, H. Peter Anvin wrote:
> By author:    "J . A . Magallon" <jamagallon@able.es>
> > 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      dalgoda@ix.netcom.com      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

Re: cdrecord from ext3

[M. R. Brown]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

* Mike Castle <dalgoda@ix.netcom.com> on Wed, Oct 31, 2001:

> On Wed, Oct 31, 2001 at 09:52:40AM -0800, H. Peter Anvin wrote:
> > By author:    "J . A . Magallon" <jamagallon@able.es>
> > > 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: cdrecord from ext3

[Mike Castle]

On Wed, Oct 31, 2001 at 05:40:30PM -0600, M. R. Brown wrote:
> * Mike Castle <dalgoda@ix.netcom.com> 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      dalgoda@ix.netcom.com      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

Re: cdrecord from ext3 [jamagallon@able.es]

[J . A . Magallon]

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:jamagallon@able.es
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