> I don't expect that any of the filesystems would or should > change their > behavior, or Linux changing its caching policies. My point was that if > you can't afford loosing the data you better assure to write the data > synchronously or programmatically flush the buffers from time to time > assuring to have consistent data to recover from.
Granted, if the assumption is that the primary applications are monolithic (such as a DBMS) and can be controlled in how they queue data to disk. The problem I have with this approach in general may be a more historic one, eg that so many of the Unix application programs available in my environment are dependent on the concept of strings of small single-purpose applications assembled into larger applications, and the connections between those programs being (and must be) buffered to allow the various interconnections to work properly. Things passing through pipes or output via stdin/stdout *can't* be forced to write synchronously, because we don't *know* how they'll be connected. Unix pipes haven't developed the CMS Pipes ability to wait for a pipe to catch up to a sync point and then write the output in a new burst. > It is not necessarily about backups exclusively. XRC and PPRC aren't > just snapshot technologies, but are meant to permanently replicate all > data stored locally to a remote storage subsystem. In case of > PPRC with > GDPS/HyperSwap this allows e.g. to non-disruptively to your workload > swap storage subsystems either locally or remotely. While > more expensive > certainly more convenient than falling back to a backup you don't have > any well defined data recovery scheme identifying what you've > lost since > then ... True. We could also exploit dual-copy much more often than we do (although one would wish that it wasn't such a pain to enable/disable dual-copy from VM -- a DUALCOPY CMS command similar to the FLASHCOPY CMS command or a CP SET DUALCOPY cuu1 cuu2 ON/OFF would be a very useful thing). This is also one of the reasons I was hoping that EVMS would catch on. LVM2 has some of the functionality we want, but overall EVMS did a better job of presenting this kind of abstraction. Of course, IBM *could* open-source SAN Volume Controller (or at least support it better on Linux/390), and we wouldn't be having these discussions...8-) Cheers, -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
