On 6/10/05, McKown, John <[EMAIL PROTECTED]> wrote: > I have no idea how to do anything about z/VM's MDC, if that is involved. > This also assumes that a each logical DASD volume under z/VM is a > physical DASD volume. The DASD would likely need to be CDL formatted as > well.
At least I know about z/VM a bit. MDC is not "lazy" and the Linux write to disk only is done when the data is written on the disk. In fact, in most cases the data will only be inserted in MDC upon reading from disk (which is not good but I cannot get the ears bent for this). Also, if you behaved well you have defined these packs as SHARED in z/VM because another system might also write to them (in the event of a restore) and this will disable MDC completely for these volumes. The full backup you make with FDR or whatever is as good as what you get when your Linux system crashed without synch of its disks. All dirty data is lost forever (can be quite a lot) and your disks will be marked dirty and need to be fsck'ed when you get up again. The default for journaling filesystems is to only journal the metadata so you know what you lost but you will not have the data anymore. All my experiences with trying to recover a ReiserFS disk after a crash have been very unpleasant. It may be due to some mismatch between the kernel module and the userspace tools, but I have never been able to sort that out. While you cannot prevent a sudden crash, you probably don't want to make that the standard for your restore quality. On the other hand, there is a timer in Linux that pushes out dirty pages after default 30 seconds, so an idle Linux server will be mostly clean after a while. You would still run a risk for log files etc, but that may be something you can live with. There's also things like snapshot techniques in Linux. Using md you could divert updates to a separate disk while you backup the main one, and after backup open the flood gates again. This does not give you a consistent backup of the filesystem like Linux would be shutdown, but at least it avoid changes over the disk while the backup traverses from one track to the other. If you want file level backups, you probably can not get away from file level utilities that run inside Linux. And backup of the system while the applications are running is tricky even then unless the backup tool can talk to the applications to do the right things. But it would be helpful to restrict the file level backup to the things that are modified by Linux on file level, and not the full operating system and application code. I am seriously looking into various options to separate code and data. This is good for sharing, but also very good for backup / restore issues. I expect good things will happen in that area in the near future. Rob -- Rob van der Heij rvdheij @ gmail.com ---------------------------------------------------------------------- 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
