Slashdot Mirror
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?
Thanks. I was about to change the url to betanews.com to read that when I saw an article with no comments. It was posted at 3:21 and I went, hey.. I might have a chance to become like all those other /. lamers and go for a first post!
Thanks for not trolling on me for beating you to the first post, Tronster.
----------
----------
Check out my blackbox styles
Did he mean "RAM and hard drive price both continuing to decline"?
I guess its a neat idea, but it seems like a hack to get around using a JFS. Maybe a Journalling FS takes some time to implement, but i run reiserfs on my laptop just fine with no problems (cept that time I forgot to include it in a kernel compile and rebooted... oops...). This is a lot of work to go through just to get around writing some software.
Also, isn't this going to be a pretty significant load on the PCI Bus? Whats the latency on a pci transaction? It seems like you could run into all sorts of troubles there and perhaps end up slowing down your system with all the traffic..
Or perhaps the pci bus is loads faster than I imagine?
If it's mission critical it should be on a UPS with controlled shutdown. No fsck on reboot.
If you're talking about the actual in-case PSU going pop, then reboot time is the least of your worries.
I must question the sanity of someone who mentions "Fight Club" in a list of otherwise brilliant, distinguished works of art ;)
And remember, he was only god as long as someone believed.
Can someone find a price on the 2 Gig HD from Platypus? The website provided is nonnavigable, and I cannot find a reseller that displays a price. It seems like a cool idea to have a big-ass RAM HDD, but I know it will be expensive.
Just something to think about for those still skeptical...
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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?
Am i mistaken or did this article feel just to warm and fuzzy. I know there is a lot of good technical info in there but its all wrapped up in a very strange manner. I dont think you are solving the whole problem, by overlooking and waving your hands over the rest. I mean so you put a few sticks of memory and power on a PCI card! You do this cause a UPS can die, well i got news for you, the PCI Card could die too! AND if you are trying to make reboots faster, dont bother, if you are serious you would have a backup system and the same should be true for a web server dying. The only time i want fast reboots is when a good game of UT croacks on me and i want to get back to fraggin..... this is not technology i would use for mission critical apps!
Hmmmmm... the more I think of it, the more it feels like a marketing team thought that a semi tech article on Slashdot would be just the ticket for killer web site traffic! Maybe its the lack of caffinne on my part...What do other ppl think ?
Non-Deterministic Finite Automata
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!
PJRC: Electronic Projects, 8051 Microcontroller Tools
First, it is absolutely critical that the OS creates some log or structure of operations on the TRAM for filesystem operations. Basically, if the OS can mark the beginning and end of an operation and place it in this memory, you can now get a journaled meta data filesystem without a complete re-architecture of a filesystem.
Basically, if the OS can determine the beg/end of an operation (transaction) and it logs this information, then we have a journaling file system. Any persistent storage will suffice for the journal - 'TRAM' or hard disk or clay bricks. The only difference is the access time.
In general there is no magical way for the OS to know what data is the beg/end of a transaction. The OS could try to handle meta-data in this fashion. It can log the meta-data changes it would make in atomic transactions and replay un-commited transactions on a reboot. However, the file system still needs to be aware of this journaling.
Consider a power failure during a commit to the file system. The file system is in a partially modified state and the transaction has not been retired from the TRAM journal (since it did not complete). When the system boots again, the TRAM journal is replayed and the same operation begins again, except this time on an inconsistent file system. The file system needs to recognize that a partially commited transaction needs to be rolled back.
The above is based on my (very incomplete) understanding of journaling file systems. However, a TRAM card amounts to a cache for a file system journal, so in no sense is it going to replace or leap-frog journaling file systems.
Here is a link to the Solid State Hard Drive Pricing Page from CDW.O
http://www.cdw.com/shop/search/results.asp?grp=HS
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.
couldn't find any...
and binary ones only for 2.2.17
this is the problem with closed-source drivers for an fast-changing os like linux...
yuck
Ring brother, ring for me | Ring the bells of hope and faith
Ring for my damnation | I am at the gallows end
What seems more likely is to use it for replacements of hard disks. And this made me remember that it already is used like that. For example Electronic Organisers. But you'd want to have good battery testing and hot swapple battery so you can replace the battery while the machine is up. I wouldn't want to rely on a battery to protect my data as they aren't very failsafe.
AussiePenguin
Melbourne, Australia
ICQ 19255837
Jeremy
Melbourne, Australia
Jabber Australia
Running ReiserFS on Linux. Boots fast without a problem. Anyway, how often do you reboot anyway? One power failure in the last 6 months, and rebooted once to upgrade the kernel. ReiserFS is so rock solid and so fast that I haven't bothered replacing the bad battery in my old UPS. Don't need it. Try ReiserFS. You'll be impressed.
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.
sigs are a waste of space
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!
0x or or snor perron?!
wow, if only the 8GB ones didn't cost $26,000.
Network Appliance has been doing this on their filers for many years now and it works very well. Although I would question using DRAM for the purpose. How would one know when their battery has failed? NetApp uses 32MB of NVRAM and a lot of other fairly commonplace technology in an interesting fashion that results in a very very fault-tolerant piece of hardware. I have a 600GB Filer (limited to 200GB volumes for back expediency) that I can pull the plug on at any time without damaging the filesystem. As a matter of fact, I have done this on occasion. Boots take a few minutes regardless of how the filer was downed.
The whole industry works towards less hardware to do the same job all the time. Solving a software problem by adding hardware is not the way to go, especially not when ReiserFS etc. are already present.
He gives the explanation on why they shouldn't be on disks....
ARRGGHH
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
Fail-over clustering. Being redundant is good, good, good. If we think a few sticks of ram are going to solve inhierent file system problems we either dont understand the problem or we dont understand the technology. I see it's benifits but for some reason it feels like it should be part of the hardware architecture rather than a simple pci card with yet another buggy driver supporting it and making it all work.
wow, you've taken what was otherwise an interesting article, and stolen its virtue, it's purity,its virgin soil, with a stupid first comment that only inspires other idiots to reply to it.
And don't burn karma, there is plenty of coal to go around for all, and it lights much better.
(Forgive my sentiment, for it's late, I have had a long day, and you're an asshole)
Why yes, all my base are belong to you.
How did you guess?
... to solve a problem that can be trivially addressed by just buying a UPS!
All it takes, is a UPS that has a serial port to tell the machine that power was lost, and the host can just sync and halt before the power goes out.
If what you want is a genuinely reliable system, then start working on EROS (www.eros-os.org)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
EROS implements global, orthogonal persistance by checkpointing the machine to disk every five minutes or so. If you lose power, the machine restarts with all of its state intact as of the last checkpoint. No fsck, no muss, no fuss, and provable security to boot!
Check it out at eros-os.org.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
is such an idiotic idea. What he wants is a battery backed hard drive buffer. Does that take 20 pages to explain? I have the same thing right now, I call it an UPS. It does the same thing without the slowdown of a PCI slot throughput and it doesn't cost a lot. So if you're reading this, I ask the question... Why battery back a buffer module and not the whole system? And this is only for production system... Home users would still need a JFS because they sure as hell don't want to pay for this shit! How many home users backup their systems period?
To all JFS developers, 'Nothin to see here, move along' with development.
Aside from some reliability issues of this technology, I wonder if it's worth the trouble.
Besides, BeOS boots in about 15 seconds into GUI, even if you previously turned off the PC without shutting down. So, journaled filesystems DO have advantages. Linux may never achieve such high speeds in booting up, but still, I predict that a good JFS will benefit it.
Sigged!
The text says that there's no production-ready journaled filesystem yet for a free unix. I completely disagree with that. We use redhat linux on reiserfs on raid5 for some of our servers and it's MUCH better then normal ext2: no corrupt filesystems anymore, no 'enter root password for maintenance' when there's a fs problem anymore and it's much faster. Imho is reiserfs much more production-ready then ext2 or ufs.
It seems to me, that this idea like many things is simply an evolutionary idea as opposed to revolutionary.
....Paul
I believe that the original author's article is fundamentally correct but there is a bit too much arm-waving and it blurs the description somewhat.
If one were to actually perform more detailed analysis on the proposal, you would probably end up having to produce a journaled or transaction logged system with all their related overhead. The difference being that the journal or xactlog buffer is a battery backup XRAM device instead of the hard-drive itself.
This could improve performance of this part of the system significantly.
After all, I think this is just perhaps another (better?) way of doing the same thing...
F U NE X N M? Son: "Dad... How do you spell 'hourly'?" Dad: "0 * * * *"
Whenever your computer told it to write to the disk, the first thing it'd do is write each sector to the cache, and write the drive and LBA sector number to a separate section of memory. The controller could then index this structure by LBA to implement "elevator" writes, vastly improving performance with little risk of data loss.
With enough memory, it could also be configured to permanently cache the MBR, boot loader, kernel, init scripts, daemons... Make it big enough and the whole swap partition is in there, too. Think how fast something like this could boot.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
I remember back in '86, a manufacturer had an 8 meg RAM drive with a big gel cell backup battery. Essentially, a DRAM hard drive like you are describing for a cache. It worked on apple IIgs series computers, which usually had less than a meg of main memory, but could be expanded to 4mB. I am sure a RAM drive could be built today. I am not talking about the solid state hard drives some posters have commented on. They are using static RAM and communicating through a PCMCIA port. They have maximum throughputs of about 1MB/s sustained, which is not very useful if you are working with databases. If anything, having your OS on one of these would give amazing startup times. The apple IIgs usually booted from an 800kb floppy, and took a few minutes. Ads for the RAM drive said seconds! With a 1.2MHZ processor! Ahhh. the good ol days.
But seriously, why the hell would you use this for a cache instead of the main drive? Why go from battery RAM -> Hard Drive -> Tape and not just batt. RAM -> tape? Espically if it is battery backed?
Speeding never killed anyone. Stopping did.
Cos it don't work. I said that 3 weeks ago, and they're still pestering me.
-- Real Men Don't Use Porn. -- Morality In Media Billboards
Also FatPhil on SoylentNews, id 863
see the Rio / Vista work by Pete Chen, Dave Lowell, et al. which won best paper at SOSP several years ago...
Multics had the same problem after crashes: it took a long time to bring the system back up because the "salvager" had to check every "VTOC entry." (fsck/inode in Unix terms)
We re-wrote the file system to do the necessary checking on each use of the directory and VTOC data, and eliminated the salvage during boot. Everything still got checked, but only as needed. Boot times went from hours to minutes, and the system was much more solid and reliable.
See http://www.multicians.org/thvv/marking.html
I was at a talk by Stephen Tweedie (one of the developers on Ext3). He was saying that one of the recent things he was working on was storing the journalling data on a separate device from the hard disk where the data is to be stored.
Initially he has tried storing the jornalling data in RAM to test performance but the plan is to store the journalling data on a NVRAM card that he was waiting to be delivered. This will increase speed of synchronous writes, like with databases and sendmail and give all the benefits of journalling.
--
Steven Murdoch.
Steven Murdoch.
web: http://www.cl.cam.ac.uk/users/sjm217/
You should read this Bob The Angry Flower comic:
http://www.angryflower.com/bobsqu.gif
How about this TRAM stored on the disk drive, and have the OS simply tell it the dependency DAG? It can perform its own write reordering (probably more efficiently since it knows where the disk head really is and all the specifics about its geometry) and then finish off the queue when first getting power after a power loss.
I find it odd that in today's world, I still can't get a default distro of Linux or any free *nix with a journaling filesystem preinstalled as the default, and with a fs driver considered to be STABLE or RELEASE. Yet, Windows NT has had a full journaling filesystem since NT 3.x....
Since NTFS is journaling, supports reparse points, extended meta data, and more, I look forward to the day when the NTFS fs driver for Linux is stable enough to boot from, then I can have one *stable* filesystem across all my disks.
I might add that a boot-time chkdsk on a rather large partition (chkdsk on NT == fsck on Linux) takes less than 30 seconds, many times even less. Contrast that to your average ext2 or FAT32 system, which can take many minutes to check.
-- russ
-
The IHA Forums
Natural != (nontoxic || beneficial)
Chris
What's the difference between an orange?
Perhaps in the UNREAD (which I guess is fairly large, hurmf) portion of the community. Chapter 8, section 2 of The Design and Implementation of the 4.4BSD Operating System talks about this idea on page 284. It referrs to research done by Moran et al, 1990. The references at the back of the chapter refer to "Breaking Through the NFS Performance Barrier," Proveedings of the Spring 1990 European UNIX Users Group Conference, pages 199-206.
So there you go, there's TWO ways that we could have heard about this. I doubt anyone here got that first hand, but the 4.4BSD book is a fairly common book to have for those who are interested in the innards of an OS.
-bugg
I don't know, but I think the author may have been writing to a different audience. It just didn't "sound" right when I read it.... maybe posting it to Slashdot was a bad idea for the poster. The idea of TRAM sounds rather ridiculous honestly, except in something like a mainframe or midrange system where the OS and the hardware are designed by the same people. But even so, it still wouldn't be useful for what the author intends.
Like many other posters have noted, it seems like the author really doesn't have any real world experience with this environment, but just though "Hey, this would be useful if it worked..."
A slip of the foot you may soon recover, but a slip of the tongue you may never get over. -Benjamin Franklin
Seriously...do they use some special proprietary ram? 8G of cdram in 512 meg chunks is only a couple of K. Hardly justifies another $24k tacked onto it. Is this another example of "charge what the market will bear"? I understand there are development costs and the like, but _geez_ $26k is _a lot_ of money. Don't give me an answer like "they are not intended for home use, so they charge more", because that's a bullshit reason (even though it's done all the damn time).
-- Who is the bigger fool? The fool or the fool who follows him? --
i dont giva damn about DBs. gimme one of those cards for my linux box and ill just use it for everything needed to boot and the rest as a swap partition. this would make my linux box boot in like 5 seconds... awesome
Not True.
Data ONTAP is written in house. The only parts from BSD is some of the network stack, and that has been changed heavily as well.
--Britt
This is what the Network Appliance boxen do to speed NFS writes.
All NFS write transactions are commited to NVRAM first, so that they can be acknowledged. Then the writes to disk are sorted and blasted out. Very efficient, very fast.
It is this NVRAM (as well as using a modified RAID-4 on top of the WAFL filesystem) that makes a NetApp much faster (yet still safer) than most other NFS servers. I've often thought about creating just such an NVRAM board for a PC, so that I could do the same thing with my Linux fileservers.
Note that the NetApp implementation caches NFS requests, not filesystem-level data. Say I'm changing 1 byte in a block. If I buffer filesystem data, I have to cache the whole block. If I'm buffering the NFS request, it'll be much smaller.
Buffering (in NVRAM) the log data might work well for something like ext3.
do you happen to know to what extend BSD code is used... and what flavor ( F/O/N BSD or BSDi ) ?
Bob the angry flower: plural's
(yeah I know plural's is wrong, but that's the name of the strip, okay?)
--
Slashdot didn't accept your submission? hackerheaven.org will!
There are better ways to fix this problem, such as put a battery backup on system RAM, so that the OS won't need to be reloaded at all; it can pick up where it left off when power to the CPU comes back on.
And if computer power supplies were also designed for battery-backup (dual-voltage, can run on either 120VAC or say 24VDC) then the complexity of the UPS (converting DC to AC just so the computer can convert it back to DC again) would be eliminated, and the result would be more reliable. There should be a standard connector so an external lead-acid battery can be plugged into the back of every computer, and the power supply would be responsible for keeping it charged, and switching to using it when the power fails. (But there should be a switch to turn off the charging feature in case you have several computers hooked to one large battery with a separate external charger.) Then maybe when the power fails the OS would be notified, and it could finish doing any uncommitted writes before powering off the disks and CPU; the battery would continue to backup the memory for a very long time since it would be such a small load compared to the whole system. That way the two battery-backup systems could be combined. (Or not... maybe a separate memory backup would be more reliable.)
Note, no free unix today has, at least to the point of people trusting their main database on it, a production-ready journaled filesystem.
Linux+ReiserFS.
I would trust ReiserFS to keep my main DB safe, I've been using ReiserFS with Linux for some time now with no data loss. (and many power failures and some crashes due to a partitcular closed source XF86 video card driver)
-- iCEBaLM
"Linus made me do it," says Mcdermott
The system RAM could be kept around just as easy on a battery. Mark the transaction section of RAM and on boot you could read it back. No more PCI card and MUCH faster access.
IBM is supposedly releasing its magnetic ram technology in a few years. This is like core memory (needs no refresh, non-volitile). If the OS knew that the memory was non-volatile, it could do everything needed to be used as TRAM.
JET Program: see Japan, meet intere
Great idea - I've always wondered by we are no longer using these. My old Apple IIGS had a battery backed up Memory card which I always kept a copy of the OS resident in. The system was very fast to boot. Memory's cheap yet these devices have all but disappeared. You know your're getting older when old ideas become new again...
- Stick small install on it, and you get a nice, reliable, silent thin client (no noise)
- Stick it in a normal machine, and you have a much more reliable place to stick data.
- In a normal machine, stick
/usr and /etc on it (in Linux) or /windows (in windows) on it, and you get almost instant boot.
I've been hunting for one of these for ages, as have several other people. Right now, high-end ones cost shitloads of money, are huge (gigs), use fans and tremendous power (usually). Embedded ones require special motherboards and special (usually binary-only) drivers. (Note: I mostly looked at Quantum's models, Disk-on-Chip, and several similar companies)To my understanding thats what my RAID controler does. Unfortanly fsck still wants to run on my RAID after a power cycle, but I just need to install a jurneling filesystem on it to acomplish the speed of the powerup.
:)
Even with some of the problems I have run into with power around here befor I got my UPS I never lost a single bit. The Mylex 1164 RAID controler comes with a minimum 32Megs of read/write cache, that has a battery backup.
Now granted, it wasnt cheep, but with my small income I still managed to afford it. Also the Linux drivers worked perfectly. With RiserFS (or the likes) this would be exactly the solution he is talking about.
If your a geek like me with a big collection of mp3's and mpg's you can not lose, and have many users, its the perfect solution. It was for me
-magister-
This sounds like a lot of standard techniques already in use in storage today. Many storage controlers (FibreChannel/SCSI, RAID/nonRAID) support battery backup power that will let them finish writes. Most use internal write and read cache and include lots of memory. Transaction support already exists in some ways. If I send a command to write 1024 bytes to a disk that does 512 byte writes, a good controller will attempt to make the 1024 byte operation atomic even though it is internally broken up into multiple 512 byte writes. File systems fragment the pieces of a file and thus have to issue multiple non-sequential commands for a given operation. This is where the problem errupts. Some controllers support combining multiple operations into one call but this is usually done without FS knowledge; it just fills a buffer of ops and then dumps it. RAID already handles the issue of non-sequential operations by hiding them. RAID may present a 1 terrabyte drive as sequential data when it is really stripped across various areas of various drives. When RAID is told to write 1 sequential GB out it is done as one operation, even though it involves many non-sequential writes to multiple locations on multiple disks. The trick is to put file system support in the storage controllers or RAID systems. With file system support, it will attempt to make sure that physically non-sequential writes that are sequential at the file level are completely written out. This doesn't happen much because for various reasons but does exist. For example, some RAID systems support running the file system on their system directly.
What does this do that is so different? At $300, it may be less expensive than similar solutions but I do not see "how it differs from everything out there".
-- soldack
The Network Appliance also has a large DRAM Cache from 512MB 1 or 2GB on their latest released products.
The benefit of having an NVRAM write cache is that there is no requirement for a backup power source in the event of a loss of power. One can also cluster NetApp filers as well as have synced read-only volumes on other filers.
I wouldn't like to get into a heavy debate of EMC vs. Network Appliance other than to say that one can run a database application doing I/O over a network. One has to have a really good network though. Your Symmetrix is going to be FC connected to your hosts. In my application the Network Appliances are connected to the hosts via Gigabit Ethernet. The max speed of both media is 1Gbps. Granted there's going to be protocol overhead with the NetApp that would cause one to get less performance all other things being equal, except maybe cost. The EMC is going to cost 3x more.
I sometimes snicker at the odious convolutions
Unix administrators have to go through to
keep their systems up and running. I'm in
an HPe3000 shop and its automatically
self-journaling file system has never caused
boot-up problems on me in 17 years.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT