About this list Date view Thread view Subject view Author view Attachment view

From: Paul Sladen (vserver_at_paul.sladen.org)
Date: Fri 01 Nov 2002 - 15:50:11 GMT


On 31 Oct 2002, Andreas Kostyrka wrote:
> Am Don, 2002-10-31 um 09.32 schrieb Matt Ayres:

> How does using LVM expose anything more than using normal /dev/[sh]d?
> devices? [...]
> So this does not make sense to me? How does putting the vservers into
> LVM devices expose the raw data to a vserver root?

It doesn't expose any *more*. (It is exactly the same as mounting
`/dev/sda5' and placing a work devnode in the vserver).

The kernel assumes that because it is the only one directly writing to
various filesystems on disk; that it is going to do so in a consistent way,
and (because the fsck was done on startup to correct any errors present), it
can now be confident in the state when it reading it from disk.

> > I've not looked into the validity of this, but it seems reasonable.
> Nope, it does not seem reasonable.

If you are the only person who uses your desk at work, you can be
reasonably sure that it's going to as you left it.

So, without looking, you can happily open top draw and pull out a
rubberband, or paper clip without having to check whether there are any baby
crocodiles in there waiting to bite off your fingers.

On the other hand... because you've just given me access to the raw contents
of your desk, how can you be sure that I haven't placed any crocodiles in
there with the explicit intention of incapacitating you.

> Only drawback of using LVM for vservers is, that you cannot unify the
> servers, ...

For good impressions of real partitioning, this is a good thing, not bad.

        -Paul

PS. Oh, did I mention that with direct device access I can create whatever
/dev/ devices I want?

-- 
Nottingham, GB


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:43 GMT by hypermail 2.1.3