Browse Prior Art Database

Microkernel Extension for Cloning

IP.com Disclosure Number: IPCOM000112268D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 101K

Publishing Venue

IBM

Related People

Copeland, GP: AUTHOR [+3]

Abstract

A file system feature of growing importance is "cloning". A clone is logically a copy of a file or directory made at the time of the clone operation. However, it uses copy-on-write to prevent having to make the full physical copy and make the file unavailable during that copy. High availability is the main usage. A clone is most often used to make a backup copy without locking the original to get a consistent snapshot. However, the semantics of cloning is that both the original and clone can be updated independently after cloning.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

Microkernel Extension for Cloning

      A file system feature of growing importance is "cloning".  A
clone is logically a copy of a file or directory made at the time of
the clone operation.  However, it uses copy-on-write to prevent
having to make the full physical copy and make the file unavailable
during that copy.  High availability is the main usage.  A clone is
most often used to make a backup copy without locking the original to
get a consistent snapshot.  However, the semantics of cloning is that
both the original and clone can be updated independently after
cloning.

      Cloning implementation must handle copy-on-write for both the
disk and the cached copies correctly.  The File Server (FS) must
create a clone file, and maintain the disk copy for both the original
and clone files using a copy on write algorithm.

      The cached copy could be maintained correctly but inefficiently
by creating a new independent memory object for the clone, returning
and writing to disk all dirty pages of the original (backing file),
and having duplicate pages in the cache for the two memory objects.
However, approach has the overhead of cleaning the dirty pages (also
an availability issue), of having to request and supply the pages of
the clone memory object even though they may have already been in the
cache on behalf of the original memory object, and wasting physical
memory by storing the same data redundantly in the two memory objects
for pages that have not been modified.

      This overhead could be avoided if FS could ask the microkernel
(MK) to create a clone memory object to be used with the clone file.
The MK would maintain the cached copy for both the original and clone
memory object.  There is currently not an EMMI operation that
supports the correct behavior for the clone memory object.  The basic
functionality needed is already present (copy-on-write shadow memory
objects), but only for a temporary memory object.  What the FS needs
is the following additional EMMI operation that provides the normal
copy-on-write implementation but makes the new clone memory object
permanent with FS as the memory manager:

memory_object_clone(original_control, /* (IN) original mo's control
port */
                    clone_memory_object, /* (OUT) new clone mo port
*/
*/
                    clone_control); /* (OUT) new clone control port
*/

      The semantics of memory_object_clone() is probably best
described by showing how it is used.  The following describes how FS
creates a clone file C from an existing backing file B and how paging
is handled:

--------------MK--------------- ----------FS------------------
                                  create C using a copy of B's meta
data;
                                  mark C and B as clone and backing
files;
                                ...