lkml.org 
[lkml]   [1998]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: LVM / Filesystems / High availability
   Date: 	Mon, 22 Jun 1998 18:26:30 -0600 (MDT)
From: Colin Plumb <colin@nyx.net>

I have a partial understanding of how an LVM works, but I could use more.
If anyone knows any detailed descriptions of an implementation on the
web, I'd be interested.

Building a fake device out of bits of real devices is not that complicated.
The RAID code does this and the file system doesn't even need to know about
it.

Different people use LVM in different ways. Some people think of LVM as
something you can do by creating a fake block device "out of bits of
real devices", as you put it. Other people put stronger requirements on
"LVM", which effectively requires that the filesystem be involved at a
very real level.

What gets tricky, to my mind, is removing blocks from the *middle* of
a virtual device. Say that you have three disks that are
concatenated to make a file system, of 2, 1 and 2 GB, respectively.
You want to upgrade, so you do a little bit of housecleaning to get
the file system down to < 4 GB, remove the 1 GB disk, and install a
nice new 8G disk in its place.

We now have a virtual memory fragmentation problem. The file system
has (let us assume) a 32-bit address space of block numbers. These
are virtual addresses, which get mapped to physical addresses on
various devices. Each disk added and removed can be seen as an
allocation and free of virtual address space. We need to keep track of
this and the mappings to devices some how.

There is no particular reason why a device has to map to contiguous
blocks in the virtual address space, but to do otherwise will mess up
the file system's block allocation strategies unless they are extended
to understand the logical-to-physical mapping.

Of course, changing a virtual address for some data once it has been
allocated is *very* expensice and, in fact, fraught with race conditions,
so you don't want to have to do that.

I'm just wondering, how do existing implementations deal with this?

In general, existing implementations either don't deal at all, or they
deal by having the filesystem use a structured block address scheme one
way or another. For example, when we add extent maps to ext2, I plan to
leave room for so that block numbers can be 8 bytes long, instead of 4
bytes. The low 4 bytes will be the original block address, as before.
The next 2 bytes will eventually contain the LVM index, where each
additional logical volume will contain its own superblock and UUID, plus
an indication that this is a subsidiary volume (and the UUID of the
master volume). The master volume is the first volume created in the
LVM set, and it will contain a table mapping LVM index numbers to UUIDs'
of each subsidary volume. (The last 2 bytes of the 8 byte address will
be reserved for future expansion.)

This makes it easy to remove a LVM in the middle of the filesystem; you
simply move the blocks of that particular LVM to other LVM's, and then
remove the LVM from the master disk's LVM table.

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.321 / U:1.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site