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.
- It's reworked. Now only the intro links out to the wikipedia list of optimized filesystems and we give indication of TRIM support as you suggested. Closing. --Indigo (talk) 10:13, 4 August 2016 (UTC)
Using discard option to mount root directory on xfs file system is no use
After I modified /etc/fstab and add the discard option to the / entry, I reboot my laptop. But when I use mount command to check the options about the file system how to be mounted, there is no discard option in the / entry. and the other directory such as /home and /boot are mounted with discard option correctly. I have tried to remount root directory with discard option, but there is no use.
- Did this perhaps solve itself after the next initramfs generation? --Indigo (talk) 10:22, 4 August 2016 (UTC)
Add TRIM (and potentially other sections) to this wiki article
It's very unintuitive to have e.g. TRIM information on a different page.
- It's hard to find via search
- It is essential for the lifetime of a SSD
- there is only *one* link to the article to TRIM!
I think the page was fine before this one guy changed it dramatically relatively recently. I don't get why we should split a moderately sized wiki page into thousand small pages.
- "This one guy" split it recently because Solid State Drives/Tips and tricks has a lot of tangential and generaly poorly structured content which doesn't fit on the main page (plus with modern SSDs, TRIM is nowhere near the "essential" you claim it be). If you're suggesting to merge the sub-article back to the main page, you first need to do some serious clean up. -- Alad (talk) 12:35, 27 July 2016 (UTC)
- I don't see how TRIM is more tangential than Solid_State_Drives#Firmware_updates, the current backbone of the page. Besides, moving content to a subpage just because it doesn't fit to the main page is not going to help maintenance, you claim that serious cleanup has to be done but that could have been done on the main page equally well or better due to the lack of potential shuffling. -- Lahwaacz (talk) 13:02, 27 July 2016 (UTC)
- How about:
- 1. Reduce Solid_State_Drives/Tips_and_tricks#Reduce_disk_reads.2Fwrites to a minimum (stuff like profile-sync-daemon has its own page)
- 2. Remove the table in Solid_State_Drives/Tips_and_tricks#TRIM
- 3. Remove duplication with File systems in Solid_State_Drives#Choice_of_filesystem
- 4. Move back TRIM, SSD security (and if remaining) Reduce disk reads to the main article
- 5. Move Solid_State_Drives#Firmware_updates to a subpage
- -- Alad (talk) 13:23, 27 July 2016 (UTC)
- How about:
- I added a TRIM redirect. Not difficult to find anymore. -- Rdeckard (talk) 12:40, 27 July 2016 (UTC)
- Good idea, Rdeckard.
- I find the table in  pretty intuitive; any info from  could easily be merged into a table column. Pity you did not propose improvals you had in mind with a Template:Move first Alad. Result is dissatisfaction on all sides :/ This article has 148 contributors and 76 watchers (these stats are just shy of systemd/2; its size too). --Indigo (talk) 19:11, 27 July 2016 (UTC)
- The discussion in Talk:Solid_State_Drives#Choice_of_filesystem shows this sort of data is pointless without references. If you have some to add, feel free to change the article accordingly.
- Besides that, are there remarks on the new (or rather, old) layout of the article? -- Alad (talk) 19:32, 27 July 2016 (UTC)
- Thanks, I'll see if I can contribute re the template later. Regarding article layout, I think moving #firmware to a subpage is more straight forward than the #TRIM section. This simply because #TRIM is a matter of configuration of the OS, hence, directly Arch related. But having firmware as a #Troubleshooting subsection or its own #Troubleshooting_firmware section (both fine) like suggested above works well IMO. --Indigo (talk) 07:34, 30 July 2016 (UTC)
Remove the section on continuous trim
The section on continuous trim should be removed and a warning added to the trim timer section. There are about a million reasons why people shouldn't use continuous trim and unless there is a very compelling reason for someone to use it that I don't know of, that information doesn't seem useful enough to stick around and could cause a lot of harm.
- Lack of information can cause a lot of harm as well, so I think we'd better keep the section. -- Lahwaacz (talk) 13:50, 29 July 2016 (UTC)
- I've trimmed the warning a little, so now I think the only reason against is performance related, although the given link for Theodor Ts'o's opinion doesn't work anymore. -- Lahwaacz (talk) 16:42, 29 July 2016 (UTC)
- The link does not work, because gmane is unavailable at current (it is likely someone else will resume its web service so that links will return to availabilty).
- I agree regarding continuous trim, it is important info. (I don't think we need the singular quote from the Ted T'so's rm'ed link, it dates).
- Also, one may argue, since the identification and blacklisting of unreliable devices (some are explicitly whitelisted for certain trim methods too) the reasons to mount with discard have grown. Another reason to have continuous trim enabled devices: Imagine your device runs at about ~66% capacity occupation. Since the drives don't hold a table what's trimmed in last run, this means that each timed fstrim runs over a third of the drive, again and again. With a discard mount flag, any freed up space is only trimmed once. Now how much wear-levelling difference this means, depends on usage pattern. The more static the data on the drive (e.g. a mailing list archive like gmane), the more proportionate wear from fstrim. Even if wear-levelling is not an issue with the device, letting it perform an action once instead of redundant times is a matter of efficiency. If you find this a compelling reason, I don't know. --Indigo (talk) 07:13, 30 July 2016 (UTC)