Hacker News Reader

Comment by slashdotaccount | Hacker News Reader

And what if it's not your PhD thesis in Libre Office but a busy database server which can easily get corrupted if you don't flush.

> I don't think I've had a freeze that was the kernel and not just X.

Device drivers sometimes have bugs, especially when the device is not working properly (I had system freezes when there was a misbehaving capacitor on the graphics card).

View on HN

> And what if it's not your PhD thesis in Libre Office but a busy database server which can easily get corrupted if you don't flush.

No properly configured and working ACID compliant RDBMS should lose any data when the server is reset or stopped. If it does, then it is either a problem with the hardware, OS, configuration or the RDBMS itself. The application must also be able to handle the DB disappearing, though. Sadly this is often not the case.

You mean lose data after it's been committed. I can send something to the database just as it's dying and it's been lost.

SQL commit is not allowed to finish before the data is safely on disk (that's the D in ACID).

That's assuming that the RDBMS can tell. The disks may lie:|

You should strive not to use such disks in your server. A machine reset won't power off the disks, though.

Or the CPU or the memory or the OS...

Thus the 's' in reisub?

The disk may lie. The 's' will get the OS to send everything out to the disk. Actually writing it to the platter (or flash part, or whatever) is at the disk's discretion.

It's at the disk's discretion as far as the laws of physics are concerned, but this would a severely broken disk prone to losing data and if it was a major server disk vendor, the vendor would take a pretty serious hit to its reputation.

Yes, but my point was that I could send data to an ACID compliant server, and kill it before the commit happened and data will be lost. Just trying to point out to the parent poster that sending is not enough, you need to wait for the commiting.

> And what if it's not your PhD thesis in Libre Office but a busy database server which can easily get corrupted if you don't flush.

Wouldn't that make it an unsafe database server?

Yes, I agree, but just several weeks ago I had to recover a MySQL InnoDB database after a power problem. MySQL is very popular, and it turns out it is an unsafe database server according to your definition. Well maybe it is.

Edit:

Besides, hard drives have write caches, and they can report a successful write operation to the OS when the data is still in its cache physically.

Yep, MySQL is an unsafe database. The fact that it's popular just goes to show how powerful marketing is on th emind of most people.

Hard drivers are supposed to flush their caches before they report the end of a flush operation to the OS (some flush into flash, but they flush). If your does not, it's defective. Go ahead and make use of the warranty.

I don't believe MySQL is ACID compliant. You may have just ran into one of the reasons how.

MySQL is only ACID compliant under a very specific set of configuration parameters. This makes it even more dangerous than an RDBMS with binary acidity.

Re HD lying, this is rare except with dubious cheap flash sticks. The caching command set is well defined and operating systems know how to issue the relevant SCSI/SATA commands. It's critical for correct functioning of journaling filesystems such as NTFS and Ext4.

Reply on news.ycombinator.com