Thanks for the clarification. I suppose I read too much into the "shingled" analogy.
So, maybe you can answer my next question: is the policy to rewrite everything after a modification, until the end of the chunk? I had previously understood that you had to rewrite the entire chunk, but since each track overlaps the previous one, if you can partially overlap it on one write pass, it's not clear to me why you wouldn't be able to partially overlap it on another.
I once had an SMR explainer written on another site that has since closed (I miss Tom's IT Pro). The article was probably too long then, and is probably still too long now. In either case, here's a relevant bit -
The process of writing data to an SMR HDD is straightforward at first. The drive writes sequential data normally, and the tracks are overlapped (shingled) during the initial write process. However, if new (or modified) data needs to be placed near existing data, any modification of the existing sectors will overwrite the neighboring shingled tracks. Thus, an overwrite triggers a read-modify-write procedure due to the inevitable impact on the adjacent overlapped tracks. Unfortunately, random write activity also triggers this process, because any data dropped into a sector at random will affect overlapping tracks.
This overwrite process begins with the HDD reading all data that will be overwritten, then the data in the following sectors/tracks that are affected, and moving it to a cache. In the case of Seagate SMR drives, the cache consists of a section of the platter (rumored to be 20GB) used as persistent storage. The drive uses the persistent cache location on the platters to hold data as it reorganizes it. Once the data is reorganized, the drive rewrites it sequentially back to the home location.
An SMR HDD also utilizes DRAM caching to aggregate and sequentialize incoming random write data before writing it to the platters. The drive also uses the cache section of the platter to provide persistence for the data held in the volatile DRAM cache. The limited size of the platter-based cache speeds data operations because it reduces head movement as it transfers data into, and out of, the cache. The persistent cache can also theoretically be NAND flash-based, and it wouldn't be surprising to see that technique come to market to help address the inherent performance limitations associated with SMR.
The drive rewrites modified sectors and tracks when it returns the data from the cache to the home location. This process would require an entire re-write of the HDD (from the affected track) for every re-write operation if the drive were shingled end-to-end. The drive has tracks that are grouped into bands to avoid this scenario, and any track modification only requires reorganization to the end of the band.
HGST is utilizing 256MB bands in its inaugural offerings. Seagate indicates that the sizes of the bands are adjustable for custom drive workloads and applications. These adjustments will likely result in drives developed specifically for targeted use-cases as the technology progresses.
SMR's overlapped track structure is optimized for large sequential read/write operations, but the technique will struggle with any type of random write data.
To accomplish the complex data placement tasks, SMR HDDs remap the LBA tables. The graphic above is an example of the modified LBA mapping techniques utilized on an SMR drive. Even if the host writes data to the drive sequentially, the drive may not initially write the data in a contiguous fashion due to the LBA table remapping. This means that some portions of files that would normally be concentrated on the outer edge of the platter, for instance, could possibly end up on other portions of the platter as well, which will can affect performance consistency. This brings forth new challenges and an additional layer of complexity (in comparison to SSDs) that must be overcome to keep performance within expectations.
The read-write-modify process is very similar to how SSDs utilize a flash translation layer in tandem with overprovisioning, and it incurs a heavy performance penalty in some scenarios. Many of the engineering techniques utilized to abstract the LBA space, such as using dynamic LBA mapping in favor of static mapping, come from established SSD technology. It is ideal if this process of sequentializing incoming random data, and the read-write-modify process, happens at the software layer (as explained on the following page).
Facebook
Twitter
Instagram