Are disk sector writes atomic?

Question

Clarified Question:

When the OS sends the command to write a sector to disk is it atomic? i.e. Write of new data succeeds fully or old data is left intact should the power fail immediately following the write command. I don't care about what happens in multiple sector writes - torn pages are acceptable.

Old Question:

Say you have old data X on disk, you write new data Y over it, and a tree falls on the power line during that write. With no fancy UPS or battery backed disk controller, you can end up with a torn page, where the data on disk is part X and part Y. Can you ever end up with a situation where the data on disk is part X, part Y, and part garbage?

I've been trying to understand the design of ACID systems like databases, and to my naive thinking, it seems firebird, which does not use a write-ahead log, is relying that a given write will not destroy old data (X) - only fail to fully write new data (Y). That means that if part of X is being overwritten, only the part of X that is being overwritten can be changed, not the part of X we intend to keep.

To clarify, this means if you have a page sized buffer, say 4096 bytes, filled with half Y, half X that we want to keep - and we tell the OS to write that buffer over X, there is no situation short of serious disk failure where the half X that we want to keep is corrupted during the write.

Lucania

I would say that the worst thing would be that the head vibrates just enough from the crashing tree to skid head-first into the fragile ceramic platter, causing it to shatter into a million pieces. It's happened before. – Forcer

Yes, that would be pretty bad. That's presumably why you have backups, mirroring, and maybe even replication. But it's not something software, like a database, can save you from. – Lucania

"Can you ever end up with a situation where the data on disk is part X, part Y, and part garbage?" -- At the sector level of an HDD, the answer is no. The ECC protects the integrity of each sector. The recalculated ECC has to be written with the new sector data, so if the sector write fails to complete, then the probability of the garbage sector data matching the existing/old ECC should be so small to not worry. – Silverplate

Answer 1

The traditional (SCSI, ATA) disk protocol specifications don't guarantee that any/every sector write is atomic in the event of sudden power loss (but see below for discussion of the NVMe spec). However, it seems tacitly agreed that non-ancient "real" disks quietly try their best to offer this behaviour (e.g. Linux kernel developer Christoph Hellwig mentions this off-hand in the 2017 presentation "Failure-Atomic file updates for Linux").

When it comes to synthetic disks (e.g. network attached block devices, certain types of RAID etc.) things are less clear and they may or may not offer sector atomicity guarantees while legally behaving per their given spec. Imagine a RAID 1 array (without a journal) comprised of a disk that offers 512 byte sized sectors but where the other disk offered a 4KiB sized sector thus forcing the RAID to expose a sector size of 4KiB. As a thought experiment, you can construct a scenario where each individual disk offers sector atomicity (relative to its own sector size) but where the RAID device does not in the face of power loss. This is because it would depend on whether the 512 byte sector disk was the one being read by the RAID and how many of the 8 512-byte sectors compromising the 4KiB RAID sector it had written before the power failed.

Sometimes specifications offer atomicity guarantees but only on certain write commands. The SCSI disk spec is an example of this and the optional WRITE ATOMIC(16) command can even give a guarantee beyond a sector but being optional it's rarely implemented (and thus rarely used). The more commonly implemented COMPARE AND WRITE is also atomic (potentially across multiple sectors too) but again it's optional for a SCSI device and comes with different semantics to a plain write...

Curiously, the NVMe spec was written in such a way to guarantee sector atomicity thanks to Linux kernel developer Matthew Wilcox. Devices that are compliant with that spec have to offer a guarantee of sector write atomicity and may choose to offer contiguous multi-sector atomicity up to a specified limit (see the AWUPF field). However, it's unclear how you can discover and use any multi-sector guarantee if you aren't currently in a position to send raw NVMe commands...

Andy Rudoff is an engineer who talks about investigations he has done on the topic of write atomicity. His presentation "Protecting SW From Itself: Powerfail Atomicity for Block Writes" (slides) has a section of video where he talks about how power failure impacts in-flight writes on traditional storage. He describes how he contacted hard drive manufacturers about the statement "a disk's rotational energy is used to ensure that writes are completed in the face of power loss" but the replies were non-committal as to whether that manufacturer actually performed such an action. Further, no manufacturer would say that torn writes never happen and while he was at Sun, ZFS added checksums to blocks which led to them uncovering cases of torn writes during testing. It's not all bleak though - Andy talks about how sector tearing is rare and if a write is interrupted then you usually get only the old sector, or only the new sector, or an error (so at least corruption is not silent). Andy also has an older slide deck Write Atomicity and NVM Drive Design which collects popular claims and cautions that a lot of software (including various popular filesystems on multiple OSes) are actually unknowingly dependent on sector writes being atomic...

(The following takes a Linux centric view but many of the concepts apply to general-purpose OSes that are not being deployed in a tightly controlled hardware environments)

Going back to 2013, BtrFS lead developer Chris Mason talked about how (the now defunct) Fusion-io had created a storage product that implemented atomic operation (Chris was working for Fusion-io at the time). Fusion-io also created a proprietary filesystem "DirectFS" (written by Chris) to expose this feature. The MariaDB developers implemented a mode that could take advantage of this behaviour by no longer doing double buffering resulting in "43% more transactions per second and half the wear on the storage device". Chris proposed a patch so generic filesystems (such as BtrFS) could advertise that they provided atomicity guarantees via a new flag O_ATOMIC but block layer changes would also be needed. Said block layer changes were also proposed by Chris in a later patch series that added a function blk_queue_set_atomic_write(). However, neither of the patch series ever entered the mainline Linux kernel and there is no O_ATOMIC flag in the (current 2020) mainline 5.7 Linux kernel.

Before we go further, it's worth noting that even if a lower level doesn't offer an atomicity guarantee, a higher level can still provide atomicity (albeit with performance overhead) to its users so long as it knows when a write has reached stable storage. If fsync() can tell you when writes are on stable storage (technically not guaranteed by POSIX but the case on modern Linux) then because POSIX rename is atomic you can use the create new file/fsync/rename dance to do atomic file updates thus allowing applications to do double buffering/Write Ahead Logging themselves. Another example lower down in the stack are Copy On Write filesystems like BtrFS and ZFS. These filesystems give userspace programs a guarantee of "all the old data" or "all the new data" after a crash at sizes greater than a sector because of their semantics even though a disk many not offer atomic writes. You can push this idea all the way down into the disk itself where NAND based SSDs don't overwrite the area currently used by an existing LBA and instead write the data to a new region and keep a mapping of where the LBA's data is now.

Resuming our abridged timeline, in 2015 HP researchers wrote a paper Failure-Atomic Updates of Application Data in a Linux File System (PDF) (media) about introducing a new feature into the Linux port of AdvFS (AdvFS was originally part of DEC's Tru64):

If a file is opened with a new O_ATOMIC flag, the state of its application data will always reflect the most recent successful msync, fsync, or fdatasync. AdvFS furthermore includes a new syncv operation that combines updates to multiple files into a failure-atomic bundle [...]

In 2017, Christoph Hellwig wrote experimental patches to XFS to provide O_ATOMIC. In the "Failure-Atomic file updates for Linux" talk (slides) he explains how he drew inspiration from the 2015 paper (but without the multi-file support) and the patchset extends the XFS reflink work that already existed. However, despite an initial mailing list post, at the time of writing (mid 2020) this patchset is not in the mainline kernel.

During the database track of the 2019 Linux Plumbers Conference, MySQL developer Dimitri Kravtchuk asked if there were plans to support O_ATOMIC (link goes to start of filmed discussion). Those assembled mention the XFS work above, that Intel claim they can do atomicity on Optane but Linux doesn't provide an interface to expose it, that Google claims to provide 16KiB atomicity on GCE storage¹. Another key point is that many database developers need something larger than 4KiB atomicity to avoid having to do double writes - PostgreSQL needs 8KiB, MySQL needs 16KiB and apparently the Oracle database needs 64KiB. Further, Dr Richard Hipp (author of the SQLite database) asked if there's a standard interface to request atomicity because today SQLite makes use of the F2FS filesystem's ability to do atomic updates via custom ioctl()s but the ioctl was tied to one filesystem. Chris replied that for the time being there's nothing standard and nothing provides the O_ATOMIC interface.

At the 2021 Linux Plumbers Conference Darrick Wong re-raised the topic of atomic writes (link goes to start of filmed discussion). He pointed out there are two different things that people mean when they say they want atomic writes:

1. Hardware provides some atomicity API and this capability is somehow exposed through the software stack
2. Make the filesystem do all the work to expose some sort of atomic write API irrespective of hardware

Darrick mentioned that Christoph had ideas for 1. in the past but Christoph has not come back to the topic and further there are unanswered questions (how you make userspace aware of limits, if the feature was exposed it would be restricted to direct I/O which may problematic for many programs). Instead Darrick suggested tackling 2. was to propose his FIEXCHANGE_RANGE ioctl which swaps the contents of two files (the swap is restartable if it fails part way through). This approach doesn't have the limits (e.g. smallish contiguous size, maximum number of scatter gather vectors, direct I/O only) that a hardware based solution would have and could theoretically be implementable in the VFS thus being filesystem agnostic...

At the 2023 Linux Storage, Filesystem, Memory-Management and BPF Summit there was discussion about exposing device atomicity in a way that could be used by an application. Prior to the talk an RFC patch series "block atomic writes" had been posted that:

• Allows querying of atomic write support
• Added a new fallocate2() call that could be used to ensure a file's backing was well aligned for subsequent atomic write operations
• Added an RWF_ATOMIC flag to pwritev2()
• Makes use of SCSI WRITE ATOMIC(16) / NVMe writes

Only direct I/O and XFS were supported by the patch series.

The benefit of the work is described as follows:

With this new interface, application blocks will never be torn or fractured. For a power fail, for each individual application block, all or none of the data to be written. A racing atomic write and read will mean that the read sees all the old data or all the new data, but never a mix of old and new.

TLDR; if you are in tight control of your whole stack from application all the way down the the physical disks (so you can control and qualify the whole lot) you can arrange to have what you need to make use of disk atomicity. If you're not in that situation or you're talking about the general case, you should not depend on sector writes being atomic.

When the OS sends the command to write a sector to disk is it atomic?

At the time of writing (mid-2020):

• When using a mainline 4.14+ Linux kernel
• If you are dealing with a real disk

a sector write sent by the kernel is likely atomic (assuming a sector is no bigger than 4KiB). In controlled cases (battery backed controller, NVMe disk which claims to support atomic writes, SCSI disk where the vendor has given you assurances etc.) a userspace program may be able to use O_DIRECT so long as O_DIRECT wasn't reverting to being buffered, the I/O didn't get split apart/merged at the block layer / you are sending device specific commands and are bypassing the block layer. However, in the general case neither the kernel nor a userspace program can safely assume sector write atomicity.

Can you ever end up with a situation where the data on disk is part X, part Y, and part garbage?

From a specification perspective if you are talking about a SCSI disk doing a regular SCSI WRITE(16) and a power failure happening in the middle of that write then the answer is yes: a sector could contain part X, part Y AND part garbage. A crash during an inflight write means the data read from the area that was being written to is indeterminate and the disk is free to choose what it returns as data from that region. This means all old data, all new data, some old and new, all zeros, all ones, random data etc. are all "legal" values to return for said sector. From an old draft of the SBC-3 spec:

4.9 Write failures

If one or more commands performing write operations are in the task set and are being processed when power is lost (e.g., resulting in a vendor-specific command timeout by the application client) or a medium error or hardware error occurs (e.g., because a removable medium was incorrectly unmounted), the data in the logical blocks being written by those commands is indeterminate. When accessed by a command performing a read or verify operation (e.g., after power on or after the removable medium is mounted), the device server may return old data, new data, or vendor-specific data in those logical blocks.

Before reading logical blocks which encountered such a failure, an application client should reissue any commands performing write operations that were outstanding.

---

¹ In 2018 Google announced it had tweaked its cloud SQL stack and that this allowed them to use 16k atomic writes MySQL's with innodb_doublewrite=0 via O_DIRECT... The underlying customisations Google performed were described as being in the virtualized storage, kernel, virtio and the ext4 filesystem layers. Further, a no longer available beta document titled Best practices for 16 KB persistent disk and MySQL (archived copy) described what end users had to do to safely make use of the feature. Changes included: using an appropriate Google provided VM, using specialized storage, changing block device parameters and carefully creating an ext4 filesystem with a specific layout. However, at some point in 2020 this document vanished from GCE's online guides suggesting such end user tuning is not supported.

Rossy

I think most people work at higher levels of abstraction, but If you are writing a filesystem or a database, then you may need to rely on having an atomic operation from the disk - and not support hardware that doesn't provide that guarantee. – Lucania

@Lucania As you stated, atomic sector writes can be an optimization but you need guarantees that not set-ups provide. A single sector write may be atomic but without additional work there's nothing stopping it being reordered relative to other "in-flight" writes if there's any sort of volatile buffering going on - in that scenario you still something to act as a barrier when the I/O has been accepted by the lower layer. FWIW SQLite depends on sector write linearity rather than sector write atomicity by default but this can be changed. – Rossy

I agree with that, but basically if you're writing a filesystem or a database that uses a raw block device you require primitives like atomic writes and barriers. If a disk doesn't provide one of those two things, or does it in an esoteric way, you basically can't support that hardware - it's fundamentally broken. It seems like atomic sector write is the nearly universal guarantee for atomicity. For barriers, there are special operations for ordering depending on which type of disks you're working with (SCSI, SATA, NVM, etc). – Lucania

@Lucania I nearly agree with you. I think what we're both saying is you need a way to know when a whole write has made it to non-volatile media. What primitives and assurances you have control how optimal you can be. For example if all I have is a way to know the disk's cache has been flushed I can emulate barriers (at a price). I can also take a log approach to emulate atomicity. I'd argue not broken but likely slow(er). Curiously Linux used to expose barriers in the block layer but it got rid of them due to complexity and bugs. – Rossy

"This means all old data, all new data, some old and new, all zeros, all ones, random data etc. are all "legal" values to return for said sector" -- The problem is not as ugly as it seems. The cited draft doc refers to a "device server", whatever that is. But at the drive level, an uncompleted sector write (esp on an HDD) should hopefully create a mismatch between any data written and the (non-updated) ECC. When the ECC is not properly updated at the completion of the sector write, then any subsequent read should be able to detect invalid sector data. That is how it is supposed to work. – Silverplate

Answer 2

I think torn pages are not the problem. As far as I know, all drives have enough power stored to finish writing the current sector when the power fails.

The problem is that everybody lies.

At least when it comes to the database knowing when a transaction has been committed to disk, everybody lies. The database issues an fsync, and the operating system only returns when all outstanding writes have been committed to disk, right? Maybe not. It's common, especially with RAID cards and/or SATA drives, for your program to be told everything has committed (that is, fsync returns) and yet there is data not yet on the drive.

You can try using Brad's diskchecker to find out if the platform you are going to use for your database can survive pulling the plug without losing data. The bottom line: If diskchecker fails, the platform is not safe for running a database. Databases with ACID rely upon knowing when a transaction has been committed to backing store and when it has not. This is true whether or not the databases uses write-ahead loggin (and if the database returns to the user without having done an fsync, then transactions can be lost in the event of a failure, so it should not claim that it provides ACID semantics).

There's a long thread on the Postgresql mailing list discussing durability. It starts out talking about SSDs, but then it gets into SATA drives, SCSI drives, and file systems. You may be surprised to learn how exposed your data can be to loss. It's a good thread for anyone with a database that needs durability, not just those running Postgresql.

Intramundane

You are correct, you have to deploy your database using storage devices that correctly report back to the OS when data is fsynced, otherwise the D in ACID is not possible. There are torn pages to deal with when page size (write size) is a multiple of the sector size, but as long as drives finish writing the current sector, and report fsync correctly to the OS, torn pages is probably the worst situation you can commonly encounter. – Lucania

One thing I would like to see in future hardware designs for both CPUs and disks is the ability to enforce an ordering without absolute fences. For example, have a computer be able to tell a drive "Write X sometime, and Y sometime; order them however you like relative to other things, but absolutely do not write Y before X". Likewise, have a CPU know enough about object references to guarantee that an object reference will not be updated until all pending writes to the object have completed--without forcing order relative to other stuff. Any idea if anyone's pursuing such notions? – Stop

Answer 3

Nobody seems to agree on this question. So I spent a lot of time trying different Google queries until I finally found an answer.

from Dr. Stephen Tweedie, RedHat employee and linux kernel filesystem and virtual memory developer in a talk on ext3 (which he developed) transcript here. If anyone knows, it'd be him.

"It's not sufficient just to write the thing to the journal, because there's got to be some mark in the journal which says: well, (has this journal record actually) does this journal record actually represent a complete consistency to the disk? And the way you do that is by having some atomic operation which marks that transaction as being complete on disk" [23m, 14s]

"Now, disks these days actually make these guarantees. If you start a write operation to a disk, then even if the power fails in the middle of that sector write, the disk has enough power available, and it can actually steal power from the rotational energy of the spindle; it has enough power to complete the write of the sector that's being written right now. In all cases, the disks make that guarantee." [23m, 41s]

Lucania

qnx.com/developers/docs/6.4.0/neutrino/sys_arch/… – Bander

That looks very old, since it only mentions ext2. A COW filesystem is merely a less efficient way to solve the same problem as a journaling filesystem - so even the idea presented is old. I'm still going to say Stephen Tweedie is likely the one who is correct here. – Lucania

I respectfully disagree with Dr. Tweedi. Split sectors can and do happen although drive manufacturers do try to prevent them. A split sector is half new, half old. This results in an ECC error on the sector and is eventually reported back to the host as a read error. Using Back EMF from the motor (Stealing rotational momentum) to power the drive is problematic as you slow the rotation as you power the electronics and because the rotation is slowing while you write the frequency of the data appears to changes from start to finish making it difficult for read circuitry to lock onto the signal. – Febrifacient

Small caps and specialized power loss detection circuits are often used by manufacturers to prevent split sectors, but not all drives are treated equally. However If a command is sent to the drive with FUA (Forced Unit Access) then the data is supposedly guaranteed to be written once you get the command complete back from the drive. Without FUA set it could remain in the write cache for some time. – Febrifacient

As part of https://mcmap.net/q/271041/-is-overwriting-a-small-file-atomic-on-ext4 Arek contacted Stephen in 2015 on the topic of atomic writes. – Rossy

Answer 4

No, they are not. Worse yet, disks may lie and say the data is written when it is in fact in the disk cache, under default settings. For performance reasons, this may be desirable (actual durability is up to an order of magnitude slower) but it means if you lose power and the disk cache is not physically written, your data is gone.

Real durability is both hard and slow unfortunately, since you need to make at least one full rotation per write, or 2+ with journalling/undo. This limits you to a couple hundred DB transactions per second, and requires disabling write caching at a fairly low level.

For practical purposes though, the difference is not that big of a deal in most cases.

See:

• How (not) to achieve durability.
• FSync() may not flush to disk

Bret

All of this goes straight out the window if you're on an SSD. Actual IOPS should be in the thousands, and real durability with flush-to-disk may be possible. – Bret

@ArekBulski Did you read the links? What precisely happens when you try to write a block, down to the level of the spinning rust? I guarantee if you look closely you'll find some nasty surprises. – Bret

Answer 5

People don't seem to agree on what happens during a sector write if the power fails. Maybe because it depends on the hardware being used, and even the filesystem.

From wikipedia (http://en.wikipedia.org/wiki/Journaling_file_system):

Some disk drives guarantee write atomicity during a power failure. Others, however, may stop writing midway through a sector after power is lost, leaving it mismatched against its error-correcting code. The sector is thus corrupt and its contents lost. A physical journal guards against such corruption because it holds a complete copy of the sector, which it can replay over the corruption upon next mount.

Seems to suggest that some hard drives will not finish writing the sector, but that a journaling filesystem can protect you from data loss the same way the xlog protects a database.

From the linux kernel mailing list in a discussion on ext3 journaling filesystem:

In any case bad sector checksum is hardware bug. Sector write is supposed to be atomic, it either happens or not.

I'd tend to believe that over the wiki comment. Actually, the very existence of a database (firebird) with no xlog implies that sector write is atomic, that it cannot clobber data you did not mean to change.

There's quite a bit of discussion Here about atomicity of sector writes, and again no agreement. But the people who are disagreeing seem to be talking about multiple-sector writes (which are not atomic on many modern hard-drives.) Those who are saying sector writes are atomic do seem to know more about what they're talking about.

Lucania

Answer 6

The answer to your first question depends on the hardware involved. At least with some older hardware, the answer was yes -- a power failure could result it garbage being written to the disk. Most current disks, however, have a bit of a "UPS" built into the disk itself -- a capacitor that's large enough to power the disk long enough to write the data in the on-disk cache out to the disk platter. They also have circuitry to detect whether the power supply is still good, so when the power gets flaky, they write the data in the cache to the platter, and ignore garbage they might receive.

As far as a "torn page" goes, a typical disk only accepts commands to write an entire sector at a time, so what you'll get will normally be an integral number of sectors written correctly, and others remaining unchanged. If, however, you're using a logical page size that's larger than a single sector, you can certainly end up with a page that's partially written.

That, however, mostly applies to a direct connection to a normal moving-platter type hard drive. With almost anything else, the rules can and often will be different. Just for an obvious example, if you're writing over the network, you're mostly at the mercy of the network protocol in use. If you transmit data over TCP, data that doesn't match up with the CRC will be rejected, but the same data transmitted over UDP, with the same corruption, might be accepted.

Erect

@Jerry: IMHO the question is concerned with the case the disk got the command to write a single sector but has no sufficient power to complete. I am pretty sure not all modern disks can always finish writing a sector. – Chiropodist

@EFraim: that was the case I had in mind, if the modern disk cannot finish writing the current sector, it must leave it as a mixture of OLD and NEW data only, if any garbage data makes it into that sector, it would need to be restored from a duplicate copy somewhere else. – Lucania

You can get battery (or capacitor) backed disks or raid controllers that will write out the cache in the event of system failure - which normally should mean that fsync only has to wait for data to hit the write cache (very fast.) Running on hardware like that, torn pages are still possible, but a sector should behave atomically, either written or not. I had in mind cheaper disks than that - but not so cheap that they lie to the OS about fsync, as you cannot safely run an ACID db on that hardware. – Lucania

Answer 7

I suspect this assumption is wrong.

Modern HDDs encode the data in sectors - and additionally protect it with ECC. Therefore you can end-up with garbaging all the sector content - it will just not make sense with the encoding used.

As for increasingly poplular SSDs, the situation is even more gruesome - the block is cleared prior to being overwritten, so, depending on the firmware being used and the amount of free space, entirely unrelated sectors can be damaged.

By the way, an OS crash will not lead to data being damaged within single sector.

Chiropodist

I suspect that the OP is referring more to databases (and their data integrity mechanisms) than the actual disk itself. Databases contain mechanisms such as transactions, serialization and journaling to prevent what you are describing from damaging the data. – Hadik

Good point. Also, I think the partition table will remove a "pointer" to data X before it tries to write data Y. I am not sure, but just throwing that out there. – Marshamarshal

@Jay: What you are referring is called "soft updates" and is actually increadibly difficult to get right. (and not many file systems do it; IMFO the FreeBSD one does) In fact even journaled FS like ext3 can get garbled data into a file in case of a crash. – Chiropodist

@Robert: IMHO the OP is interested just HOW the journal ensures data integrity. – Chiropodist

I think the respresentation of the data on disk is irrelevant. What matters is the operating system's data integrity guarantees for the system calls you are using. This varies from operating system to operating system, and even between multiple file systems on the same operating system, or even depending on the configuration of a particular file system (e.g. the ext3 data={data,ordered,writeback} option). – Mutate

@EFraim, could you elaborate on your last statement please? "By the way, an OS crash will not lead to data being damaged within single sector." And yes I am more interested with how software achieves the D in ACID. – Lucania

@Eloff: the fact is that once the OS had given the "write sector" command to the disk, even if it were to crash the next milisecond, the disk controller will put it to the platter nonetheless. – Chiropodist

@EFraim: that answers my question then. Sector writes are atomic, they either succeed entirely, or don't happen at all. Which makes torn pages the worst you can reasonably expect in an OS crash. – Lucania

@EFraim: So you're saying sector writes are atomic even in the face of an OS crash (which as I understand it includes power failure and system component failures.) If that is indeed correct, please make that clear in your answer and I will accept it as the answer to my question. Your answer confused me because it seems to say both that you can get garbaged sectors, and that you cannot get damage within a single sector (assuming perfectly working hard disk.) – Lucania

He's right that sectors are protected by ECC, he's wrong about reading garbage back - the HDD's microcontroller will detect the ECC mismatch and report the sector as unreadable. You won't get any data back from that sector at all, garbage or otherwise. His description of SSDs is also overstated - block overwrites only happen when they're full. Partially filled blocks are written incrementally, 512 bytes at a time. – Sliver

@hyc: That's not the point - you don't know exactly how the wear leveling algorithm spreads the sectors among the erase sectors - so you don't know when exactly the erase sector will become full. This can happen when you are writing to what seems to the OS to be an entirely unrelated disk area. – Chiropodist

Answer 8

I would expect one torn page to consist of part X, part Y, and part unreadable sector. If a head is in the middle of writing a sector when the power fails, the drive should park the heads immediately, so that the rest of the drive (aside from that one sector) will remain undamaged.

In some cases I would expect several torn pages consisting of part X and part Y, but only one torn page would include an unreadable sector. The reason for several torn pages is that the drive can buffer lots of writes internally, and the order of writing might interleave various sectors from various pages.

I've read conflicting stories about whether a new write to the unreadable sector will make it readable again. Even if the answer is yes, that will be new data Z, neither X nor Y.

Shagreen

Answer 9

when updating the disk, the only guarantee drive manufactures make is that a single 512- byte write is atomic (i.e., it will either complete in its entirety or it won’t complete at all); thus, if an untimely power loss occurs, only a portion of a larger write may complete (sometimes called a torn write).

Edp