lkml.org 
[lkml]   [2001]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UDMA 100 / PIIX4 question

> Device Boot Start End Blocks Id System
> /dev/hda1 * 1 932 7486258+ b Win95 FAT32
> /dev/hda2 933 3737 22531162+ 5 Extended
> /dev/hda5 933 935 24066 83 Linux
> /dev/hda6 936 952 136521 82 Linux swap
> /dev/hda7 953 3737 22370481 83 Linux
>
>
> I also ran hdparm -tT /dev/hda1:
>
> Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
> Timing buffered disk reads: 64 MB in 4.35 seconds = 14.71 MB/sec
>
> Which obviously gives much the same result as my usual hdparm -tT /dev/hda
>
> I then tried hdparm -tT /dev/hda7:
>
> Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
> Timing buffered disk reads: 64 MB in 2.12 seconds = 30.19 MB/sec
>
> As you would expect, I get almost identical results with several repetitions.
>
> Does this solve the mystery ?

no, it's quite odd. hdparm -t cannot be effected by the filesystem
that lives in the partition, since hdparm is doing reads that don't
go through the filesystem. hmm, I wonder if that's it: if you mount
the FS that's in hda1, it might change the block driver configuration
(changing the blocksize, for instance). that would effect hdparm,
even though its reads don't go through the FS.

prediction: if you comment out the hda1 line in fstab, and reboot,
so that vfat never gets mounted on that partition, I predict that
hdparm will show >30.19 MB/s on it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [from the cache]
©2003-2011 Jasper Spaans