Difference between revisions of "Talk:Solid State Drives"

From ArchWiki
Jump to: navigation, search
(Ask for clarification about verifying TRIM support section.)
Line 15: Line 15:
:::[[User:ushi|ushi]] 2013, November 03
:::[[User:ushi|ushi]] 2013, November 03
::::So does anyone have any good data? My research says deadline is best and
::::that "cfq has some optimizations" doesn't mean it's better than others.
::::[[User:MindfulMonk|MindfulMonk]] ([[User talk:MindfulMonk|talk]]) 22:38, 5 July 2014 (UTC)
== Alignment ==
== Alignment ==

Revision as of 22:38, 5 July 2014


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
So does anyone have any good data? My research says deadline is best and
that "cfq has some optimizations" doesn't mean it's better than others.
MindfulMonk (talk) 22:38, 5 July 2014 (UTC)


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)

tune2fs -o discard != mkfs.ext4 -E discard

`mkfs.ext4 -E discard` will perform discard all blocks in target device only once (and faster mkfs optimize). Will not save to 'Default mount options' as tune2fs.--Bugmenot2 (talk) 13:50, 27 January 2014 (UTC)

Partition Alignment Verification

On my system 'blockdev --getalignoff /dev/sda5' returns zero, even though the partition seems not to be aligned optimally:

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd9a92553

Device    Boot     Start       End    Blocks  Id System
/dev/sda1 *         2048   1026047    512000   7 HPFS/NTFS/exFAT
/dev/sda2        1026048 479475711 239224832   7 HPFS/NTFS/exFAT
/dev/sda3      946051072 976771071  15360000   7 HPFS/NTFS/exFAT
/dev/sda4      479475712 946051071 233287680   5 Extended
/dev/sda5      479475775 518545791  19535008+ 83 Linux
/dev/sda6      518545855 541984626  11719386  83 Linux
/dev/sda7      541984690 557615871   7815591  82 Linux swap / Solaris
/dev/sda8      557615935 946051071 194217568+ 83 Linux

The command 'parted /dev/sda align-check optimal' gives the right message in my opinion: 'not aligned'. Should we replace blockdev command?

Plk (talk) 18:31, 31 May 2014 (UTC)

Verify Trim Support section ambiguous

This section implies that only the following results confirm that the drive has TRIM support:

       *    Data Set Management TRIM supported (limit 1 block)
       *    Deterministic read data after TRIM

My result when I run the command # hdparm -I /dev/sda | grep TRIM is as follows:

       *    Data Set Management TRIM supported (limit unknown)

I will assume that the lack of "Deterministic read data after TRIM" in my results is not a problem, and that my drive does support TRIM. If that's correct, shall we remove the unecessary line from the example? Either way, we should clarify what results are key to arriving at the conclusion that the drive does or does not support TRIM so there is as little ambiguity as possible. Lightnin (talk) 20:16, 2 June 2014 (UTC)