[gentoo-user] Normal disk speed?

[gentoo-user] Normal disk speed?

[Adam Carter]

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

Taring my mp3 collection from 2.5in 500MB internal sata drive (sda) to esata
3.5in 500MB drive (sdb) and it seems slow. In vmstat i can see that the
external drive writes faster than the internal can read (external has
periods of inactivity)
# time tar cf /mnt/usbdrive/mp3back.tar mp3/

real    10m9.679s
user    0m1.577s
sys    2m1.769s
# du -ks mp3/
21221661    mp3/

So 21221MB in 610 seconds = 35 MB/s

# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  220 MB in  3.01 seconds =  73.14 MB/sec (77
with --direct)

FWIW;
# hdparm /dev/sda

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 60801/255/63, sectors = 976773168, start = 0


So the should i expect filesystem (reiser3) and other overhead to cut the
read performance to less than half of what hdparm reports? Anything else i
can look at to speed it up? Im using CFQ io scheduler.

[-- Attachment #2: Type: text/html, Size: 1035 bytes --]

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

Am Donnerstag 30 September 2010, 12:58:36 schrieb Adam Carter:
> Taring my mp3 collection from 2.5in 500MB internal sata drive (sda) to
> esata 3.5in 500MB drive (sdb) and it seems slow. In vmstat i can see that
> the external drive writes faster than the internal can read (external has
> periods of inactivity)
[...]
> So 21221MB in 610 seconds = 35 MB/s
> 
> # hdparm -t /dev/sda
> 
> /dev/sda:
>  Timing buffered disk reads:  220 MB in  3.01 seconds =  73.14 MB/sec (77
> with --direct)
[...] 
> So the should i expect filesystem (reiser3) and other overhead to cut the
> read performance to less than half of what hdparm reports? Anything else i
> can look at to speed it up? Im using CFQ io scheduler.

35 MB/s is a pretty normal value for a 5400 RPM laptop HDD.

An HDD gets slower when you read the inner tracks.  The angular velocity is 
constant (5400 RPM) while the tangential velocity gets lower with the radius.

Inner tracks are mapped to the sectors at the far end of the partition table. 
That's why you should always put swap and system partitions at the front of 
your partition table and use its end for bulk data.

I guess your mp3 collection is stored somewhere at the middle or end of your 
internal disk (inner tracks) while your external disk is nearly empty and 
therefore stores data on the outer tracks. 

Hope this helps.
Florian Philipp

Re: [gentoo-user] Normal disk speed?

[Peter Humphrey]

On Thursday 30 September 2010 14:10:42 Florian Philipp wrote:

> An HDD gets slower when you read the inner tracks.  The angular
> velocity is constant (5400 RPM) while the tangential velocity gets
> lower with the radius.

Are you telling us that the length of a stored bit is constant? I'd have 
thought it was the time needed to read or write a bit that was constant; 
otherwise the electronics would get extremely complex. In that case it's 
the angular velocity that counts, not the linear velocity, and it 
matters not which track your data are on. (If a block goes past the head 
twice as fast, it also occupies twice the space, so you're back where 
you were.)

That's the way it was with our imposing new 2MB disks in 1974, anyway. 
They occupied boxes four feet tall and six feet long, and had external 
air systems; I was one of those responsible for the maintenance; we were 
sent on a training course specifically for the disks. I can't remember 
who made them, but they were part of a Ferranti Argus 500 system at the 
then national grid control centre.

Maybe technology has changed since then.

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

[gentoo-user] Re: Normal disk speed?

[Nikos Chantziaras]

On 09/30/2010 07:00 PM, Peter Humphrey wrote:
> On Thursday 30 September 2010 14:10:42 Florian Philipp wrote:
>
>> An HDD gets slower when you read the inner tracks.  The angular
>> velocity is constant (5400 RPM) while the tangential velocity gets
>> lower with the radius.
>
> Are you telling us that the length of a stored bit is constant? I'd have
> thought it was the time needed to read or write a bit that was constant;
> otherwise the electronics would get extremely complex. In that case it's
> the angular velocity that counts, not the linear velocity, and it
> matters not which track your data are on. (If a block goes past the head
> twice as fast, it also occupies twice the space, so you're back where
> you were.)

Uhm, no.  The higher the linear velocity, the higher the read/write 
speed.  This can be proven with any disk benchmark that can bench the 
whole disk.  You get a graph that begins low and ends high (and the 
difference between inner and outer region is substantial, almost 2:1).

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

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

Am 30.09.2010 18:00, schrieb Peter Humphrey:
> On Thursday 30 September 2010 14:10:42 Florian Philipp wrote:
> 
>> An HDD gets slower when you read the inner tracks.  The angular
>> velocity is constant (5400 RPM) while the tangential velocity gets
>> lower with the radius.
> 
> Are you telling us that the length of a stored bit is constant? I'd have 
> thought it was the time needed to read or write a bit that was constant; 
> otherwise the electronics would get extremely complex. In that case it's 
> the angular velocity that counts, not the linear velocity, and it 
> matters not which track your data are on. (If a block goes past the head 
> twice as fast, it also occupies twice the space, so you're back where 
> you were.)

Yes, the length of a block is constant. If the innermost "ring" (track)
contains 4 blocks, the next ring contains maybe 5 blocks.[1]

Put another way: If you could pack your bits more densely on innermost
tracks, why wouldn't you pack them that densely on the whole disk and
thereby increase the overall capacity?

> 
> That's the way it was with our imposing new 2MB disks in 1974, anyway. 
> They occupied boxes four feet tall and six feet long, and had external 
> air systems; I was one of those responsible for the maintenance; we were 
> sent on a training course specifically for the disks. I can't remember 
> who made them, but they were part of a Ferranti Argus 500 system at the 
> then national grid control centre.
> 
> Maybe technology has changed since then.
> 

Well, we are talking about devices employing the GMR effect while also
doing error correction and remapping of defect sectors on-the-fly. I
guess a little lookup table from track number to time-per-block doesn't
add too much complexity.

You can easily test this if you have various partitions on your HDD.
Just compare dd throughput for your first partition versus your last one.

[1] The numbers are arbitrary. The number increases linearly. C = 2*pi*r


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Normal disk speed?

[Peter Humphrey]

On Thursday 30 September 2010 17:50:41 Florian Philipp wrote:
> Am 30.09.2010 18:00, schrieb Peter Humphrey:
> > On Thursday 30 September 2010 14:10:42 Florian Philipp wrote:
> >> An HDD gets slower when you read the inner tracks.  The angular
> >> velocity is constant (5400 RPM) while the tangential velocity gets
> >> lower with the radius.
> > 
> > Are you telling us that the length of a stored bit is constant? I'd
> > have thought it was the time needed to read or write a bit that
> > was constant; otherwise the electronics would get extremely
> > complex. In that case it's the angular velocity that counts, not
> > the linear velocity, and it matters not which track your data are
> > on. (If a block goes past the head twice as fast, it also occupies
> > twice the space, so you're back where you were.)
> 
> Yes, the length of a block is constant. If the innermost "ring"
> (track) contains 4 blocks, the next ring contains maybe 5 blocks.[1]
> 
> Put another way: If you could pack your bits more densely on
> innermost tracks, why wouldn't you pack them that densely on the
> whole disk and thereby increase the overall capacity?
> 
> > That's the way it was with our imposing new 2MB disks in 1974,
> > anyway. They occupied boxes four feet tall and six feet long, and
> > had external air systems; I was one of those responsible for the
> > maintenance; we were sent on a training course specifically for
> > the disks. I can't remember who made them, but they were part of a
> > Ferranti Argus 500 system at the then national grid control
> > centre.
> > 
> > Maybe technology has changed since then.
> 
> Well, we are talking about devices employing the GMR effect while
> also doing error correction and remapping of defect sectors
> on-the-fly. I guess a little lookup table from track number to
> time-per-block doesn't add too much complexity.
> 
> You can easily test this if you have various partitions on your HDD.
> Just compare dd throughput for your first partition versus your last
> one.

Seems like technology has moved on. Well, it has had 35 years or more.

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

[gentoo-user] Re: Normal disk speed?

[James]

Adam Carter <adamcarter3 <at> gmail.com> writes:


> Taring my mp3 collection from 2.5in 500MB internal sata drive 
> (sda) to esata 3.5in 500MB drive (sdb) and it seems slow. 


Well, there are multiple avenues to nail down your specific issues,
most documented or hinted at in the archives of this list.....

Here is some fuel for thought, on a higher plain:
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/B-tree

So you have at least (2) issues.

1. Your specific hardware
http://www.coker.com.au/bonnie++/
bonnie is also in portage
[eix bonnie]

2. The longer view of increasing
file system performance, particularly
in a distributed resources environment:

(CEPHGS, GlusterFS, BTRFS, others?) is the subject
of a hot debate, probably overdue for the devs
or the brilliant, on this list, to update
us commoners? (here goes another religious war!)

hth,
James

Re: [gentoo-user] Normal disk speed?

[Volker Armin Hemmann]

On Thursday 30 September 2010, Adam Carter wrote:
> Taring my mp3 collection from 2.5in 500MB internal sata drive (sda) to
> esata 3.5in 500MB drive (sdb) and it seems slow. In vmstat i can see that
> the external drive writes faster than the internal can read (external has
> periods of inactivity)
> # time tar cf /mnt/usbdrive/mp3back.tar mp3/
> 
> real    10m9.679s
> user    0m1.577s
> sys    2m1.769s
> # du -ks mp3/
> 21221661    mp3/
> 
> So 21221MB in 610 seconds = 35 MB/s
> 
> # hdparm -t /dev/sda
> 
> /dev/sda:
>  Timing buffered disk reads:  220 MB in  3.01 seconds =  73.14 MB/sec (77
> with --direct)
> 
> FWIW;
> # hdparm /dev/sda
> 
> /dev/sda:
>  multcount     = 16 (on)
>  IO_support    =  1 (32-bit)
>  readonly      =  0 (off)
>  readahead     = 256 (on)
>  geometry      = 60801/255/63, sectors = 976773168, start = 0
> 
> 
> So the should i expect filesystem (reiser3) and other overhead to cut the
> read performance to less than half of what hdparm reports? Anything else i
> can look at to speed it up? Im using CFQ io scheduler.

as soon as your harddisk seeks you are lucky to be above 5mb/sec. Yes, even 
with a modern harddrive. Just look up the seek times and do the math.

Your harddisk seeks, everything is slow. 

Re: [gentoo-user] Normal disk speed?

[Adam Carter]

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

> Your harddisk seeks, everything is slow.
>
> So does that then mean that my options are;
1. Defragment, so there is less seeking
2. Get an SSD

Since 2 is too expensive for a decent size drive, is there anything i can do
about 1 without a backup and restore operation? Or will the fragmentation be
very small on reiser3 anyway (i mount with notail) so I should just accept
things as they are.

[-- Attachment #2: Type: text/html, Size: 616 bytes --]

Re: [gentoo-user] Normal disk speed?

[Volker Armin Hemmann]

On Friday 01 October 2010, Adam Carter wrote:
> > Your harddisk seeks, everything is slow.
> > 
> > So does that then mean that my options are;
> 
> 1. Defragment, so there is less seeking
> 2. Get an SSD
> 
> Since 2 is too expensive for a decent size drive, is there anything i can
> do about 1 without a backup and restore operation? Or will the
> fragmentation be very small on reiser3 anyway (i mount with notail) so I
> should just accept things as they are.

every fs fragments over the course of time. Some more, some less. So as long 
as you have harddisks:
get used to the seeking penalty. 

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

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

Am 01.10.2010 03:12, schrieb Adam Carter:
>     Your harddisk seeks, everything is slow.
> 
> So does that then mean that my options are;
> 1. Defragment, so there is less seeking
> 2. Get an SSD
> 
> Since 2 is too expensive for a decent size drive, is there anything i
> can do about 1 without a backup and restore operation? Or will the
> fragmentation be very small on reiser3 anyway (i mount with notail) so I
> should just accept things as they are.

To prevent fragmentation, try to always keep a decent amount of free
space on each partition. That way, the FS driver can allocate space for
new files without too much fragmentation (a fragment every 2 MB or so
doesn't really hurt performance).

If you had enough free space on your partition when you created the
mp3-files there, I don't think fragmentation is an issue here. The files
likely never grew in size which would cause fragmentation.

Of course, the situation changes again when the free space on your file
system was already heavily fragmented even if there was enough of it. It
all depends on your usage pattern of that disk to make an educated guess
if that is true.

The good thing about hard disks is that you can usually hear whether
they are seeking or reading sequentially. If you hear a lot of seeking
on sequential operations, it is time to reformat the partition or at
least erase and recreate the affected files.

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Normal disk speed?

[Volker Armin Hemmann]

On Friday 01 October 2010, Florian Philipp wrote:
> Am 01.10.2010 03:12, schrieb Adam Carter:
> >     Your harddisk seeks, everything is slow.
> > 
> > So does that then mean that my options are;
> > 1. Defragment, so there is less seeking
> > 2. Get an SSD
> > 
> > Since 2 is too expensive for a decent size drive, is there anything i
> > can do about 1 without a backup and restore operation? Or will the
> > fragmentation be very small on reiser3 anyway (i mount with notail) so I
> > should just accept things as they are.
> 
> To prevent fragmentation, try to always keep a decent amount of free
> space on each partition. That way, the FS driver can allocate space for
> new files without too much fragmentation (a fragment every 2 MB or so
> doesn't really hurt performance).

you obviously never used a tape drive...

Re: [gentoo-user] Normal disk speed?

[Adam Carter]

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

>
> > > 1. Defragment, so there is less seeking
>

To this end i have found the scripts fragck.pl and defrag at
http://forums.gentoo.org/viewtopic-t-429915.html

For me;
# ./fragck.pl /home/adam/mp3/
77.6329693554068% non contiguous files, 27.4885523071504 average fragments.

Unfortunately defrag did nothing, running fragck.pl after defrag showed no
difference.

[-- Attachment #2: Type: text/html, Size: 728 bytes --]

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

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

Am 01.10.2010 18:23, schrieb Volker Armin Hemmann:
> On Friday 01 October 2010, Florian Philipp wrote:
>> Am 01.10.2010 03:12, schrieb Adam Carter:
>>>     Your harddisk seeks, everything is slow.
>>>
>>> So does that then mean that my options are;
>>> 1. Defragment, so there is less seeking
>>> 2. Get an SSD
>>>
>>> Since 2 is too expensive for a decent size drive, is there anything i
>>> can do about 1 without a backup and restore operation? Or will the
>>> fragmentation be very small on reiser3 anyway (i mount with notail) so I
>>> should just accept things as they are.
>>
>> To prevent fragmentation, try to always keep a decent amount of free
>> space on each partition. That way, the FS driver can allocate space for
>> new files without too much fragmentation (a fragment every 2 MB or so
>> doesn't really hurt performance).
> 
> you obviously never used a tape drive...
> 
> 

Hehe, yep. :)

While we're at the topic, we can do some basic math to show how bad
fragmentation is.

Symbols:

s [MB]: total size
t_f [s]: total read/write time with fragmentation
t_nf [s]: total read/write time without fragmentation
t_s [s]: seek time
v [MB/s]: sequential throughput
n [-]: number of fragments
f [1/MB]: fragmentation (fragments per MB)
e [-]: effectiveness (percentage)

Assumptions:

1. Seek time is constant. For HDDs we can take an average value. Of
course this doesn't work for tapes. They have a seek time which
increases linearly with the distance between the fragments.

2. Throughput is constant. As I've stated in another post this is not
true for HDDs but we can again take an average value.

Formulas:

s = v * t_nf //without fragmentation
s = v * (t_f - n*t_s) //with fragmentation

s = v*t_f - v*n*t_s
t_f = (s + v*n*t_s)/v
Without fragmentation we would have
t_nf = s/v

Now we can normalize the time to get the effectiveness
e = t_nf / t_f
e = s/v * v/(s * v*n*t_s)
e = s/(s * v*n*t_s)
e = 1/(n/s * t_s * v + 1)

Nearly done. n/s is the fragmentation. Therefore we get:
f = n/s
e = 1/(f * t_s * v + 1)

Great. Now we're done.
For laptop HDDs I think a seek time of 12 ms (Wikipedia says so) and an
average throughput of 50 MB/s are good values.
When we plot effectiveness against fragmentation, we see that with one
fragment every two MB we get around 77% effectiveness whereas with two
two fragments every MB we already drop to 45%. Worst case would be one
fragment per file system block. With 4kB blocks that's 256 fragments per
MB. That means we drop to 0.65% effectiveness.

The values seem drastic but are plausible: 50 MB/s sequential throughput
and 12 ms seek time mean that in the time we need to do one seek
operation, we could read 50*12e-3 = 0.6 MB.

Hope this helps,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Normal disk speed?

[Volker Armin Hemmann]

On Saturday 02 October 2010, Florian Philipp wrote:
> Am 01.10.2010 18:23, schrieb Volker Armin Hemmann:
> > On Friday 01 October 2010, Florian Philipp wrote:
> >> Am 01.10.2010 03:12, schrieb Adam Carter:
> >>>     Your harddisk seeks, everything is slow.
> >>> 
> >>> So does that then mean that my options are;
> >>> 1. Defragment, so there is less seeking
> >>> 2. Get an SSD
> >>> 
> >>> Since 2 is too expensive for a decent size drive, is there anything i
> >>> can do about 1 without a backup and restore operation? Or will the
> >>> fragmentation be very small on reiser3 anyway (i mount with notail) so
> >>> I should just accept things as they are.
> >> 
> >> To prevent fragmentation, try to always keep a decent amount of free
> >> space on each partition. That way, the FS driver can allocate space for
> >> new files without too much fragmentation (a fragment every 2 MB or so
> >> doesn't really hurt performance).
> > 
> > you obviously never used a tape drive...
> 
> Hehe, yep. :)
> 
> While we're at the topic, we can do some basic math to show how bad
> fragmentation is.
> 
> Symbols:
> 
> s [MB]: total size
> t_f [s]: total read/write time with fragmentation
> t_nf [s]: total read/write time without fragmentation
> t_s [s]: seek time
> v [MB/s]: sequential throughput
> n [-]: number of fragments
> f [1/MB]: fragmentation (fragments per MB)
> e [-]: effectiveness (percentage)
> 
> Assumptions:
> 
> 1. Seek time is constant. For HDDs we can take an average value. Of
> course this doesn't work for tapes. They have a seek time which
> increases linearly with the distance between the fragments.

I think you misunderstood my remark.

Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed. 
Slow, isn't it?

But when you do a backup on such an old tape even with a modern harddisk you 
have problems keeping it streaming. As soon as you hit a directory with many 
small files - like ~/Mail or /usr/portage you are screwed. 

Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single 
small file. But when you have houndreds, thousands or hundreds of thousands of 
small files, harddisks suck.
And your tape drive has to stop and rewind every couple of seconds because 
your harddisks were not able to keep up the required 10mb/sec. Trueley 
pathetic.

Besides, seek times are not constant ;)

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

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

Am 02.10.2010 14:11, schrieb Volker Armin Hemmann:
> On Saturday 02 October 2010, Florian Philipp wrote:
[...]
>>
>> Assumptions:
>>
>> 1. Seek time is constant. For HDDs we can take an average value. Of
>> course this doesn't work for tapes. They have a seek time which
>> increases linearly with the distance between the fragments.
> 
> I think you misunderstood my remark.
> 
> Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed. 
> Slow, isn't it?
> 
> But when you do a backup on such an old tape even with a modern harddisk you 
> have problems keeping it streaming. As soon as you hit a directory with many 
> small files - like ~/Mail or /usr/portage you are screwed. 
> 
> Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single 
> small file. But when you have houndreds, thousands or hundreds of thousands of 
> small files, harddisks suck.
> And your tape drive has to stop and rewind every couple of seconds because 
> your harddisks were not able to keep up the required 10mb/sec. Trueley 
> pathetic.

Well, that's exactly what my little math shows. When you read 4kB files,
you can end up with 0.0065 * 50 MB/s = 0.32 MB/s effective throughput
(worst case).

> 
> Besides, seek times are not constant ;)
> 

Sure they aren't. That's why it is stated as an assumption. It is just a
model.  Like every model it has its limits.[1] It doesn't take into
account prefetching, caching and NCQ/TCQ, for example.

Still it is a valid assumption: *On average*, the read/write head has to
move around half the radius of the platter to reach its next position
and it has to wait for half a rotation until the right block is under
the head. If we assume that fragments are uniformly distributed over the
whole disk, we can simply take an average value for seek times.

The model also doesn't take into account that even with no
fragmentation, there might be some seek operations: Blocks on an HDD are
organized in rings (tracks), not as a spiral like the sound track on an
good old LP. That means that at some point, the r/w head has to switch
to the next track when the file does not reside on one track alone.

[1] A bit off-topic: I work in applied sciences and engineering. There
I've learned two basic rules about models: 1. Truth doesn't matter,
usefulness does. 2. Every model has its limits. Knowing these limits is
the single most important important thing when using a model.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

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

Am 02.10.2010 14:44, schrieb Florian Philipp:
> Am 02.10.2010 14:11, schrieb Volker Armin Hemmann:
>> On Saturday 02 October 2010, Florian Philipp wrote:
> [...]
>>>
>>> Assumptions:
>>>
>>> 1. Seek time is constant. For HDDs we can take an average value. Of
>>> course this doesn't work for tapes. They have a seek time which
>>> increases linearly with the distance between the fragments.
>>
>> I think you misunderstood my remark.
>>
>> Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed. 
>> Slow, isn't it?
>>
>> But when you do a backup on such an old tape even with a modern harddisk you 
>> have problems keeping it streaming. As soon as you hit a directory with many 
>> small files - like ~/Mail or /usr/portage you are screwed. 
>>
>> Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single 
>> small file. But when you have houndreds, thousands or hundreds of thousands of 
>> small files, harddisks suck.
>> And your tape drive has to stop and rewind every couple of seconds because 
>> your harddisks were not able to keep up the required 10mb/sec. Trueley 
>> pathetic.
> 
> Well, that's exactly what my little math shows. When you read 4kB files,
> you can end up with 0.0065 * 50 MB/s = 0.32 MB/s effective throughput
> (worst case).
> 
>>
>> Besides, seek times are not constant ;)
>>
> 
> Sure they aren't. That's why it is stated as an assumption. It is just a
> model.  Like every model it has its limits.[1] It doesn't take into
> account prefetching, caching and NCQ/TCQ, for example.
> 
> Still it is a valid assumption: *On average*, the read/write head has to
> move around half the radius of the platter to reach its next position
> and it has to wait for half a rotation until the right block is under
> the head. If we assume that fragments are uniformly distributed over the
> whole disk, we can simply take an average value for seek times.
> 
> The model also doesn't take into account that even with no
> fragmentation, there might be some seek operations: Blocks on an HDD are
> organized in rings (tracks), not as a spiral like the sound track on an
> good old LP. That means that at some point, the r/w head has to switch
> to the next track when the file does not reside on one track alone.
> 
> [1] A bit off-topic: I work in applied sciences and engineering. There
> I've learned two basic rules about models: 1. Truth doesn't matter,
> usefulness does. 2. Every model has its limits. Knowing these limits is
> the single most important important thing when using a model.
> 


Hmm, I've just looked up some specs from this page:
http://www.wdc.com/en/products/products.asp?driveid=512

These make me a wonder a bit:
Average latency is 5.5 ms. That's the time the disk needs for half a
rotation. However, read seek time is 12 ms. That's a bit more than one
rotation. If that's an average value rather than a maximum, it makes me
wonder what takes it so long. It can't be rotational delay (that's their
average latency). Therefore it must be the time it takes the r/w head to
move into position.

I find it a bit unbelievable that this takes so long. If that really is
the limiting factor then a high-end server disk couldn't be much faster
simply by increasing the RPM.

Well, I guess their "seek time" is the maximum value. Then it makes
sense: One rotation is 11.111 ms. Then they might add some latency due
to data processing etc. Any different thoughts?

Another interesting bit of information: Track-to-track seek time is 2
ms. That's the seek time I mentioned above which also occurs for
sequential reads/writes.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Normal disk speed?

[Daniel Troeder]

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

On 10/01/2010 03:12 AM, Adam Carter wrote:
>     Your harddisk seeks, everything is slow.
> 
> So does that then mean that my options are;
> 1. Defragment, so there is less seeking
> 2. Get an SSD
> 
> Since 2 is too expensive for a decent size drive, is there anything i
> can do about 1 without a backup and restore operation? Or will the
> fragmentation be very small on reiser3 anyway (i mount with notail) so I
> should just accept things as they are.

You can gain a significant performance win by choosing your fs carefully
(and benchmarking).

If you've got a fs with mostly files of "middle size" or "big size" like
a root fs or media collection you can use ext4 or xfs and they will
perform as good or better than reiser3 because they fragment less. In my
experience reiser3 fragments strongly after a year or so of heavy usage.

xfs has a online-defragment tool "xfs_fsr" in sys-fs/xfsdump that works
very well and is officially supported. (No other fs has that, to my
knowledge.)

xfs is especially fast and efficient with "big" files (media files).

ext4 and xfs perform well in most use cases and are actively developed.
Read phoronix for benchmarks. :)

If you've got lots of small files (<4kb) (like in a portage tree, mail
or news server) you want to go with reiser3 or ext4. ext4 can be
formatted with "-T news" to optimize for small files. The optimization
is not in speed, but in small block size, to save disk space.

As I read about the nice performance of btrfs with compression I tried
it out two weeks ago. I'll be posting my benchmarks to this list soon.
Until now I didn't have any problems, but still would not use btrfs on
production systems.
I store all my small portage files (/usr/portage, /var/cache/edb and
/var/db/pkg - 215000 files) on a btrfs partition and have benchmarked it
against reiser3 (which I was using before).
--> double speed!  (For example "emerge --metadata" and "rsync
<yesterday-portage> <today-portage>" needs *half* the time on btrfs than
reiser3!!!)

For work I use VirtualBox a lot. I store my VM disk images on a xfs-fs,
because I can defragment it, and fragmented VM disks are really slow.

If you're working on a RAID or have a 4k-disk, you'll have to align your
partitions to the stripe size. (See lots of long threads in this mailing
list.)

BTW: You wrote you mount with "notail". I hope you also use "noatime".
This is _ultra_important_ if you have lots of metadata work
(reading/modifying lots of files and/or their attributes, like in
portage-trees). You probably never need atimes, no you should always
mount all your filesystems with it.

mkfs.xfs has an option "-l lazy-count=1" that helps in metadata heavy
workloads.


My point: The speed of your file access can vary a lot depending on the
file system and its options. But the right file system to choose depends
on your use case. In the end you'll have to benchmark...


Bye,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-user] Re: Normal disk speed?

[James]

Daniel Troeder <daniel <at> admin-box.com> writes:


> As I read about the nice performance of btrfs with compression I tried
> it out two weeks ago. I'll be posting my benchmarks to this list soon.
> Until now I didn't have any problems, but still would not use btrfs on
> production systems.

What tool(how) did you setup btrfs?
As I'm going to use it (test it) on an old 
drive (system), with / /boot and swap all
using btrfs.........

Fdisk(gentoo_handbook)? 

What would a grub entry look like?

/etc/fstab ?

Other affected files?

Well, I'm going to take the BTRFS plung. Any words
of wisdom,  howto's or caveats are most welcome.


James

Re: [gentoo-user] Re: Normal disk speed?

[Daniel Troeder]

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

On 10/01/2010 04:40 PM, James wrote:
> Daniel Troeder <daniel <at> admin-box.com> writes:
> 
> 
>> As I read about the nice performance of btrfs with compression I tried
>> it out two weeks ago. I'll be posting my benchmarks to this list soon.
>> Until now I didn't have any problems, but still would not use btrfs on
>> production systems.
> 
> What tool(how) did you setup btrfs?
> As I'm going to use it (test it) on an old 
> drive (system), with / /boot and swap all
> using btrfs.........
> 
> Fdisk(gentoo_handbook)? 
> 
> What would a grub entry look like?
> 
> /etc/fstab ?
> 
> Other affected files?
> 
> Well, I'm going to take the BTRFS plung. Any words
> of wisdom,  howto's or caveats are most welcome.
> 
> 
> James
I read the man and web page, and ended up using the defaults:

$ mkfs.btrfs /dev/xyz

To use compression, just mount with "-o compress". That's all :)

/etc/fstab:
/dev/mapper/vg0-portage /gentoo btrfs noatime,compress 0 2

I installed sys-fs/btrfs-progs-0.19-r1 and I have the 'acl' flag on.

I haven't done anything fancy since then, and it justworks(tm) ;)

Bye,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-user] Re: Normal disk speed?

[James]

Daniel Troeder <daniel <at> admin-box.com> writes:



> $ mkfs.btrfs /dev/xyz
> To use compression, just mount with "-o compress". 
> /etc/fstab:
> /dev/mapper/vg0-portage /gentoo btrfs noatime,compress 0 2
> I installed sys-fs/btrfs-progs-0.19-r1 and I have the 'acl' flag on.


Fair enough,

thanks

James

Re: [gentoo-user] Re: Normal disk speed?

[Adam Carter]

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

FYI some braindead benchmarking, reiserfs vs ext4, kernel 2.6.35-gentoo-r8

Copy same DVD image from internal reiserfs drive to freshly formatted
external drive;
reiserfs    1m37.530s
ext4        3m15.074s

Then image copy on that external drive;
# time cp CentOS-5.3-x86_64-bin-DVD.iso CentOS-5.3-x86_64-bin-DVD.iso2
# time cp CentOS-5.3-x86_64-bin-DVD.iso CentOS-5.3-x86_64-bin-DVD.iso3
reiser        1m44.719s and 1m51.441s
ext4        3m24.337s and 4m30.534s

Not that is matters, but create filesystem on 2TB drive;
reiserfs    1m17.373s
ext4        6m3.421s

Didnt see that coming, I guess i'll stick with reiser3....

[-- Attachment #2: Type: text/html, Size: 689 bytes --]

Re: [gentoo-user] Re: Normal disk speed?

[Daniel Troeder]

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

On 10/06/2010 10:04 AM, Adam Carter wrote:
> FYI some braindead benchmarking, reiserfs vs ext4, kernel 2.6.35-gentoo-r8
> 
> Copy same DVD image from internal reiserfs drive to freshly formatted
> external drive;
> reiserfs    1m37.530s
> ext4        3m15.074s
> 
> Then image copy on that external drive;
> # time cp CentOS-5.3-x86_64-bin-DVD.iso CentOS-5.3-x86_64-bin-DVD.iso2
> # time cp CentOS-5.3-x86_64-bin-DVD.iso CentOS-5.3-x86_64-bin-DVD.iso3
> reiser        1m44.719s and 1m51.441s
> ext4        3m24.337s and 4m30.534s
> 
> Not that is matters, but create filesystem on 2TB drive;
> reiserfs    1m17.373s
> ext4        6m3.421s    
> 
> Didnt see that coming, I guess i'll stick with reiser3....
WOW! Those differences are crazy!

Please - I know benchmarking takes a lot of time - but could you check
something: the behavior those fs have at what time they flush data from
cache to disk is very different. Have you made sure that you measured
the time it really needs? I mean the difference between:

$ sync; time cp source dest
and
$ sync; time (cp source dest; sync)

Only the last measures somewhat correctly.

I'm irritated, because ext4 is extends based, and should behave much
better with big files than reiser3... not only less fragmentation, but
should also be faster...

Bye,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Re: Normal disk speed?

[Adam Carter]

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

WOW! Those differences are crazy!

>
> Please - I know benchmarking takes a lot of time - but could you check
> something: the behavior those fs have at what time they flush data from
> cache to disk is very different. Have you made sure that you measured
> the time it really needs? I mean the difference between:
>
> $ sync; time cp source dest
> and
> $ sync; time (cp source dest; sync)
>
> Only the last measures somewhat correctly.
>

I had noticed that there was, say, 5 seconds of disk activity after the cp
command complete which I assumed was buffers getting flushed, but 5 seconds
didnt seem that significant overall. I will run the tests as you suggest and
post back. Do you think btrfs (with or without compression) would be faster
than reiser? If so I will try that as well.

[-- Attachment #2: Type: text/html, Size: 1006 bytes --]

Re: [gentoo-user] Re: Normal disk speed?

[Daniel Troeder]

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

On 10/07/2010 12:59 AM, Adam Carter wrote:
> WOW! Those differences are crazy!
> 
> 
>     Please - I know benchmarking takes a lot of time - but could you check
>     something: the behavior those fs have at what time they flush data from
>     cache to disk is very different. Have you made sure that you measured
>     the time it really needs? I mean the difference between:
> 
>     $ sync; time cp source dest
>     and
>     $ sync; time (cp source dest; sync)
> 
>     Only the last measures somewhat correctly.
> 
> 
> I had noticed that there was, say, 5 seconds of disk activity after the
> cp command complete which I assumed was buffers getting flushed, but 5
> seconds didnt seem that significant overall. I will run the tests as you
> suggest and post back. Do you think btrfs (with or without compression)
> would be faster than reiser? If so I will try that as well.
On my system it is twice as fast as reiser3 for _lots_ (200.000) of
small files with compression on (didn't test is without compression). I
didn't test if with big files.

But your results may vary anyway. For example btrfs is very
cpu-intensive (even more with compression). If you've got a slow cpu
(like in embedded devices), jfs might perform better.

BTW: _all_ my partitions are encrypted and on LVM, so your use case is
probably very different :)

Bye,
Daniel

-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Re: Normal disk speed?

[Adam Carter]

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

> > suggest and post back. Do you think btrfs (with or without compression)
> > would be faster than reiser? If so I will try that as well.
> On my system it is twice as fast as reiser3 for _lots_ (200.000) of
> small files with compression on (didn't test is without compression). I
> didn't test if with big files.
>
> But your results may vary anyway. For example btrfs is very
> cpu-intensive (even more with compression). If you've got a slow cpu
> (like in embedded devices), jfs might perform better.
>

FWIW i finally re-ran my tests (CPU is 64 bit dual core Intel 2.4GHz);

Copy DVD iso from Internal drive (reiserfs) to external drive
reiserfs           1m24 1m23 1m23 1m22
ext4               1m39 1m25 1m25 1m25 remount 1m26 1m23 1m23 1m22
btrfs               1m22 1m22 1m22
btrfs+comp     1m20 1m21 1m20 1m21

Copy DVD iso on external drive
# sync; time (cp CentOS-5.3-x86_64-bin-DVD.iso
CentOS-5.3-x86_64-bin-DVD.iso2; sync)
reiser         1m52 1m52 1m52
ext4           1m43 1m43 1m43 1m44 remount 1m33 1m33 1m33 1m42
btrfs           1m42 1m41 1m41 1m45 remount 1m46 1m41
btrfs+comp 1m34 1m33 1m34 (im guessing the driver is clever enough not to
uncompress and recompress)

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]