Misplaced Pages

Talk:Solid-state drive

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 02:25, 30 October 2015 (Archiving 2 discussion(s) to Talk:Solid-state drive/Archive 4) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 02:25, 30 October 2015 by Lowercase sigmabot III (talk | contribs) (Archiving 2 discussion(s) to Talk:Solid-state drive/Archive 4) (bot)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
This is the talk page for discussing improvements to the Solid-state drive article.
This is not a forum for general discussion of the article's subject.
Article policies
Find sources: Google (books · news · scholar · free images · WP refs· FENS · JSTOR · TWL
WikiProject iconComputing C‑class High‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
CThis article has been rated as C-class on Misplaced Pages's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (assessed as High-importance).

The contents of the Disk on module page were merged into Solid-state drive on July 21, 2014‎. For the contribution history and old versions of the redirected page, please see Error: Invalid time. its history; for the discussion at that location, see its talk page.
The contents of the History of solid state drives page were merged into Solid-state drive on August 5, 2015. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page.
Archiving icon
Archives
See old talk page here


This page has archives. Sections older than 99 days may be automatically archived by Lowercase sigmabot III when more than 7 sections are present.

...and lower power

I suggest adding something about SSD being lower power than spinning drives, in the excellent phrase:

Compared with electromechanical disks, SSDs are typically more resistant to physical shock, run silently, have lower access time, and less latency.

Suggested change: add "require less power"

Compared with electromechanical disks, SSDs are typically more resistant to physical shock, run silently, require less power, have lower access time, and less latency.

Also, since there is an SLC vs MLC table, and now TLC is out, TLC should at least be introduced, perhaps with a reference to: Multi-level_cell

which has been updated to TLC.

WardXmodem (talk) 23:15, 18 September 2014 (UTC)

Hello! Hm, when compared to HDDs, not all SSDs require less power to operate. Just have a look at those power-hungry SSDs in form of PCI Express expansion cards – some older models needed additional power on top of what PCI Express provides, and even required active cooling. — Dsimic (talk | contribs) 10:47, 22 September 2014 (UTC)

eMMC vs SSDs

This HowToGeek article says that eMMC is different from SSD, I am a bit confused and was wondering if both this and the other article could explain the distinction.

The SSD article is in the Category:Solid-state_computer_storage while the MCC article is in Category:Solid-state_computer_storage_media, so my best guess is that SSD is the hardware while MCCs (cards) are software? But "card" sounds more like hardware to me... why would a card be called a media? --64.228.88.135 (talk) 23:18, 30 November 2014 (UTC)

I'm unable to find the Misplaced Pages article for eMCC as your wikilink was a disambiguation page. Can you provide a link please? --Chamith (talk) 00:00, 1 December 2014 (UTC)
Sorry, wrong consonant-doubling, I screwed up and wrote EMCC by mistake, fixed link to eMMC, embedded-multimedia, C is either card or controller, or possibly both. Right now solid-state storage redirects to this article but perhaps that is wrong and I am misled by that? Is there any kind of SSS besides drives? For example would a MultiMediaCard be described as a "solid state card" with cards being smaller/slower than drives? --64.228.88.135 (talk) 00:22, 1 December 2014 (UTC)
No, solid-state storage doesn't redirect to eMMC. Those are two different articles about two different storage medias. And you asked whether why eMMC falls into Category:Solid-state_computer_storage_media. Actually the word media doesn't mean software, it stands for a particular form of storage material for computer files, for example magnetic tape or discs. In other words it's a physical media. eMMCs are memory cards and it is also known/used as non-traditional SSDs. You can describe it as a "solid state card" if you like because it is a solid state storage media. Like hard drives SSD technology has improved a lot. You can consider eMMC as a basic step/version of SSDs available now.--Chamith (talk) 00:36, 1 December 2014 (UTC)

Thank you for the answer, beginning to clear up a bit. Based on MMCs being solid-stage storage but NOT a solid-state drive, I am going to change the solid-state storage redirect to this article into a disambig and use this SSC term. I also need to amend that edit based on misunderstanding to the MMC intro. --64.228.88.135 (talk) 01:13, 1 December 2014 (UTC)

Sales section (More information suggested)

Hi, can u please give us any information about the percentage of how many notebooks and desktop systems have those SSDs integrated? And how many computers will have them in future? --Martin — Preceding unsigned comment added by 47w0rmh0le (talkcontribs) 17:26, 22 December 2014 (UTC)

SSD automatically fragments everything to avoid hot spots?

Pink love 1998 (talk · contribs) added this to the SSD/HD comparison table, in the row about fragmentation:

The critical purpose of the SSD algorithm is to distribute the data to various 
locations to prevent heat build up on a particular spot, so SSD's are typically 
always fragmented.

with edit comment:

Added info, please don't delete I don't know how to insert references and
advise you to read about SSD's

Inserting references is only barely more complicated than just typing the reference info in prose. Just add <ref> (your reference) </ref> following your text. If you want to be precise about location, the ref goes before any immediately following space, but after any immediately following punctuation.(like here) Others will improve the formatting by using a cite template. Eventually you'll pick up on that.

Or, you could add a section to the talk page here, giving your refs. Someone else will pick them up and put them in the article.

However, even if referenced, this claim raises an issue, and this is the real reason I deleted it. When most people speak of "fragmentation" on a hard drive, we're talking about the fact that large (and sometimes small) files do not occupy contiguous ranges of LBAs. This fragmentation is visible to a file system from the outside of the drive, can be corrected by defragmenters, etc. This has well-known impact on HD performance. It even impacts SSDs, although minimally: to access a part of the file that crosses an extent boundary, two different I/O requests must be issued by the FSD and implemented by the disk driver and other drivers in the stack.

The... call it distribution of content from sequential LBAs to different areas of the chips in an SSD is different. It is not visible to e.g. file system drivers, and a defragmentation run would not "fix" it. To the host speaking to the drive through its SATA connector, a file that occupies sequential LBAs still appears to be contiguous even though those LBAs might not be physically contiguous on the chips.

There is no analog to this in a normal hard drive, other than the occasional "sparing" of bad sectors.

If this point can be referenced to a WP:RS, it certainly belongs in the article. But I don't think it belongs in the table row that discusses file system fragmentation, certainly not as the first sentence in the entry for SSDs. That table row is just not talking about this sort of thing. Wherever it goes, it needs to be described so as to distinguish it from the non-contiguous-LBA sort of fragmentation. Jeh (talk) 21:04, 13 January 2015 (UTC)

Yes, isn't heat the reasonable cause for the fragmentation. The SSD keep track of the next memory location using a link pointer. With the argument of latency (very low latency consider it as RAM in RAM the access speed of all locations is the same) it doesn't matter where the data is stored and because of the higher latency compared to that of HDD, defragmentation is needed because it takes longer to access data from random location(it's funny do you know that ssd uses DDR2 ram technology) . — Preceding unsigned comment added by Pink love 1998 (talkcontribs) 22:28, 13 January 2015 (UTC)
Hello! As Jeh already explained it very well, fragmentation pretty much doesn't exist in the context of SSDs. Pink love 1998, your post seems highly confused, as I simply don't understand what heat, link pointers, and DDR2-related technology you refer to? Again, defragmenting an SSD can't do anything but shorten its life by wearing out underlying flash memory. — Dsimic (talk | contribs) 00:12, 14 January 2015 (UTC)
Oh, fragmentation still exists. It just doesn't matter (except only just barely due to increased numbers of I/O requests to the drive).
No, SSDs don't use DDR2 technology. DDR means "dual data rate", which describes the bus the DIMMs plug into, not the memory cell structure. Jeh (talk) 02:00, 14 January 2015 (UTC)
Right, thanks for the correction. I didn't express myself clearly enough, it should've been something like "fragmentation pretty much doesn't matter in the context of SSDs, compared to the way it affects the operation of HDDs". At the same time, SSDs might use DDR2 memory for their buffers or storage of in-memory metadata structures, but that has nothing to do with the fragmentation of stored data. — Dsimic (talk | contribs) 02:33, 14 January 2015 (UTC)

Over provisioning

A section on over provisioning would be useful imo. Its a popular issue is discussed alot. Chendy (talk) 14:30, 12 February 2015 (UTC)

Maximize SSD Lifetime and Performance With Over-Provisioning

Hello! Over-provisioning is already mentioned a few times in the article, linking the term to the Flash over-provisioning article (better said, a redirect), which provides a rather good description. Repeating that in greater detail might be pretty much redundant, if you agree. — Dsimic (talk | contribs) 03:12, 17 February 2015 (UTC)

Amdahl's law

"In applications where hard disk seeks are the limiting factor, this results in faster boot and application launch times (see Amdahl's law)." I know the law and that SSDs are better under parallel I/O load, but is the law applicable here? Is it immediately obvious to people why or is this WP:OR? Note, I didn't find the law in the ref (the first page, there are 17..). comp.arch (talk) 13:09, 27 February 2015 (UTC)

Hello! Well, Amdahl's law is "used to find the maximum expected improvement to an overall system when only part of the system is improved". SSDs are obviously only one part of a computer system, but I'd remove the "(see Amdahl's law)" wording anyway. — Dsimic (talk | contribs) 12:19, 2 March 2015 (UTC)

conventional hard drives

Congratulations, now most web pages and government documentation refer to Conventional Hard Drives (instead of Magnetic Hard Drives, etc ). Is it possible to state that Conventional means the majority of the mechanical/magnetic hard drives at the time of writing?

10 years time, conventional may mean a completely new type of Hard Drive. — Preceding unsigned comment added by 164.39.36.212 (talk) 14:56, 29 October 2015 (UTC)

Categories: