Re: [Evms] EVMS Conference call (04/10/01) minutes

[Andreas Dilger]

Andrew writes:
> > Correct.  For (any) LVM, the LV contents are always logically contiguous
> > no matter how they are layed out on disk.  You never have to touch
> > the contents, regardless of what you are doing to the actual on-disk
> > layout.
> 
> Is the granularity usually the size of a physical extent?

Yes.

> > I think this will be difficult (if not impossible) to do in a general
> > way.  There are lots of different filesystems, and databases and such
> > often use raw device access, so there is no hope to "resize the start"
> > with such beasts.
> 
> I think it's basically possible to resize-the-start on anything
> (just not online!).  Reason: databases and file systems and such
> need to be able to dynamically grow and shrink, and have indexes
> and such.  (I actually don't know much about db's, but I'm
> sure it must be a basic property of them!)
> 
> That said, writing a resizer is a lot of work, and it will be a long
> time before we have resizers for everything!

My opinion on this is that it will hopefully be possible to migrate from
a "compatibility" volume to a full EVMS native volume in some transparent
way (transparent meaning while device is mounted/in use).  This requirement
needs to exist for EVMS volumes to be useful in the enterprise anyways, so
making it a "hack" for migrating compatibility volumes should not be much
more work.

By "hack for migrating", I mean that you will do something akin to this
(sorry for not following the new terminology, I will talk in terms of LVM):
- add a new "PE" equivalent unit to the "compatibility volume" as a mirror
  of the first PE worth of user data.  Sync up this mirror PE by copying
  the first PE worth of user data from start of compatibility volume to
  new PE.  Writes in progress should be done to both mirror copies.
- reduce the size of the compatibility volume by 1 PE length from the start
  of the volume (in memory only)
- write a native EVMS header at the start of the compatibility volume which
  indicates the new start of the now full-EVMS volume
- repeat as necessary (if desired) to move the rest of the old volume to EVMS.

Once you have virtually contiguous volumes, you never need resize-the-start
because instead of resizing, you simply move the start to another location
if you really need to.

> In reality, we don't have a FAT partition, we have a partition,
> with some feature/personality + a FAT file system.  We shouldn't
> expect it to be backward compatible, when we introduce features.

I agree, but when we start to add features, one of the features should be
the ability to migrate parts of volumes (bad-block relocation, disk removal,
performance tuning, etc).  This is one of the reasons why breaking volumes
into PE chunks is attractive, IMHO.

Cheers, Andreas
-- 
Andreas Dilger                               TurboLabs filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/