HD to SSD question.

[Mihai T. Lazarescu]

On Tue, Aug 20, 2013 at 03:56:56PM +0200, Heinz Diehl wrote:

> On 20.08.2013, Mihai T. Lazarescu wrote: 
> 
> > Thanks for the pointer.  I add to the mix my test results for
> > F19 with kernel 3.10.7 on an ASUS UX31E with its factory 256GB
> > SSD-only mass storage.
> > 
> > CFQ scheduler run1:
> [....]
> 
> All these numbers are pointless, because when I see
> your results I'm quite shure you did run the test without
> generating loads of disk I/O in parallel.  What you actually
> measured is the latency in idle state ;-)
> 
> Open a console and run
> 
>  while : ; do time sh -c "dd if=/dev/zero of=bigfile bs=8M count=256 ; sync; rm bigfile"; done
> 
> Then, open another one and run fsync-tester.  The numbers
> that count to compare different elevators on your system
> is the output fsync-tester generates while your machine is
> generating the "bigfile".

Thanks Heinz!  Indeed, I took every precaution to leave the
machine still. :-)

Here are the program numbers while running the script:

CFQ:
    write time: 0.0010s fsync time: 0.8647s
    write time: 0.1340s fsync time: 3.1220s
    write time: 2.1435s fsync time: 2.8134s
    write time: 0.1458s fsync time: 8.3726s
    write time: 0.0005s fsync time: 1.0401s
    write time: 0.0175s fsync time: 1.0270s
    write time: 4.0406s fsync time: 0.0321s
    write time: 0.0005s fsync time: 4.8683s
    write time: 0.0004s fsync time: 0.3178s

Deadline run1:
    write time: 0.0009s fsync time: 82.3477s

Deadline run2:
    write time: 0.0007s fsync time: 659.2289s

Noop:
    I give up after waiting for more than 20'
    to see even the first measurement.

As a side note, with deadline and noop schedulers the test can
take a LOT to complete and often lock for tens of seconds other
programs that make mild accesses to disk (e.g., vim writing
this email or unhiding/hiding MATE panel).  This happened also
in previous tests, run without additional load, but then the
tests did complete in a reasonable amount of time.

Mihai