Talk:Solid State Drives
Don't 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. —This unsigned comment is by Tama00 (talk) 22:38, 21 December 2011. Please sign your posts with ~~~~!
- 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
TRIM and RAID
The wiki article within the warning in the section Enable continuous TRIM by mount flag says: A possible patch has been posted on July 19, 2015."
The quoted spinics article seems to be saying that there is a serious kernel bug which impacts when SSD's are being used with linux software raid.
- The bug was manifested for particular brand SSD bios only, which were blacklisted. Since TRIM is a standard and other brands work fine, this issue was not regarded a kernel bug to my knowledge. Nonetheless, they may (have) merge(d) the patch to work-around the bios bugs. If someone has a related bug report where it is tracked or kernel commit, it would be useful to add, I agree. -Indigo (talk) 09:23, 27 September 2015 (UTC)
- Samsung's patch about data corruption are now merged, but full blacklist still here in Linux 4.5 https://github.com/torvalds/linux/blob/v4.5/drivers/ata/libata-core.c#L4223 for a lot of SDD brand, in particular all the popular Samsung 8 series (840|850 EVO|PRO). I still cannot find any information about the source issue and when it will be whitelisted. The article should warn user that all those SSD models should be avoided until a solution. Note that also --Nomorsad (talk) 11:03, 26 March 2016 (UTC)
Choice of filesystem
I will expand on the prior accuracy flag here:
The two sentences in the introduction of SSD#Choice of filesystem are ambiguous at best, "This section describes optimized filesystems to use on a SSD." followed by "It's still possible/required to use other filesystems, e.g. FAT32 for the EFI System Partition." may be understood as either "FAT32 is not optimized for SSD" or "the list below is not complete" or simply "using filesystems not listed below will still work".
The second part of the accuracy dispute is more serious, it does not describe "optimized" filesystems, but filesystems "with support for SSD/wear-leveling features". It's not necessarily a bad thing to describe only "support", it may very well be the only sensible way, but it shouldn't claim otherwise.