Would it improve the write performance to fill a reformatted drive with zeros?

14

3

I have a 2 TB drive which was filled to >99%. I’ve delete the partitions with fidsk and formatted them with mkfs.ext4.

So as far as I know, the actual data which was on the drive does still exist. Still the partition table was reassigned.

The question is: Would it improve the write performance for further write actions if the disk would be cleaned? With cleaned I mean fill the disk with zeros?

Something like

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

Brettetete

Posted 2015-10-16T22:04:06.170

Reputation: 2 057

8No advantage to having zero's to start with as it will overwrite anything that is there to begin with. – Moab – 2015-10-16T22:08:37.327

7If it was a SSD, the answer would be "hell no", because mkfs.ext4 actually uses TRIM to discard the entire partition's contents, so manually writing zeros on top of that would slightly reduce performance. – user1686 – 2015-10-16T22:56:09.333

2@grawity I have been wondering if there is any SSD which automatically turns writes of all zeros into TRIM instead. – kasperd – 2015-10-17T09:06:28.027

@kasperd: good follow-up question! – liori – 2015-10-17T18:00:35.263

Another possible follow up question: if said disk was a VM mounted on a SAN that did low level disk deplication, could that help (in that if the data that was deleted at the VM level, unless the system is using some VM-aware API, it would see to the SAN that all of those deleted blocks need to stick around, whereas setting them to all zeros would end up with a bunch of duplicated blocks all pointed to a all zero thing) – Foon – 2015-10-17T19:10:50.847

@Foon That's a very different question from what the OP is asking. It may be a valid question (it probably needs more details to be answerable) but it isn't this question. – a CVn – 2015-10-17T21:14:50.817

Why use bs=1? – user253751 – 2015-10-18T06:14:47.173

Not sure why no one has mentioned this - Particularly on a Hard Drive, you want to defragment the disk - this will re-order files so they are in contiguous blocks, which makes consecutive reads faster - in some cases dramatically so. – davidgo – 2016-03-11T08:28:33.123

Answers

36

No, it would not improve performance.

TL;DR: rotational magnetic hard disk drives don't work like that.

First, when you write any given data to a rotational magnetic-storage drive, that data gets transformed into magnetic domains that may actually look very different from the bit pattern you are writing. This is done in part because it's much easier to maintain synchronization when the pattern read back from the platter has a certain amount of variability, and for example a long string of "zero" or "one" values would make it very hard to maintain synchronization. (Have you read 26,393 bits, or 26,394 bits? How do you recognize the boundary between bits?) The techniques for doing this transformation between computer data bits and storable chunks have evolved over time; for example, look up Modified Frequency Modulation, MMFM, Group Code Recording and the more general technology of run-length limited encodings.

The actual recording process, such as HAMR, PMR, shingled and so on are orthgonal to this in that they describe the mechanics of how the magnetic domains are stored on the physical media.

Second, when you write new data to a sector, the magnetic domains of the relevant portions of the platter are simply set to the desired value. This is done regardless of what the previous magnetic domain was at that particular physical location. The platter is already spinning under the write head; first reading the current value, then writing the new value if and only if it's different, would cause each write to require two revolutions (or an extra head for each platter), causing write latency to double or greatly increasing the complexity of the drive, in turn increasing cost. Since the limiting factor in hard disk sequential I/O performance is how quickly each bit passes under the read/write head, this wouldn't even offer any benefit to the user. (As an aside, the limiting factor in random I/O performance is how fast the read/write head can be positioned at the desired cylinder and then the desired sector arrives under the head. The major reason why SSDs can be so fast in random I/O workloads is that they completely eliminate both of these factors.)

As pointed out by JakeGould, one reason why you might want to overwrite the drive with some fixed pattern (such as all zeroes) would be to ensure that no remnants of previously stored data can be recovered, either deliberately or accidentally. But doing so will not have any effect on the drive's performance going forward, for the reasons stated above. Another reason, which could conceivably be said to "improve performance", as pointed out by liori, is to help compression of unused portions of stored disk images, but even that doesn't improve the performance of the system in use.

a CVn

Posted 2015-10-16T22:04:06.170

Reputation: 26 553

3Another reason for zeroing partitions/drives is if you plan to take raw partition/drive dump (e.g. as a backup, making an OS image for multiple machines, as a system migration technique, etc.). Zeros compress well, which might be different from whatever previous content was stored on the drive. – liori – 2015-10-17T17:59:24.993

@liori Good point, but that's not a common end-user scenario, and it's pretty far from what the OP is describing. – a CVn – 2015-10-17T18:44:31.427

So optical discs are either non-rotational or are magnetic? – Max Ried – 2015-10-18T08:13:14.257

4

You say this:

The question is: Would it improve the write performance for further write actions if the disk would be cleaned? With cleaned I mean fill the disk with zeros?

100% nope. Writing zeros to a disk does not improve performance. You would only do that to destroy data. So knowing that, you say this:

So as far as I know, the actual data which was on the drive does still exist.

Technically yes… The data that previously existed on the drive still exists on the drive on some fundamental level. That said, it does not exist in a form that is easy to access or recover at this point but it might be a concern if you are truly worried about the data being compromised by someone willing to make the effort to recover those fragments of data that remain.

So if security and privacy is a concern, then you might want to write zeros to the drive to make sure all free space is truly wiped. But security and privacy is the absolute only reason you would ever wipe out free space with zeros since doing something like that never improves performance.

JakeGould

Posted 2015-10-16T22:04:06.170

Reputation: 38 217

Does running a tool like recover not count as "easy"? It would turn up lots and lots of files on a full drive that had just been mkfs'd. – hobbs – 2015-10-18T07:54:23.233

0

My two cents gift tor all of you is my own experience, YES it helps but with caution.

I had a lot SSDs and based on my own tests i recomend to full fill with zeros prior to rewrite master table and instead of delete partitions, recreate master table.

Later i will explain why, but steps would be ˋddˋ to fill entire SSD, use bs=1M, much faster than bs=1, and forget the count parameter to make it go till end (it will give the error of no more space when reach the end, that is spected so don't worry to see such error, it must be shown); after full fill use gparted or whatever you want to write a master table (MBR/GPT/etc) as needed, this will 'trim' all the disk, then create partitions with desired format, etc.

Why fill it with zeros? Short anwser is that my experience is when i fill it with zeros some SSDs that where giving 2-24 unreadable blocks got fixed, no more blocks unreable anymore.

Now first thing i do when i recieve a new SSD, prior to use it, is full fill it with zeros, to ensure i will not suffer again the common random errors of unreadable 1KiB blocks.

My experience: Using software to read / test the whole SSD (it tells you how much time takes to read each 'sector') i was getting a lot of pairs of '512byte secttors' (1KiB blocks) that are unreable, and their position changes randomly and number of fails varies from 2 to 24, etc.; after full fill with zeroes and recreate the master table (that vauses trim) no more unreadable sectors.

My crash test: Instesd of filling with zeros to recover from such errors, i let one SSD to be used, after a few hours and with only less than one terabyte written to it (120GiB SSD) it died misserably, it does not allow any access to it anymore, motherboard bios can not see it, usb enclosures freezes when accessing it, so neither Windows see it, neither Linix fdisk see it.

It was a 'die' test with multiple SSD i had buy at the same time, identical ones... all i did not zeroed are died, rest have a lot of blocks reallocated, but without any unreadable errors anymore.

Of course, my conclusion is that all SSDs are not reliable, no matter what brand and capacity.

So first thing with them, in my experience, is to force them to full fill at least once, better with zeros than with random (it is faster).

More, most SSD do internal trim when written with zeros (garbe recollection algorithms, etc).

Also, if you first fill them once, any block that gives write error get reallocated. It is much better that such thing happens with no vital data, when written zeros if data got lost (all was zeros) it is not relevant, but if data is 'vital' to operating system it is very bad.

Most SSD reallocate do that but loosing the data on the block that gave write error, only 'enterprise' (they cost >10€ per GiB) do a re-try the write after reallocate correctly. Some SSD will also loose all the other 'sectors' on such failed block (like doing a 'discard').

So best, try it first, after full fill, check SMART data to see how much reallocations can still be done.

It is not so important how much reallocations had been done, most SSDs came from manufacter with some blocks already reallocated, find one with zero is less than 1%, so the important is the ratio, reallocate versus future possi le reallocations.

Its is my experience after hundreds of SSDs died along 5 five years, some died in the first hour of use, other in a week, others in a month; but all i'd done such zero full fill did live for 2 to 3 years, with a 13GiB written each day, 3*365*13 GiB = 13.9TiB written, much less than manufatures say (>100TiB).

But speed matters, most if on Windows (on Linux a good 2xHDD LVM2 striping gives neat same boot times but thay do not fail in >25 years), so using SSD with a price of 0.21€ per Gigabyte (120GiB = 25€) is worth it (for Windows), among they muct be changed after 2 or 3 years; i hope technology will improve reliability.

For Linux i do not want anymore SSD till thay will be more reliable, but for Windows (Vista, 7 and 10) system partition is a must (boot times ten times lower in some cases, with Windows Vista, instead of >30min boot it boots on >4min on my old laptop).

Yes, full fill with zeroes is a must, given my experience.

But, only when you recieve the SSD and prior to use it for anything.

Tip: If SSD does not do garbage collection well and operating system does not tell it to trimm all, better do a full fill with zeros, at end that is what internally in the SSD when it discard blocks. Also writting zeros will clear electronic, that is why it helps to recover failing read blocks.

And also, every time you change data on it, try yo do a clone, the SSD will inform the write was OK, also on unreadble sectors (they can be written OK but not readed), no operating system is designed to support such condition, they all supose if wtite is OK data can be readed; do not confuse readable with read different data thsn what was written.

That is my experience with SSDs and HDDs. For Windows boot and apps i use SSD but allways with a clone done on normal HDDs since SSD die in less than 3 years, but gor Linux i use 2x or 3x good 2.5" HDD ti get similar times on normal use as what SSD would give, but lasting much longer (>25 years).

I am not up to pay >1000€ for 100GiB entetprise SSD that works well for 10 years, i preffer to pay 25€ for 130GiB every 2 or 3 years. Price matters 100€ per year (enterprise) versus 10€ per year (Yucon, Samsung, etc), just do the maths.

Claudio

Posted 2015-10-16T22:04:06.170

Reputation: 9

Forcing to write over bad sectors is indeed a quite reliable way to "fix" them, as long as there are reserved sectors still available. – confetti – 2018-09-08T11:46:30.380