My SCSI controller
already has RAM, isn't that TRAM?
Has anybody used
this technology before?
What about read caching?
Doesn't my OS already
buffer writes to memory instead of disk?
Don't I need a special
Journalling Filesystem or something like that?
What if Microsoft
or Apple or IBM do not support it yet?
What about other operating
systems - I'm a (FreeBSD, *BSD, Linux) User!?
Why Is It Called TRAM?
What Is Necessary To
Make TRAM?
Why did I write this?
Shouldn't this
be in a hard drive controller or in the drive itself?
Why wouldn't FLASH memory
be good for TRAM?
Don't laptops already
act like they have TRAM?
Does this elminate RAID?
Imagine....
Would people pay for 128 megs of memory
plus a little additional hardware (battery, support and interface circuitry),
to achieve this kind of phenomenal performance? I think a lot of
people would purchase this kind of thing yesterday. This technology
would speed every operation that would have required a complete disk write.
I think there are a lot of systems in all businesses today that could use
the benefits of TRAM.
Now, TRAM is a form of non-volatile memory that is very fast. Usually, it would probably use the same memory you use in your computer. However, there would now be a battery to keep the memory from losing it's data. If you added some TRAM to a computer (probably as a card), it would act as a very fast middle ground between your very fast CPU and the very slow hard disk.
For example, whenever your computer had to write to a disk (usually as a part of a thing called a transaction), it would write to the VERY fast TRAM instead. After that, you or the program would be free to do more work. Periodically the data in TRAM would go to the disk in the background. When a computer is used as a server, it is often the case that the software has to wait for data to get written to the disk before the operation is complete. This kind of thing can happen quite a lot with many applications. With TRAM, your applications wouldn't have to wait. The result would be a TREMENDOUS speedup.
What is required, just a card?
Yes and no. A card would be all that is
necessary hardware wise. s well as some changes in the operating system
you are using. See, there would have to be some software to support this
hardware. Fortunately, this isn't a tough job at all.
My SCSI controller already has ram, isn't that TRAM?
No. All the SCSI controller's that I have seen with RAM use the memory to buffer reads instead of writes. If the power fails, the data would be lost before it was stored on the disk. (Note: Adaptec just released a RAID controller that does write-back caching without battery backup. It only supports NT, which has a journaled filesystem. So when you lose power, you will the data that was thought to have been written. In my opinion, this isn't any good at all.).
Has Anybody Used this technology before? Isn't this an old Idea?
YES, and it is in use now. Unfortunately, it is not in common use. That is the purpose of these web pages.
It was probably used first, in some fashion, when the very early computers were used (1950's-1960's). A lot of the early computers used used a ferrite-core memory system, which was inherently non-volatile. I'm sure that some designs depended on the memory's non-volatile characteristic for doing transactions. It has also been talked about in various academic papers throughout the past as a performance enhancement for various applications. I'm sure that some companies have built products like this in the past. On unix computers there was a product from Legato called Prestoserve that was exactly what TRAM is. Unfortunately, it was expensive and licensed for use for one specific purpose. It also looks like it disappeared from their product line.
Today, you can buy devices which use this technology. TRAM cards are a standard issue In Network Appliance, Auspex, or Sun NETRA file servers. However, each of these vendors use TRAM in a different way. Also, you can't buy just a TRAM card from them. They like selling the whole package in order to differentiate themselves.
Still, you can't easily buy a TRAM card and use it with any of the common operating systems today.
It shouldn't!. All this card would have
is memory, a few glue chips, and a battery. Add a cost of $100-$200 to
the cost of the memory SIMMS for the card and that is how much it should
cost. This is an EXTREMELY cost effective way of making one of your computers
an equivalent performer to a computer that is supposed to do the same thing
for much more money. (Go out and see how much a high end Sparc, SGI, or
IBM costs these days :-)
If you were doing a lot of new reads, then the computer would have to go to the disk to satisfy the reads. However, most computer users these days have tremendous amounts of RAM for this purpose. If they don't have to reboot their computer, they will be able to cache the applications they use. Also, the first generation of TRAM's will probably not cache 'reads' because your OS already does that.
Now, if the TRAM was large enough, it could be a read and write cache. For example, if all of your computer's memory was battery backed, then it would act as a large TRAM. Then the read caching and write caching would be in the same memory. Now, if your computer didn't reboot for a long time, the chances are very high that you would not have to hit the disk for a read or a write.
Doesn't my OS already buffer writes to memory instead of disk?
Yes and no. For some things it does, for
others, it does not. Most of the interesting things that happen will require
a write to the disk before the OS can consider it complete. For example,
directory operations are required to be atomic, and persistent (like a
transaction). Databases generally require that their writes hit the disk
before a transaction can be committed. That means ALL database writes folks.
TRAM would make these things happen without having to go to the disk.
Don't I need a special Journalling Filesystem or something like that?
Yes and no. A journalling filesystem is a filesystem like NTFS on NT or the WAFL filesystem on a Network Appliance Filer It is different that FAT, UFS, ext2fs and other filesystems.
All I can say, is go back to the main TRAM
page and read the paper that I wrote. I talk about the various methods
of implementing TRAM with filesystems. In a nutshell, it would NOT take
a lot of work to keep existing filesystems and keep them in a consistent
state. (ie., a fsck that takes seconds instead of minutes!)
What if Microsoft or Apple or IBM do not support it yet?
Maybe a third-party could implement the code as an extension to those operating systems. At any rate, once one of them or one of the operating systems in the next question adopts TRAM, it will become quite common. I can also imagine them eager to sell upgrades in order to utilize this technology.
What about other operating systems - I'm a (FreeBSD, *BSD, Linux) User!?
Luckily, there are some popular unix OS's
out there that could go for this technology. FreeBSD and Linux are popular
free operating systems with source code. With very little effort (and some
hardware), support for TRAM would be not too far away. Also, since a lot
of these systems are being used for server side applications, they is already
quite a demand.
Why is it called
TRAM?
What is necessary to make TRAM?
All of the technology to build this equipment has been around for years. In the next section, you can see some examples of this. From a complexity point of view, these devices fit in the low-complexity category. Essentially, you are adding RAM to a computer. This is not a new problem and there are a lot of designs available for doing this easily. For the memory, you could choose static RAM or dynamic RAM. Then you could power this with any battery technology available. With the advent of laptops, battery technologies have progressed quite dramatically. So, the bottom line is that TRAM hardware could be completely built from existing off-the-shelf technology.
Well, to be quite honest, there was no way to build this product and get paid in the process. I would have had to patent the idea in order to protect the idea if I approached companies to build it. Generally, these companies like ideas that haven't been done before so they have the least amount of competition. That is not the case here. This thing has been done in the past for a lot of platforms.
Then a friend said, "Just put it out there".
He was right. All that I really wanted was the technology to be commonly
available. This avoids all of the business hassle and puts better people
on the task. A couple more friends suggested 'putting the idea out there'
via the web. Now, I really feel that this is the best way.
Shouldn't
this be in a hard drive controller or in the hard drive itself?
It could be. However, it would probably be best if it was separate from a specific drive controller. This would limit it's application to certain drives attached to a controller or to just the drives with TRAM. By having TRAM as an independent card you could use it with any drive in the system using any interface (IDE, SCSI, etc.). You could also use it with existing systems. Another good reason is that maybe it won't be used for the drive. Maybe it will be used for an application which just requires good fault tolerance (like the 'state database' of a network address translation (NAT) process of a network router).
In the future, maybe all of your computer's
RAM will be TRAM. I believe that this is probably the best way to go.
Why wouldn't FLASH
memory be good for TRAM?
A TRAM module would be getting a lot of writes. Most FLASH memories can only handle 100,000 to 1,000,000 writes. A TRAM could get that many writes in a second.
Don't laptops already act like they have TRAM?
It would be nice if they could. The only
problem with laptops is that they would probably erase the memory that
they had if they were reset. It is important that the memory is intact
after a reboot, so this erase sequence would hurt. If there was an area
of memory in a laptop that was guaranteed not to be erased, then that memory
could be used as a TRAM.
Does this elminate
RAID?
No, you would still need RAID. TRAM cannot back up all the data that your disks store. If that were the case, you wouldn't need those disks anymore. Disks still provide a good bang for the buck, they just don't provide speed. So, in order to make the data available via disk, the disk would have to be a RAID. You wouldn't want all of your data to go away because you lost one disk.