Difference between revisions of "Talk:Solid State Drives"

From ArchWiki
Jump to: navigation, search
(What about F2FS?: Response regarding not providing information about F2FS)
(34 intermediate revisions by 15 users not shown)
Line 1: Line 1:
@Aedit - thank you very much for the contribution to this article.  Can you explain how you arrived at the numbers that relate to the head and cylinder choices?  2^8 times 49 and how does that translate into 2^8 times 512 = 128 KiB alignment?
+
== DONT USE NOOP ==
  
*Ted Tso recommends using a setting of 224*56 (=2^8*49) which results in (2^8*512=) 128 KiB alignment
+
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.
*While others advocate a setting of 32*32 (=2^10) which results in (2^10*512=) 512 KiB alignment
+
:Interesting assertion... do you have any data or a source to back it up?
 +
:[[User:Graysky|Graysky]] 17:20, 21 December 2011 (EST)
  
@Graysky - you're welcome. The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). So factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.
+
::It seems that the cfq scheduler already knows what to do when SSD is detected, so there is no use to change it.
 +
::[[User:raymondcal|raymondcal]] 2012, may 29
  
@Aedit - interesting.  I have an Intel X25-M G2 and I used the -H 32 -S 32 to give a 512 KiB alignment which should be fine, yet Ted suggests using the values that give a 128 KiB alignment (although 128 is a factor of 512).  Is there any advantage to using the smaller number, or to put it another way, is there a disadvantage to using the larger number?
+
:::''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.''
 +
:::https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt
 +
:::[[User:ushi|ushi]] 2013, November 03
  
@Graysky: As you say, a disk aligned to 512k is also aligned to 256k,128k... etc. The only disadvantage of larger alignment I know is that a little space is wasted by putting partition boundaries on the larger alignment. I suspect Ted thought the X25-M has a 128k erase block but I also have seen reports of 512k. Is there a definitive reference? Very nice wiki page btw - thanks.
+
== Alignment ==
  
== GPT anyone? ==
+
The information about alignment is missing
Did you ever think about directing the user to a painless partitionning scheme like GPT? You can just use <tt>gdisk /dev/sda</tt> and create as many partitions you want and it will be created at sector 2048 by default! Else you can also suggest using <tt>fdisk -cu /dev/sda</tt> (with a recent version of fdisk) which will do about the same except with logical partitions. Anyway, no one uses DOS anymore, just think about it twice, the famous extended partition was really a big big hack which should be forgotten. Booting XP with a partition starting at sector 2048 made with fdisk just works anyway. [[User:TiCPU|TiCPU]] 02:12, 9 July 2010 (EDT)
+
[[User:Juen|Juen]] ([[User talk:Juen|talk]]) 06:28, 20 January 2013 (UTC)
  
@TiCPU: I just buy another SSD (the current one will go into the laptop) and I consider using GPT, since I won't install XP nor Seven on it and since after this article GPT allow the use of GPT and Gparted that do auto-alignement. So if either you could write something, or when I'll try to partion my drive I'll write what I do. [[User:Tcourbon|Tcourbon]] 09:56, 30 September 2010 (EDT)
 
  
I write something based on my notes taken during my arch install using GPT and experimentation with gdisk and a raw disk image. Can someone review it ? [[User:Tcourbon|Tcourbon]] 16:31, 11 November 2010 (EST)
+
Both {f,g}disk handle alignment automatically. Why introduce erroneous info to the already bloated article?
 +
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 13:48, 20 January 2013 (UTC)
  
== ext4 discard option ==
+
== What about F2FS? ==
I believe ext4 is a sensible filesystem choice for an SSD as long as you enable the TRIMM command using the discard otpion in fstab (source : [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/ext4.txt;h=e1def1786e5074e5d8f3cf89b5f14cbfc9fab4af;hb=HEAD ext4.txt in kernel doc]).
+
Consequently I've added a paragraph about that. [[User:Tcourbon|Tcourbon]] 08:43, 18 September 2010 (EDT)
+
  
== I/O Scheduler ==
+
In the [https://wiki.archlinux.org/index.php/Solid_State_Drives#Choice_of_Filesystem Choice of Filesystem] section, isn't it time to include some information about [http://en.wikipedia.org/wiki/F2FS F2FS] since [http://hothardware.com/News/Linux-Kernel-38-Released-Includes-F2Fs-Files-System-for-Solid-State-Storage/ Linux Kernel 3.8 Includes F2FS File System for Solid State Storage]
  
I don't understand why the part on I/O scheduler was changed : the new way to alter the scheduling on SSD is far from optimal since not every as a SSD as only drive. I think we should add that method to change the scheduler as a side note for this particular setup. [[User:Tcourbon|Tcourbon]] 19:22, 12 November 2010 (EST)
+
:Perhaps, but after examining this [http://www.phoronix.com/scan.php?page=article&item=linux_f2fs_benchmarks&num=1 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 ?  [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 17:12, 19 August 2013 (UTC)
Whoops, sorry about that...it hadn't occurred to me when I edited the section. At least all is well now, though. :) --[[User:Ichifish|Ichifish]] 22:00, 8 December 2010 (EST)
+
::See [[ArchWiki:About#Comprehensive]]. Information relevant to Arch Linux should be provided so that the end user to make the decision. As I understand it, Arch Wiki is meant to be ''descriptive'' not ''prescriptive.'' -- [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 20:26, 17 November 2013 (UTC)
 
+
== AHCI ==
+
Dispite common practice OCZ discourages the use of AHCI on (their) SSD drives [http://www.ocztechnology.com/res_old/images/Configuring-and-Setting-Up-SSDs.pdf] Both AHCI and IDE mode support the TRIM command, so it is recommended to use IDE SSD drives.
+
--[[User:theking2]] 15:25, April 20, 2011
+

Revision as of 20:26, 17 November 2013

DONT USE NOOP

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.
https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt
ushi 2013, November 03

Alignment

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)
See ArchWiki:About#Comprehensive. Information relevant to Arch Linux should be provided so that the end user to make the decision. As I understand it, Arch Wiki is meant to be descriptive not prescriptive. -- AdamT (Talk) 20:26, 17 November 2013 (UTC)