... it's made for hard cycling.
It's not the hardware you should be concerned about, it's the state of a filesystem. 8-o
If you just remove the power supply, your filesystem is in an undefined state. It might be that it's ok, it might be that there is a small error one can recover from, it might be that everything is just *poof* gone! :?:
Why is that?
Say your program wants to write 8kB data on disk. The operating system writes the data into a buffer (my filesystem cache is set to 2048kB), reports to the program that the data is written on disk, and marks the buffer as dirty. To clean the buffer, the operating system moves the data from the buffer to the harddisk (here, take that block of data and write it to address this-and-that). Depending on the harddisk, it takes blocks of data and either writes it directly to disk or stores them in a buffer. In either case, it reports back that the data is written to disk!
So, first your operating system lies, then the disk. In both cases the data is still in a buffer. You can imagine what happens if the data is in a buffer and you remove the power supply. I*poof* t's gone.
But that's not the worst of it. 8-o
The harddisk is totally agnostic to the importance of the data. You know that data is organised on disk by a filesystem. The filesystem for most of our old macs is called HFS, (NT3.5 and greater prefers NTFS, Linux knows several dozens, and uses EXT4 in my case). If you write a blob of data into the filesystem, at least two blocks get changed, the block where no data is and your blob will end up and the block that contains the table of contents, which is a table that says file ''Homework'' is on block 3425 to 3429 (simplified).
Both, the blocks with the data nd the blocks with the table of contents, look to the harddisk like just blocks. Both might end up in a buffer before they are written on disk. Imagine the data is already written to disk and the table of contents isn't yet. How can you ever find your data again? Imagine your table of contents is large and uses more than one block and one block is on disk, the others are not? You would end up with an invalid table of contents.
Modern filesystems use backups of the table of contents, in case the original is inconsistent. Even more modern filesystems use a journal, that is, they lock the table of contents, write the data, write to the table of contents and unlock if all is done. If something happens, the old state of the table of contents is still there and every write or delete action since then is automatically voided. All these steps are still perverted by harddisk buffers, which are grown today to several megabytes (32 in my case).
Even if your instruct your filesystem explicitly not to use the buffers by mounting it with the option sync in my example, some harddisks still use buffers. They just lie and say they don't! That is a major concern for people that do more than just playing Doom *cough-cough*. That is also the reason why we don't measure disk performance in "computer-to-disk", but "disk-to-buffer" and "buffer-to-computer" today.
Luckily, in the olden days, when we used to write computer with a capital K, the buffers where small and filesystem transactions where mostly synchronous, instead of mostly asynchronous as they are today. But you can not be sure. Ever! Even marking your filesystem as "readonly" might be ignored by some systems. For example, the time of last mount might be written into the filesystem.
And that is why you shut down your operating system properly, telling it to flush all buffers, which then tells the harddisk to flush all buffers. :approve:
I hope my writing makes sense to you and you can look past my crude application of the english language. |)
.
