Talk:Solid State Drives

From ArchWiki
Revision as of 00:54, 3 November 2013 by Ushi (Talk | contribs) (DONT USE NOOP)

Jump to: navigation, search


The noop scheduler will perform slow but as a result it will greatly frees up CPU cycles. This in the real world will not increase the speed of your read/writes compared to CFS but instead consume less CPU resources. You can benchmark the deadline scheduler which MAY increase performance in some circumstances. By real world benchmarks, I mean anything but hdparm.

Interesting assertion... do you have any data or a source to back it up?
Graysky 17:20, 21 December 2011 (EST)
It seems that the cfq scheduler already knows what to do when SSD is detected, so there is no use to change it.
raymondcal 2012, may 29
CFQ has some optimizations for SSDs and if it detects a non-rotational
media which can support higher queue depth (multiple requests at in
flight at a time), then it cuts down on idling of individual queues and
all the queues move to sync-noidle tree and only tree idle remains. This
tree idling provides isolation with buffered write queues on async tree.
ushi 2013, November 03


The information about alignment is missing Juen (talk) 06:28, 20 January 2013 (UTC)

Both {f,g}disk handle alignment automatically. Why introduce erroneous info to the already bloated article? Graysky (talk) 13:48, 20 January 2013 (UTC)

What about F2FS?

In the Choice of Filesystem section, isn't it time to include some information about F2FS since Linux Kernel 3.8 Includes F2FS File System for Solid State Storage

Perhaps, but after examining this performance comparison by Phoronix, you have to ask if the (slight) performance advantage of F2FS outweighs the stability and support of ext4.
Might the article become more bloated and confusing for little or no real advantage ? Kal (talk) 17:12, 19 August 2013 (UTC)