Linux vies with Oracle (vnunet)

[Posted September 3, 2004 by ris]

Here's a Vnunet article about a company that replaced an Oracle database cluster with a few Linux servers. "The great thing about this story is that the Linux servers did not run database software. The Oracle database had been converted and stored on the Linux hard disk as a collection of some 100,000 files. The work was part of a major application upgrade that involved redesigning all the components of a busy web site."

(Log in to post comments)

Posted Sep 3, 2004 19:14 UTC (Fri) by leandro (guest, #1460) [Link]

This must have been the dumbest, most clueless article of the year.

And it illustrates well what I have against how ReiserFS is being sold.

First, Oracle is not relational. SQL isnt relational, and has never been. It came close with ISO SQL:1992, but then ISO SQL:1999 lost it by implementing pointers, and has even had relational terminology deleted.

Then, by going ReiserFS and XML, one may save bucks and system resources, but this could have been much better done with PostgreSQL. It is just as cheap, and much more capable than ReiserFS and XML in any combination. And it gives things ReiserFS and XML cant do, like declarative programming, integrity constraints (business rules) checking and transactional integrity, and ad hoc reports and operations.

It is prostituted.

Dumb decisions in the long term

Posted Sep 3, 2004 19:15 UTC (Fri) by leandro (guest, #1460) [Link]

This must have been the dumbest, most clueless article of the year.

And it illustrates well what I have against how ReiserFS is being sold.

IT is prostituted.

Amen

Posted Sep 3, 2004 21:40 UTC (Fri) by ccyoung (guest, #16340) [Link]

(and you can say that again)

Yes, well said

Posted Sep 4, 2004 1:30 UTC (Sat) by man_ls (guest, #15091) [Link]

Still, it is hard to know if they did the right thing, given the shoddiness of the article. It seems to be written for managers -- the author just throws around some buzzwords ("open source" and "xml" being the most prominent) and lights up the imagination of a boss type.

I like this quote:

My vote would be for something like Coda - a research implementation of a fault-tolerant, distributed file system for long-latency IP networks.

The BOFH himself might have said it to his boss, with the inevitable result:
> DUMMY MODE ON <

Yes, well said

Posted Sep 4, 2004 13:38 UTC (Sat) by nix (subscriber, #2304) [Link]

Given Coda's (lack of) scalability, he was really advertising his ignorance of it.

Journaling vs. power failure

Posted Sep 3, 2004 19:16 UTC (Fri) by ncm (subscriber, #165) [Link]

The article repeats the common myth that a journaled file system is proof against corruption in the event of a power failure. Like many myths, it is almost always a simple falsehood. Like most myths, a germ of truth keeps the story propagating.

The germ of truth is twofold. First, journaled file systems present a smaller target for corruption. In other words, if some random block that's being written when the power drops gets written wrong or incompletely, it's less likely to corrupt the whole file system. Therefore, if you're worried about power failures, you are probably better off with a journaled file system, completely aside from the time you save not running fsck when it happens. (I.e. you're about equally likely to have undetected corruption as you have after a successful fsck, but the fsck might fail, too.)

The second is more subtle. It's possible to design a journaled file system so that it will be robust against power outages, but it's far from universal practice. It requires that journal blocks be written with a strong hash (e.g. CRC-64 or MD5). Then the recovery code can determine reliably the last valid journal entry. However, for that to be useful, you need a further guarantee, that when the drive says a block is written, it is really physically on the disk surface.

Most ATA drives (i.e. almost all drives) lie about this, and claim to have written blocks that are only saved in the drive's RAM buffer. SCSI drives are frequently better about this, but are found increasingly rarely these days. (Vendors have found they can get away with socking SCSI customers twice as much for the same physical object. "Market segregation", they call it.)

Therefore, if your journaled filesystem was designed to be robust against power failure, and if your disk drives are the very expensive sort that don't lie, then you can breathe easy about power outages. Everybody else needs battery backup before they can promise safe recovery.

What all journaled filesystems do give you is confidence in the event of a system crash or somebody poking the "reset" button. In that case, the drive gets a chance to flush its buffer to disk. (Technically, whatever caused the system crash might also corrupt the file system, but that doesn't seem to happen much.) What this means in practice is that your battery-backup system should reset your machine before its batteries finally give out. Ideally, though, it should just trigger a proper shutdown, and in that case the journal didn't help you.

The end result is that the right thing to do, usually, is use a battery backup and controlled shutdown (and replication, too) if you want reliability in the face of power failure, and depend on a journaled filesystem for its other merits (e.g. speed). However, for a self-contained gadget (e.g. Tivo) where you can be certain about the disk drive behavior, where cost matters, and where the power frequently goes away unexpectedly, a journaled file system that was designed to protect against corrupted blocks might be exactly what you need.

Journaling vs. power failure

Posted Sep 3, 2004 19:22 UTC (Fri) by Ross (guest, #4065) [Link]

Which is not to mention that most people using a journaled filesystem aren't
even journaling the data blocks, so they are just protecting the internal
data structures of the filesystem, not the contents of the files.

Plus, many drives have a second fault which is that they sometimes write
garbage (not just incomplete or missing blocks) on the disk of they are
shut down during a write. Some even write this garbage past the number of
blocks the OS thought it was writing out. Designing a safe filesystem for
that type of device is non-trivial to say the least.

Journaling vs. power failure

Posted Sep 4, 2004 19:54 UTC (Sat) by ncm (subscriber, #165) [Link]

I asked on the kernel list about journaling only the file system structures, and not the data. Their take was that any data that matters should have been fsync'd out, and is on the disk if the system said it is (assuming the drive didn't lie). Anything else is a race; depending on when the crash happened, you would have no reason to think it got there, or that it didn't, so you'd better be prepared for either result. The main problem with this shows up in (e.g.) make judging file currency by the modification time; the compiler might not have finished writing the file, and make didn't get a chance to delete it (as it does, e.g. when you kill it), so after a crash you have to "make clean" in any directories that were being written when it happened.

I hadn't heard about drives that scribble outside the lines during a power drop, but it's not too surprising. Digital chips can do all kinds of strange things when supply voltage is "out of spec" (as it is just before it goes away completely), not limited to impregnating one's sister. If the manufacturers cared (and were obliged to care by discerning buyers -- ha!) they could arrange have the power to the head cut off before the controller has a chance to go crazy. That would probably raise the cost of manufacture by $0.25, though, so it's generally out of the question for PC-grade products.

Journaling vs. power failure

Posted Sep 11, 2004 17:59 UTC (Sat) by pimlott (guest, #1535) [Link]

The main problem with this shows up in (e.g.) make judging file currency by the modification time; the compiler might not have finished writing the file, and make didn't get a chance to delete it (as it does, e.g. when you kill it), so after a crash you have to "make clean" in any directories that were being written when it happened.

ext3's default ordered mode is supposed to prevent this: Data blocks are not journaled, but they are written out before the metadata blocks are committed. So the file could contain garbage, but if so, the mtime should not have been updated.

Journaling vs. power failure

Posted Sep 4, 2004 7:33 UTC (Sat) by AJWM (guest, #15888) [Link]

Wandering a bit offtopic here, but it relates to the comments about hard drives and power failures, and to a feature I've not seen a Unix (or Linux) box in a long time.

Back in the mid 80s I was doing evaluations of various Unix boxes, and remember one -- I think it was from NCR, but I wouldn't swear to it -- that would not only save itself when the power was interrupted, it would resume previously running processes when powered back up. It had enough backup power (or nonvolatile RAM?) to snapshot its state when it detected a power drop.

I tested it with a program that produced sequential output, and yanked the power plug. Plugged it back in about ten minutes later and the box did a fast boot, recovered the processes, and the program continued the output sequence where it left off.

Clearly this is trickier in a networked environment, since some of the state of a running networked process will be elsewhere on the net. But it was damn impressive, and a feature I've wanted in desktop machines more than once. (Although a UPS certainly helps.) Anyone familiar with this machine and how they implemented it?

Journaling vs. power failure

Posted Sep 4, 2004 16:37 UTC (Sat) by piman (subscriber, #8957) [Link]

The software end would be basically the same as software suspend in Linux; and if the architecture is saner than modern x86, probably a lot less buggy.

Journaling vs. power failure

Posted Sep 4, 2004 17:11 UTC (Sat) by ballombe (subscriber, #9523) [Link]

My previous and current laptops had that feature, when battery was low
they triggered (BIOS) suspend-to-disk via apm.
It is a shame the switch to ACPI removed that feature from modern BIOS.

Linux vies with Oracle (vnunet)

Posted Sep 4, 2004 6:39 UTC (Sat) by hannes.g (guest, #24506) [Link]

If they could replace the database with just a filesystem and a little XML (as the article says), they never had a real need for a database and should'nt have wasted money on the license in the first place.

If you look at a database as a mere storage for data, you're clueless.

There's a little more to it: transactions, recoverability, concurrency. What about backups? Just save the files and hope it's consistent? How do you deal with logical corruptions (that cannot be maintained by the file system - it doesn't know anything about it)... and so on

And out there are a lot of management types who are now going to believe they can replace that expansive database with a filesystem ...

Linux vies with Oracle (vnunet)

Posted Sep 4, 2004 7:53 UTC (Sat) by dmantione (guest, #4640) [Link]

There is a lot to say for a simple filesystem layout. Now I'm sure I'm going to
sound like a ReiserFS advocate, as the reason is namespaces.

Data in a database is only accessible with a database interface. Now that
works well in most web languages, and perhaps some other tools as well. As
soon as you discover that you need your data in a shell script you start to
notice the disadvantage.

In an example in practice, I maintain a server which contains 170000
documents. Those documents need metadata. This is stored into a database
and it was Oracle, which is much less supported than open-source databasde.
This has proven to be a very bad choice since it forced to write me
specialized C programs using the complex OCI interface to get data out of it,
where all I did want was access the metadata from a shell script.

Some people tell me I should have done the opposite, put the documents into
the database, but that would have made things worse, normal programs cannot
access the documents anymore.

What looks like would have been the best solution was to put the metadata into
the filesystem. In separate files, since extended attributes still needyears until
they can be relied upon.

To summarize, I can imagine very well that a filesystem approach has
advantages compared to a database. Sure, some complex querys need some
complex code, but in reality, most querys are very simple.