Date: Fri, 29 Mar 2024 00:34:42 +0000 (UTC) Message-ID: <91696356.8390.1711672482261@support.blancco.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8389_1240523290.1711672482261" ------=_Part_8389_1240523290.1711672482261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
SSDs differ in a ma= jor way from HDDs because they store data on NAND semiconduc= tor arrays. One SSD typically has multiple (4-16) NAND flash chips. Ea= ch of these chips are divided into blocks (around million NAND cells) which= are further divided into pages (thousands of NAND cells). = Pages are further divided into individual cells. Depending on the technolog= y each cell can store 1-3 bits of data.
Due to the structure and technology&n= bsp;of the NAND cell array there are a few factors that make data managemen= t in an SSD an interesting task:
All these factors make copying, movin= g, and duplicating of data necessary. This adds to complexity of how t= he data is distributed in the NAND cells. The data becomes fragmented and t= here will be large amounts of stale data.
SSDs have a built in controller (flas= h controller chip) that manages the data and keeps track of its&n= bsp;physical location. When the operating system sends a read or = write command it goes through the flash controller which then translates th= e command. The operating system does not actually see the flash controller = commands. As a result the operating system can not keep track of the physic= al location of the data. It has been shown that operating system = sanitize (overwrite data with some pattern) commands on SSDs do not necessa= rily purge all data because the flash controller may translate the command = so that it does not apply to all instances of data.
Related links: