Difference between revisions of "Talk:Solid State Drives"

From ArchWiki
Jump to: navigation, search
(Using GPT - Modern Method)
(What about F2FS?: Response regarding not providing information about F2FS)
(11 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== Get head and cylinder number ==
 
@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?
 
 
*Ted Tso recommends using a setting of 224*56 (=2^8*49) which results in (2^8*512=) 128 KiB alignment
 
*While others advocate a setting of 32*32 (=2^10) which results in (2^10*512=) 512 KiB alignment
 
 
@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.
 
 
@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?
 
 
@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.
 
 
== GPT anyone? ==
 
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)
 
 
@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)
 
 
While I think GPT is a good idea, it requires another bootloader than Grub. Since Grub2 is an unholy mess, and the other alternatives are far from common, I think it is a little harsh to call the fdisk/MBR approach "DEPRECATED". Especially since the latest fdisk has sane defaults for SSDs (with respect to alignment). I'm probably going to rewrite the fdisk/MBR section, to reflect changes in the latest version of fdisk, and change the wording to be less dramatic than "PREFERRED/DEPRECATED". Any objections? --[[User:AsmundEr|AsmundEr]] 11:40, 29 January 2012 (EST)
 
 
I don't think grub2 is an unholy mess at all.  Very usable and reliable.  I dunno about the latest fdisk, but I agree with you about using less harse language giving users the two options. [[User:Graysky|Graysky]] 12:06, 29 January 2012 (EST)
 
 
I guess we agree to disagree on grub2. Personally, I don't like it. But I've rewritten the GPT and the MBR sections, in what I hope is a fairly balanced way. In particular, I added a subsection at the start of the GPT section, which guides the user in choosing between GPT and MBR. Does this look OK to you? [[User:AsmundEr|AsmundEr]] 10:39, 31 January 2012 (EST)
 
 
== AHCI ==
 
Dispite common practice and believes 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
 
 
This guide is 3 years old - I don't know if there is an actual one, but this guide was only for the OCZ Core Series back in 2008.
 
 
--[[User:Evilandi666|Evilandi666]] 20:46, 14 June 2011 (EDT)
 
 
 
Still there is no need for AHCI in order to enable TRIM. The two having nothing to do with each other. AHCI would enable NCQ, which is useless if not harmful on a SSD. [http://http://forum-en.msi.com/faq/article/ide-sata-and-ahci-all-you-need-to-know forum msi]
 
 
I recommend to remove the misleading remark on AHCI in this wiki.
 
--[[User:Theking2|Theking2]] 06:25, 4 March 2012 (EST)
 
 
 
== DONT USE NOOP ==
 
== DONT USE NOOP ==
  
Line 47: Line 8:
 
::[[User:raymondcal|raymondcal]] 2012, may 29
 
::[[User:raymondcal|raymondcal]] 2012, may 29
  
== Partition Alignment ==
+
:::''CFQ has some optimizations for SSDs and if it detects a non-rotational
The Note might be wrong. In particular:
+
:::media which can support higher queue depth (multiple requests at in
''"Note: If one do not know the EBS of one's SSD, use a size of 512 KiB. Those numbers are greater or equal than all the current EBS."''
+
:::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
 +
 
 +
== Alignment ==
 +
 
 +
The information about alignment is missing
 +
[[User:Juen|Juen]] ([[User talk:Juen|talk]]) 06:28, 20 January 2013 (UTC)
  
I have contacted Kingston about my 64GB V200 SSD, this is their answer about the erase block size and page size (and some other questions):
 
''1) Disk Alignment is only necessary if you are cloning an hard drive with Windows XP installed - if you are doing a fresh installation or cloning / installing Vista or 7, you do not need to align.''
 
''2.1+2.2) Erase Block size / Page size data is on TS Intranet, E.B. is 2MB, P.S. is 8KByte/Page''
 
''2.3) All current SSDs support the TRIM feature in Windows 7 and 2008. The TRIM version in Apple OS supports only Apple certified SSDs.''
 
  
--[[User:Lucat|Lucat]] 14:38, 20 February 2012 (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)
  
== <s> Using GPT - Modern Method </s> ==
+
== What about F2FS? ==
  
"Note: ... GRUB (version 2.0.x), which requires a GPT formatted disc."
+
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]
Does GRUB 2 really ''require'' GPT? Or am I mis-reading this?
+
--[[User:Lapimate|Lapimate]] ([[User talk:Lapimate|talk]]) 04:35, 26 July 2012 (UTC)
+
  
:I just noticed this as well. I don't believe GRUB2 requires GPT formatting. I am using a MBR-formatted disc with GRUB2. Also, other wiki pages seem to disagree with the note as well: [[GPT#BIOS_systems]] [[GRUB#Preliminary_Requirements_for_GRUB2]]
+
: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.
:[[User:itsjareds|itsjareds]] 09:08, 03 August 2012 (EST)
+
: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)
:: Fixed in [[Partitioning]]. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:55, 28 September 2012 (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.'' -- [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 20:26, 17 November 2013 (UTC)

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)