A Semi-Radical Approach To Avoiding fsck

Dru writes: "This is an article about a hardware technology that is largely unknown in the new Unix community. In theory, with this inexpensive hardware, your BSD or Linux box could start doing guranteed reboots in under 2 minutes (no fsck required) and super fast database writes. It could leapfrog all of the journaling filesystem projects as well. Yes, I wrote the article. The article is long, detailed, and mentions FreeBSD often. However, I do believe it is relevant to any other PC Unix. If enough people learn about it, maybe they will start demanding it from their favorite hardware vendor." With RAM and hard drive space both continuing to decline, I wonder how the speed / use curve for individual PCs' storage (from L1 cache to backups) will evolve. With a similar bent, Arek urges you to "take a look at our company's Solid State Disk Drives." How'dja like 8 or so gigs of DRAM next time you edit a video or burn a CD?

Comments

Too much work

[ericfitz]

A write-caching disk controller combined with a journaling file system would give you the same benefit. You're just reinventing the wheel..

The only really new thing here seems to be the fact that the "TRAM" is file-system aware, which is just another way of saying that you are investing in hardware which will just tie you to tired old EFS.

Windows NT has had a journaled file system forever, and the journaling doesn't cause the major performance impact that everyone seems to think it does. Maybe someday Linus will get in the mood and allow a journaling FS into Linux.

On a side note, what does the OS do in case of some sort of TRAM failure?

RAM == volatile

[pjrc]

RAM is volatile.

Sure, a battery backup sounds like it solves this, but consider that DRAM stores its charge on tiny capacitors, and requires a controller to be performing "refresh" access cycles regularily (usually every 15.26 s). This means that not only must the battery be good, but the controller accessing the DRAM must continue providing the refresh cycles without interruption. That may sound simple, but not all DRAMs are created alike.... SDRAM DIMMs have a feature called Serial Presence Detect (SPD) that is a small non-volatile 2-wire serial EEPROM memory that hold identifying data about the size and timing parameters for the memory. A typical DRAM controller would be initialized at boot time... a card like this would require a special DRAM controller that only initialized its timings when the DRAM/battery is first installed. Perhaps the controller would be designed to use relatively slow and conservative timings, always, so it'd never be able to reinitialize to other settings (that could be wrong) and/or stop providing the critical refresh at any point.

The point is that to retain memory, DRAM requires not only power but a properly operating controller to supply the refresh cycles. Magnetic media maintains its memory without either of these conditions. Compared to magnetic media, DRAM is very volatile. "Mission Critical" data, whatever that may be, would be existing at tiny charges on the very tiny capacitors, which could dissipate in only about 4-8 ms, if the DRAM controller doesn't perform perfectly.... inside a computer (designed as a reliable server) which has just crashed for some unknown reason!

Re:RAM == volatile

[dbarclay10]

You raise an implementation issue.

The point is that to retain memory, DRAM requires not only power but a properly operating controller to supply the refresh cycles.

Laptops run off batteries, and their memory seems okay.

My Pilot runs okay off AAA-type batteries. Memory has been running quite well, thank you :)

This fellow wasn't talking about slapping some RAM sticks to a breadboard and running current through the wires. Of course you would need a memory controller. Duh. :) The problems you raised were solved many years ago. If they hadn't been, nobody would be using volatile memory(like SDRAM) at all - it'd be too unreliable.

I almost think you're just looking to spread some FUD.

"Mission Critical" data, whatever that may be, would be existing at tiny charges on the very tiny capacitors,

You say this like it's a bad thing! It's relied on every day. Hell, mission-critical data on its way to be written to disk is nothing but A CLUMP ELECTRONS MOVING ALONG A WIRE, in a lot of cases, those wires many times smaller than a human hair.

Don't make a mountain out of a molehill. This isn't a bad idea, and just because they'll have to put a DRAM controller on the card doesn't make it one.

Dave

Barclay family motto:
Aut agere aut mori.
(Either action or death.)

Platypus Prices from CDW

[l1nuxn3rd]

Here is a link to the Solid State Hard Drive Pricing Page from CDW.
http://www.cdw.com/shop/search/results.asp?grp=HSO
Platypus products are listed as well as some from Quantum and Sandisk.
You are talking $1,969.40 US currency for the Platypus QikDRIVE8 512MB, the smallest model i saw.
CDW is the Authorized reseller I found for the US.

Already available for most RAID controllers....

[X]

Most RAID controllers will give you a battery backed-up write-back RAM cache. Depending on how you configure it, it will say that a write is committed as soon as it's in RAM. This accomplishes the same net effect without requiring all this modification of the OS.

Of course, lots of people don't like to configure their RAID controllers this way, because there is no redundancy for data in RAM, not to mention that the risk of failure is still higher than with a hard disk.

I hate to say it, but that article seems like it was written by someone who has not been out in the real world.

Come to the point!

[zmooc]

To the author:

Why on earth do you want to tell us things like this Unix was designed to be simple. This means, if they found that they could do certain things as libraries in user space, then it didn't belong in the kernel.? It has absolutely nothing to do with TRAM. Actually that's true for nearly everything you say in your article; you use a lot of irrelevant examples and try to mention everything you seem to know about Unix and then explain the solution in 2 lines?! Why don't you mention the real interesting things like that such cards most probably fail just as often as UPS'es, why this should be on a PCI-card and not on the disk (ok that's because you want to access the memory directly, but please explain this...) or what the consequences are concerning access-time?

Although the idea is good, I think you could have done a much better article; come to the point!

Whats so radical...

[A Masquerade]

This has been talked of for quite a time, and is hardly radical. Whats more it is not an alternative to journal based filesystems, but logically its an adjunct to them.

First you have your filesystem that buffers transactions in a journal that is streamed to disk. Then, for performance, by avoiding all those extra seeks, you put the filesystem journal on another device - say a small fast dedicated disk. Then you make that device a NVRAM device rather than something based on spinning rust.

Whats more, if you are interested in something like mail systems, where you get a lot of transactions that *must* committed to stable storage (although a lot of MTAs don't do that in spite of the wording of RFC821), and you use a fileystem like ext3 with a data journalling mode, then putting the journal onto NVRAM makes a huge difference - by the time it comes to the point where data would be committed to the disk from the journal, most of the data (ie e-mail messages) is now unwanted (since the messages have been delivered to final local destination or for onward transmission) and so you don't even need to do the disk ops...

All of this is pretty much available now in ext3 other than the tools to get the journal onto a NVRAM disk - and thats just detail.

So, nice idea, needs more flesh, a little more infrastructure needed round it.

[Those who came to the London UKUUG Linux Conference might well have heard these discussions before going on in various corridors :-) ]

Re:Interesting idea but..

[jmp100]

You'd have to implement a completely separate bus or you'd risk getting severely bogged down. You'd have to make a dedicated bus that went from the CPU to a dedicated slot and then to the hard-drive controller. Doing this on a PCI bus like that which exists today would not be particularly efficient. Certain IDE and SCSI drives talk at 100MHz and up; having disk I/O passing over the PCI bus TWICE (CPU -> TRAM -> HD) isn't the way to go, since your Ethernet, video, and other PCI devices are also competing for time on the bus.

Of course, implementing a separate bus will take millions in research (after all, it has to be done right), but once everything is decided on, it's probably only $20 or so in extra hardware. In theory, all you'd need is another PCI bridge chip or similar. Ever seen the inside of a NetApp? The motherboard has a CPU, space for RAM, a PCI bridge, and some slots. Nothing else. Extremely simple.