4

In my understanding, even if i want to overwrite a byte in middle of a file, OS and/or disk will read the content of the size of page, modify one byte and then write the contents back.

What is the fundamental reason that disks are designed this way to have read-modify-write cycle ?

Is hardware or physical properties of disk the reason ?

Is optimizing for data-locality for next reads is the reason ?

This question is more about granularity of each disk operation than inserting in middle of file.

Ashish Negi
  • 251
  • 2
  • 8
  • 1
    Possible duplicate of [Why can we not insert into files without the additional writes? (I neither mean append, nor over-write)](https://softwareengineering.stackexchange.com/questions/237416/why-can-we-not-insert-into-files-without-the-additional-writes-i-neither-mean) – Kilian Foth Sep 07 '18 at 07:04
  • 2
    It's worth noting that disks don't usually work at a hardware level in page size chunks -- they use sector size, which is usually either 512 bytes or 2KiB. Pages are usually larger: typically 4KiB or more. Your *operating system* may decide to operate on the disk in page size chunks, because doing so allows it to unify disk access with its virtual memory system, but this isn't strictly necessary. – Jules Sep 07 '18 at 17:33

4 Answers4

6

That's due to the mechanics.

A disk is a surface which rotates around its axis at a high speed (in reality several surfaces). The surface is divided into concentric tracks, and a motor controls the electromagnetic head to move to the right track. The head then just waits until the information it wants to read/write passes under it. So the problem is then to locate the bytes on the track in order to know when they will reach the head.

If there would be byte addressing, the head would read/write a single byte, but due to the speed of the rotation, would have to wait a full rotation to execute the next read/write instruction. An alternative could be to cache the access instructions to optimize the access to continuous bytes in order to avoid waiting for unnecessary rotations. But this would have required more memory and more throughput for the disk controller, which were both very limited in earlier times.

So instead of accessing single bytes, and considering that most accesses are for a whole sequence of bytes, the tracks were divided into sectors of same capacity. This is why you have this block logic.

user1118321
  • 4,969
  • 1
  • 17
  • 25
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 7
    It would also require the disk to be able to precisely locate a single byte, which it can't do: it finds sectors because there's a gap between each one and a marker is stored to identify them. If it wanted to be able to find individual bytes, it'd have to have a gap between each byte, which would mean you'd get about 1/20th as much actual data on the disk, because most of it would be used for sector headers and gaps. – Jules Sep 07 '18 at 17:42
3

Your mechanical hard drive reads and writes data at 100 MB per second, using a strong magnet. To change a single byte, you’d have to turn that magnet on for ten nanoseconds. In order to not destroy any bits of the previous bytes, you’d have to turn that super strong magnet on and off within half a nanosecond.

You’d also have to recognize the location where you write with sub-nanosecond precision before you arrive there. So you have zero processing time available. Just impossible.

And since a hard drive rotates 90 times a second, if you write bytes one after the other, you have the enormous write rate of 90 bytes per second.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
gnasher729
  • 42,090
  • 4
  • 59
  • 119
  • 1
    Hard drives have to do all that regardless how many bytes are being written in a logical operation. The choice do do pages is an engineering trade-off to meet practical considerations. Sub-nanosecond is still plenty of time for the specialized ASICs driving the disk heads to do their jobs. – whatsisname Sep 07 '18 at 16:07
  • 1
    There is an error-correcting code that used to have 512 byte block size but now has 4096 byte block size. It's impossible to write just one byte and expect the error-correcting code to be valid after the modification. Really, the smallest unit you can write is the error-correcting code block size. – juhist Sep 07 '18 at 16:58
  • @whatsisname - they don't do that, though. Not with the required degree of accuracy. They store data in a way that allows it to be read even if it is a slightly different speed to what's expected. But changing a single byte in the middle would require a precise match in order to not corrupt that encoding. There are spaces between sectors so that if the write process is slightly slow it doesn't overwrite the next sector. There isn't enough space to do that on an individual byte level. – Jules Sep 07 '18 at 17:54
  • 1
    @Jules: don't confuse "impossible" with "impractical" – whatsisname Sep 07 '18 at 18:22
  • 1
    @whatsisname They don't write with that precision. There's a bit of extra space around the sector to allow for slight variations in where it's written on different writes. – Loren Pechtel Sep 09 '18 at 13:05
2

All memory devices at every level of the memory hierarchy (from L1 cache, main memory, disk...) offer sequential access as a faster mode compared to random access.  Random access requires constant transmission of addresses (which means devices have to reconfigure their access for changing addresses) whereas sequential access means bulk transfers: amortizing one address across transfer of whole block, while the devices are internally advancing addressing to the next, in parallel with access of the prior address.

Disk takes that to extreme as @gnasher729 is pointing out.  Due to the physical media, byte addressing is not even practical.  On disk, there is fixed-sized overhead surrounding any amount of content you might store.  During low-level formatting by the manufacturer, a choice is made of the size of content that is made into a block.  The choice is a trade off between advantages of sequential bulk transfers when you want more data, and the disadvantages when you don't, as well as amortizing overhead over content.

In practice, if the operating system is working with a given file, then it will only do read-modify-write when the page is cold, whereas thereafter for a time it will cache the latest content of that page.  If the page is found in the cache, then the initial read can be forgone.

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91
0

I agree with previous answers in many points. Except about hdd structure - this doesn't cover other device types. But they also use bulk operations as @Erik Eidt already said. Completely agree with inherent sequential access of any memory device. But need to mention another aspect of input / output process: on most architectures it is optimised to be executed asynchronously. This usually means that some memory device control copying of data between different addressed points. For x64 it is done by MMU for example. As such the granularity of IO operations depends on these devices and is usually is block sized or even page sized. You can look at some scattering / gathering principles of their work.

Anton Astafiev
  • 64
  • 6