Talk:Solid State Drives

From ArchWiki
Revision as of 21:38, 21 December 2011 by Tama00 (Talk | contribs)

Jump to: navigation, search

@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 gdisk /dev/sda and create as many partitions you want and it will be created at sector 2048 by default! Else you can also suggest using fdisk -cu /dev/sda (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. 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. 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 ? Tcourbon 16:31, 11 November 2010 (EST)

ext4 discard option

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 : ext4.txt in kernel doc). Consequently I've added a paragraph about that. Tcourbon 08:43, 18 September 2010 (EDT)

I/O Scheduler

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. Tcourbon 19:22, 12 November 2010 (EST)

Whoops, sorry about that...it hadn't occurred to me when I edited the section. At least all is well now, though. :) --Ichifish 22:00, 8 December 2010 (EST)

AHCI

Dispite common practice and believes OCZ discourages the use of AHCI on (their) SSD drives [1] 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.

--Evilandi666 20:46, 14 June 2011 (EDT)

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.