Hi,
Disk read/write times are (my view) somewhat misleading.
To a compiler, which ends up loading lots and lots of small files during
compiling, seek time is far more important than read/write speed.
Yes - the OS buffers the various include files, so the next file that is
compiled is faster.
Some utilities lots of files on startup - a disk that has ultra fast
seek time
will be best.
I checked:
xemacs
lsof | grep xemacs | grep / | wc -l >> 128 files.
chromium - 832 files.
yup - quite easy to argue that ultra fast access time is important.
Comment?
(P.S. - so good to have a proper linux discussion on this list!)
Cheers,
Derek.
On 04/02/14 12:31, Steve Holdoway wrote:
ADATA SP900
/dev/sda:
Timing cached reads: 8024 MB in 2.00 seconds = 4014.98 MB/sec
Timing buffered disk reads: 970 MB in 3.01 seconds = 322.75 MB/sec
ADATA SSD S511 1
/dev/sdb:
Timing cached reads: 8072 MB in 2.00 seconds = 4039.68 MB/sec
Timing buffered disk reads: 870 MB in 3.00 seconds = 289.73 MB/sec
Second one is the older disk.
Steve
On Tue, 2014-02-04 at 12:01 +1300, C. Falconer wrote:
Timing buffered disk reads: 532 MB in 3.00 seconds = 177.30 MB/sec
Timing buffered disk reads: 566 MB in 3.00 seconds = 188.49 MB/sec
So the faster one is a 64 GB Intel SSD on a SATA3 connector
The *slightly* slower is a 2 TB seagate desktop drive on SATA2 that
cost me under a hundred bucks.
So is my ssd excessively slow? Have I been bitten by the trim thing?
Does anyone else have access to a normal SSD in linux to run a quick
hdparm -t /dev/sd? and email me the result?
--
CF
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
