<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Sabrent Rocket Q4 PCIe 4 NVMe SSD Review &#8211; Gen 4 Speed 4TB Capacity and Value	</title>
	<atom:link href="https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/</link>
	<description>The Worlds Dedicated SSD Education and Review Resource &#124;</description>
	<lastBuildDate>Tue, 17 Nov 2020 01:01:51 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: Les Tokar		</title>
		<link>https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/#comment-54379</link>

		<dc:creator><![CDATA[Les Tokar]]></dc:creator>
		<pubDate>Tue, 17 Nov 2020 01:01:51 +0000</pubDate>
		<guid isPermaLink="false">https://www.thessdreview.com/?p=103319#comment-54379</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/#comment-53482&quot;&gt;Christian&lt;/a&gt;.

Unfortunately, I cannot and thank you for replying.  I don&#039;t play with overprovisioning at all because...as you said... some drives brick.  Typically, we want to test them to the extent that the reader can determine if it is the drive for them, and also so they can imitate same in their tests.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/#comment-53482">Christian</a>.</p>
<p>Unfortunately, I cannot and thank you for replying.  I don&#8217;t play with overprovisioning at all because&#8230;as you said&#8230; some drives brick.  Typically, we want to test them to the extent that the reader can determine if it is the drive for them, and also so they can imitate same in their tests.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Christian		</title>
		<link>https://www.thessdreview.com/our-reviews/nvme/sabrent-rocket-q4-pcie-4-nvme-ssd-review-gen-4-speed-4tb-capacity-and-value/#comment-53482</link>

		<dc:creator><![CDATA[Christian]]></dc:creator>
		<pubDate>Wed, 04 Nov 2020 18:44:44 +0000</pubDate>
		<guid isPermaLink="false">https://www.thessdreview.com/?p=103319#comment-53482</guid>

					<description><![CDATA[Dear Les,


I think there is a typo in the last few sentences on the first page, were the per seconds part should not be there after the capacity in megabyte (gigabyte, after all?) &quot;... 3725MB/s available for user storage once formatted ...&quot;

Is the difference related to the 1000 vs 1024 marketing thingy or simply to overprovisioning practices.

Also, while on topic of overprovisioning. I usually format and partition SSDs with Partition Guru. The way I do it is dividing the total capacity in bytes by the number of storage chips on the drive. Then I divide this by eight, so that I know how many 4K(=8 times 512 bytes) aligned sectors essentially there are. Then I size the very first part for EFI System Partition (ESP) to be large enough to contain the recommend 100 megabytes size. Whatever the amount in bytes, I subtract this from the result of the division, and create the first NTFS partition so that the sum of &quot;the very first MBR sector + ESP + the first partition&quot; is exactly, down to the byte, as large as a single chip can hold. To size the remaining partitions is simpler, as from that point on I only have to decide on exactly how many chips a given partition spans out over.

So, I usually get extremely, really down to the bytes precise results when examining the sector count boundaries afterwards. But on rare occasions I just brick the drive, simple as that ...

And that made me wonder in trying to be this precise I inadvertedly wreak havoc in the overprovisioning proper, i.e. the way it is engineered on circuit logic level.

So, long story short, my question proper:

The overprovisioned part, say X percentage of a drive&#039;s total capacity is ...

a) an a single allocated and continuous area on one of the chips?

or

b) this X percentage is further divided by the number of chips, and each of them contains an equal sized OP area (the sum of which essentially being the X percentage in total)?


I do hope you can enligthen me ;-)


Kind regards,
-Christian]]></description>
			<content:encoded><![CDATA[<p>Dear Les,</p>
<p>I think there is a typo in the last few sentences on the first page, were the per seconds part should not be there after the capacity in megabyte (gigabyte, after all?) &#8220;&#8230; 3725MB/s available for user storage once formatted &#8230;&#8221;</p>
<p>Is the difference related to the 1000 vs 1024 marketing thingy or simply to overprovisioning practices.</p>
<p>Also, while on topic of overprovisioning. I usually format and partition SSDs with Partition Guru. The way I do it is dividing the total capacity in bytes by the number of storage chips on the drive. Then I divide this by eight, so that I know how many 4K(=8 times 512 bytes) aligned sectors essentially there are. Then I size the very first part for EFI System Partition (ESP) to be large enough to contain the recommend 100 megabytes size. Whatever the amount in bytes, I subtract this from the result of the division, and create the first NTFS partition so that the sum of &#8220;the very first MBR sector + ESP + the first partition&#8221; is exactly, down to the byte, as large as a single chip can hold. To size the remaining partitions is simpler, as from that point on I only have to decide on exactly how many chips a given partition spans out over.</p>
<p>So, I usually get extremely, really down to the bytes precise results when examining the sector count boundaries afterwards. But on rare occasions I just brick the drive, simple as that &#8230;</p>
<p>And that made me wonder in trying to be this precise I inadvertedly wreak havoc in the overprovisioning proper, i.e. the way it is engineered on circuit logic level.</p>
<p>So, long story short, my question proper:</p>
<p>The overprovisioned part, say X percentage of a drive&#8217;s total capacity is &#8230;</p>
<p>a) an a single allocated and continuous area on one of the chips?</p>
<p>or</p>
<p>b) this X percentage is further divided by the number of chips, and each of them contains an equal sized OP area (the sum of which essentially being the X percentage in total)?</p>
<p>I do hope you can enligthen me 😉</p>
<p>Kind regards,<br />
-Christian</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
