Matt Zimmerman writes: > On Fri, Jun 18, 2004 at 04:42:43PM -0700, Brandon Darbro wrote: > > > Huh? EVMS or LVM2 has a method of adding a writable layer to read only dasd? > > EVMS supports writable snapshots, using copy-on-write from an EVMS volume. > I haven't tried it with read-only DASD, but in theory it should be possible > for it to be used this way.
Unfortunately, LVM2 snapshots (I haven't looked at EVMS to see how they do it) are the "wrong way around" for this use. When you write to a volume that you are snapshotting, the original data from the block is written to the snapshot volume and then the new block data is written back to the underlying original volume. The advantage is that the original volume always contains up to date data but the disadvantage is that you can't have the original volume readonly. A further benefit of having a "new block data gets written to new volume" device mapper would be that you could take raw copies (e.g. with DDR) of un-quiesced (i.e. mounted live and somewhat active) Linux (journalled) filesystems and be confident that mounting the resulting copy will (after haing replayed the journal and hence provided the copy lives on a writable volume itself) give you a filesystem with consistent metadata. The result corresponds to a point-in-time shutdown of the filesystem which journalling is designed to cope with). Atomic snapshotting at device level (e.g. ESS Flashcopy) can give you similar functionality but is less widely applicable or convenient. Writing such a device mapper shouldn't be too hard given the nice new dm infrastructure (which I haven't looked at detail and really must sometime): reads/writes in non-snaphot mode go straight through to the original volume. In snapshot mode, a write to block m causes the new block data to be written to the "next free" block, n, on the snapshot device along with an entry in a map at the front of the snapshot device mapping m -> n. Reads look up in the map on the snapshot device and get the redirected block or else a read to the original block if unmapped. You then need a feature to merge back the new data into the original volume when desired. And you really, really don't want the snaphot device to fill up because the failure mode is much, much worse than letting an archive-style LVM snapshot fill up. I'd love to hear if EVMS has a mapping facility in that direction already. --Malcolm -- Malcolm Beattie <[EMAIL PROTECTED]> Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself ---------------------------------------------------------------------- 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
