All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric S. Johansson" <esj@harvee.org>
To: Tom Hibbert <tom@nsp.co.nz>
Cc: xen-devel <xen-devel@lists.sourceforge.net>
Subject: Re: organizing virtual machines
Date: Mon, 21 Feb 2005 21:45:27 -0500	[thread overview]
Message-ID: <421A9CC7.8070102@harvee.org> (raw)
In-Reply-To: <421A867A.6010002@harvee.org>

dead badger bites can be pretty nasty...

I believe I was over thinking the problem.

Given three pieces of data (base line file, diffs, and result) you can 
derive any one file from the other two.  If you have a /etc baseline, 
/etc diffs you can derive your working /etc.  This also means that if 
you make changes to working /etc, you can regenerate your diffs.  If you 
upgrade and have changes to the baseline, you can regenerate your 
working /etc.

operationally, this means you really need only two commands. etc_working 
and etc_diffs to generate even the working file or its difference from 
the baseline.  they are effectively wrappers for patch and diff but 
hopefully somewhat more user-friendly and infinitely easier to get right 
much of the time.

If you create a user space file system to mediate all this information, 
a simple timestamp comparison of three elements would tell you whether 
or not you need to regenerate data or just hand back the cached copy. 
Performance shouldn't be too hideous.

in a virtual machine environment, one would obviously need to associate 
each diff directory with each machine but would only need a single 
baseline.  This would then allow for a single copy for your system 
binaries and only need to have /var as a start of per virtual machine 
storage

I don't have a good solution for cases where you really want to 
overwrite the baseline files instead of creating a diff.  The best I can 
think of it is if a regenerated working /etc file is the same as what is 
in the /etc directory then there is no baseline change.  If on the other 
hand there is a difference then that's an indication that the baseline 
changed.  It would be a relatively safe bet to pull the potential new 
baseline back into the baseline hierarchy and regenerate the deltas from 
there.  Obviously, if something breaks, it's time to call the human.

One way this can break is if somebody changes to file without pushing 
the difference back into the diff hierarchy.  But hopefully, people 
won't be too careless.

anyway, that's the simplest I can make it.  objections?


---eric

-- 
http://www.salon.com/books/review/2004/12/18/heloise/index.html

The basis of Abelard's philosophy, which he taught to Heloise, was
that logic had to be applied to religion in order to arrive at the
truth.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

  reply	other threads:[~2005-02-22  2:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <31F19452BA8B2042A359D849B74B1BF00C0415@aklexch01.nsp.local>
2005-02-22  1:10 ` organizing virtual machines Eric S. Johansson
2005-02-22  2:45   ` Eric S. Johansson [this message]
2005-02-21 23:05 Tom Hibbert
2005-02-21 23:29 ` Eric S. Johansson
2005-02-22  0:45   ` Tim Freeman
  -- strict thread matches above, loose matches on Subject: below --
2005-02-21 22:53 Eric S. Johansson
2005-02-21 23:19 ` Andrew Theurer
2005-02-21 23:35 ` Anthony Liguori
2005-02-22  0:31   ` Mark Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=421A9CC7.8070102@harvee.org \
    --to=esj@harvee.org \
    --cc=tom@nsp.co.nz \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.