Can anyone see a reason why a fsck would take substantially longer on one drive (Hitachi Travelstar 40GB) than another (Fujitsu 30GB)?

You can see in my boot log below where I timed a fsck on each drive. One took 12 minutes the other a little over two. The fast drive is about 25/30GB full and the the slow one is only about 15/40GB full.

The slow drive is the system drive if that could make any difference.

Any ideas? I just noticed when syncing on the checking media stage (I guess the fsck was due), that it was taking quite a long time so I did it myself manually.

There are no irq timeout etc errors that are quite often a sign of a dying drive. Am I paranoid?

Just found it a little strange that my brand new IBM would take that much longer to fsck than the original Fujitsu.

empeg-car bootstrap v1.02 20001106 ([email protected])

If there is anyone present who wants to upgrade the flash, let them speak now,

or forever hold their peace...it seems not. Let fly the Penguins of Linux!



e000 v1.04

Copying kernel...

Calling linux kernel...

Uncompressing Linux..................................... done, booting the kernel.

Linux version 2.2.17-rmk5-np17-empeg52-hijack-v320 (root@ibbm) (gcc version 2.95.3 20010315 (release)) #2 Wed Feb 19 21:53:19 EST 2003

Processor: Intel StrongARM-1100 revision 11

NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.

empeg-car player (hardware revision 9, serial number 40104192)

Command line: mem=16m

Calibrating delay loop... 207.67 BogoMIPS

Memory: 14996k/16M available (996k code, 20k reserved, 368k data, 4k init)

Dentry hash table entries: 2048 (order 2, 16k)

Buffer cache hash table entries: 16384 (order 4, 64k)

Page cache hash table entries: 4096 (order 2, 16k)

POSIX conformance testing by UNIFIX

Linux NET4.0 for Linux 2.2

Based upon Swansea University Computer Society NET3.039

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP

TCP: Hash tables configured (ehash 16384 bhash 16384)

IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)

IrCOMM protocol (Dag Brattli)

Starting kswapd v 1.5 

SA1100 serial driver version 4.27 with no serial options enabled

ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART

ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART

ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART

Signature is 206f6972 'rio '

Found custom animation at offset 0x9bbb0

empeg display initialised.

empeg dsp audio initialised

empeg dsp mixer initialised

empeg dsp initialised

empeg audio-in initialised, CS4231A revision a0

empeg remote control/panel button initialised.

empeg usb initialised, PDIUSBD12 id 1012

empeg state support initialised 0089/88c1 (save to d0005400).

empeg RDS driver initialised

empeg power-pic driver initialised (first boot)

RAM disk driver initialized:  16 RAM disks of 4096K size

empeg single channel IDE

Probing primary interface...

hda: IC25N040ATCS04-0, ATA DISK drive

hdb: FUJITSU MHL2300AT, ATA DISK drive

ide0 at 0x000-0x007,0x038 on irq 6

hda: IC25N040ATCS04-0, 38154MB w/1768kB Cache, CHS=4864/255/63

hdb: FUJITSU MHL2300AT, 28615MB w/2048kB Cache, CHS=58140/16/63

empeg-flash driver initialized

smc chip id/revision 0x3349

smc9194.c:v0.12 03/06/96 by Erik Stahlman ([email protected])



SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:28:10:60

Partition check:

 hda: hda1 < hda5 hda6 > hda2 hda3 hda4

 hdb: hdb1 < hdb5 hdb6 > hdb2 hdb3 hdb4

RAMDISK: ext2 filesystem found at block 0

RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.

EXT2-fs warning: checktime reached, running e2fsck is recommended

VFS: Mounted root (ext2 filesystem).

empeg-pump v0.03 (19980601)

Press Ctrl-A to enter pump...•Ô•j½Õ¹Ñ•‘�ɽ½Ñ�¡•áÑÉ�™¥±•ÍåÍÑ•µ¥�É•…‘½¹±å¹)5ÿchange_root: old root has d_count=1

Trying to unmount old root ... okay

Freeing unused kernel memory: 4k initempeg init 0.8

I see this is a developer image!

Mounting proc

Mounting first music partition

Tried to mount /dev/hda4 as reiserfs but got error 19

Mounting second music partition

Remounting first music partition read-only

Remounting second music partition read-only

Press 'q' now to go into development mode. You Have Zero Seconds To Comply...

Starting player



hijack: removed menu entry: "Hard Disk Detection"

khttpd: listening on port 80

kftpd: listening on port 21

  player.cpp        : 385:empeg-car 2.00-beta13 2002/07/24.

Prolux 4 empeg car - 2.1434 Jul 24 2002

Vcb: 0x4086d000

q

Restored terminal settings

Remounting first music partition read-only

Remounting second music partition read-only

Player exited normally: 0

Switching to shell-player loop

Starting bash.

empeg:/empeg/bin# ro

empeg:/empeg/bin# umount /dev/hda4

empeg:/empeg/bin# umount /dev/hdc4

empeg:/empeg/bin# swapon /swapfile 

Adding Swap: 16028k swap-space (priority -1)

empeg:/empeg/bin# fsck -fay /

Parallelizing fsck version 1.19 (13-Jul-2000)

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/hda5: 1517/4096 files (0.5% non-contiguous), 9446/16384 blocks

empeg:/empeg/bin# time fsck -fayVC /dev/hdc4  

Parallelizing fsck version 1.19 (13-Jul-2000)

[/sbin/fsck.ext2 -- /dev/hdc4] fsck.ext2 -fay -C0 /dev/hdc4 

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure                                           

Pass 3: Checking directory connectivity                                        

Pass 4: Checking reference counts                                              

Pass 5: Checking group summary information                                     

/dev/hdc4: 10303/228352 files (9.8% non-contiguous), 6157817/7304850 blocks    



real    2m23.148s

user    0m16.630s

sys     0m6.790s

empeg:/empeg/bin# time fsck -fayVC /dev/hdc4

Parallelizing fsck version 1.19 (13-Jul-2000)

[/sbin/fsck.ext2 -- /dev/hdc4] fsck.ext2 -fay -C0 /dev/hdc4 

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure                                           

Pass 3: Checking directory connectivity                                        

Pass 4: Checking reference counts                                              

Pass 5: Checking group summary information                                     

/dev/hdc4: 10303/228352 files (9.8% non-contiguous), 6157817/7304850 blocks    



real    2m23.233s

user    0m16.190s

sys     0m6.890s

empeg:/empeg/bin# time fsck -fayVC /dev/hda4

Parallelizing fsck version 1.19 (13-Jul-2000)

[/sbin/fsck.ext2 -- /drive0] fsck.ext2 -fay -C0 /dev/hda4 

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure                                           

Pass 3: Checking directory connectivity                                        

Pass 4: Checking reference counts                                              

Pass 5: Checking group summary information                                     

/dev/hda4: 4425/304448 files (28.9% non-contiguous), 11223749/38965657 blocks  



real    12m25.375s

user    0m37.270s

sys     0m23.790s

empeg:/empeg/bin# 

The fast drive is about 25/30GB full and the slow one is only about 15/40GB full.

The slow drive is the system drive if that could make any difference.

The swap partition is on the system drive. Paging fsck or swapping its data will cause lots of time-consuming seeks if you're fscking a partition on the same drive. But I'm still surprised that there's a factor of six difference. Maybe the fsck data structures for 30GB's worth of disk just fit in memory, and for a 40GB disk they don't and it thrashes swap?

The actual disk performance -- whether data rate, spin speed, or seek time -- makes a lot less difference in these circumstances, unless the slow disk is actually dying (and doing a lot of retries), which seems unlikely.

Peter

Very simple: the "slow" drive isn't really that slow, it just has a LOT more data on it. Look at the "block counts" rather than the file counts. The "slower" drive has almost double the amount of data stored on it, which may be enough to cause some "thrashing" in e2fsck (cannot hold all data structures in memory at once, so it has to reread some of them over and over ..).

Cheers

Maybe he could try activating the secondary drive's swap space instead of the primary's and see if that significantly changes the time. (I'm correctly remembering that /swapfile is just a link to a partition, aren't I?)

Look at the "block counts" rather than the file counts.

Oooh, good spot. Probably part of the problem is that the slow drive was mke2fs'd with a 1K block size, and the fast drive with a 4K block size. With nearly half the files on the filesystem several megabytes in length, 4K is obviously more efficient. The slow drive is only 30% bigger but has five times as many blocks, and I can bet fsck has some data structures sized by block count. Were these drives formatted with the builder image, or by hand?

Peter

In reply to:

---

Were these drives formatted with the builder image, or by hand

---

The "fast" drive is the original drive from the factory and has never been reformatted or anything like that. So it is as it came from the factory.

The second drive was a brand new drive installed in the player and formatted using the disk builder. I followed the instructions word for word from the Drive Upgrade page on riocar.org.

The only thing that did happen was that when I put the new drive in, I put it in as a master and I put the original drive in as a slave in the hope that the newer drive might have been a little faster. I also copied the dynamic data from the old drive to the new drive and it worked perfectly in case anyone was wondering.

I know it's not going to affect things too much in real life but could 1k blocks instead of 4k blocks pose any sort of problem later on apart from slow fscks? Although I will try turning on the other swap instead and see how fast that goes...

Enabling only the other drives swapfile made absolutely no difference. Still 12 minutes 30 seconds.