begin quoting Tracy R Reed as of Mon, Mar 24, 2008 at 02:53:41AM -0700: > SJS wrote: [attribution lost] > > Should an application call fsync(), the expected result (blocking > > until the data is written to physical media) will not happen. > > > >...and that gets me annoyed. > > > >What's wrong with respecting fsync()? This is betraying the user's > >trust in the system, really. > > Not really. The user knows he just spent a ton of money on one of Violin > Memory's terabyte RAM devices or that they spent somewhat less on a > ton of RAM and then set up Ramback so they know exactly what they are > getting into. Plus they want the apps to run fast and don't want to have > to go through the code and strip out fsync's.
So going through the trouble of buying one of these terabyte devices, configuring and installing Ramback, and reading the documentation so they "know what they're getting in to" is to save them the trouble of stripping out fsync()? Huh? That's like saying "I purchased a new mercedes to avoid the expense of using public transit". > When I was at MP3.com we bought these big Storagetek disk arrays (our > first one was 1.6T in 90 18G Fibrechannel disks yielding around 1T of > usable space after RAID 5 and hot spares etc) and they had two "storage > processors" which were PC-like motherboards with Alpha processors, PCI > bus, DRAM, etc. with something like 512M of cache in each one. And they > would return from fsync and cache the data in RAM before having written > to the disk. They had batteries built into the chassis which would > maintain this RAM and power a special hard disk to write the RAM > contents out to in case of power failure. Overall a pretty similar setup > as the RAMback. Actually, they sound more like a big disk. > Not nearly so much RAM but failure of the system could > ruin your data. And these were very popular units deployed in countless > datacenters in both private businesses and government facilities all > over the world. Popularity is a lousy indicator of reliability. IMO, of course. > I've never heard of a single problem resulting from the > way they handle fsync or failing to get the memory written to disk. This > is pretty common in the storage industry and a well accepted practice. Yup. Putting a battery _in_ the device and building in auto-flush logic goes a long way towards mitigating the most common failure scenarios. [attribution lost] > > You just need to believe in your battery, Linux and the hardware it > > runs on. Which of these do you mistrust? > > > >Duh. All of 'em. > > I think a system can be built which would work quite well I'm sure one could. Whether or not one _would_ is another thing. > and which I > would trust. Others have done it many times before as I note above. It So what are you trying to say here? That I should trust these things because you do? Or because "many others" have done so as well? Bah. More people run MSwindows as their primary desktop OS, so by the popularity logic, MSWindows is THE BEST operating system, and we should all give up on this Linux crap and stop trying to think, judge, or decide for ourselves. Have I mentioned just how much I despise popularity-based arguments? > wouldn't be Wal-mart hardware. And it wouldn't be running X or a bunch > of other extraneous stuff. And yes, I would keep close tabs on the UPS > and wouldn't buy the cheap home-office unit from Best Buy. So, you're saying that this is a good idea if you buy high-end hardware for a dedicated machine? You start putting _those_ kinds of constraints on the problem, and I shall start agreeing with you. IF you take a sober, considered, careful assessment of the tradeoffs, AND you are willing to expend the money for hardware of sufficient quality, AND you deploy your hardware in such a way so as to minimize the chances of accidently catastrophic failures, AND you maintain a semi-rigorous schedule of testing and verification, THEN I would happily refrain from any sort of I-told-you-so. Of course, what I'm now wondering -- why are we bothering over all this journalling filesystem nonsense if we're also considering something that makes journalling pretty much useless? > >I have six UPSes at home. All of them have failed at one time or > >another. Batteries are consumable items, and who goes around replacing > >a UPS battery at home once a year "just in case"? > > This isn't for a home application. People who use this kind of > technology and really need to rely on it do indeed test and change out > batteries on a regular basis. So, to maintain that uptime, dual redundant power supplies are needed. -- I need a way to retrofit dual power supplies into a computer. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
