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

[Andrew Clausen]

Andreas Dilger wrote:
> 
> Andrew writes:
> > For FAT (on Windows), the size of the partition must equal
> > the size of the file system.  Otherwise, Windows will silently
> > destroy your file system.
> 
> Yuk, I knew they would break it somehow.

Hehehe.  General reverse engineering strategy:
* try the most obvious naïve method of solving the problem
* figure out what bugs they put in the naïve design

> > Why is major/minor an issue?  Who uses major/minor?
> 
> Well, LILO for instance.  The LVM user tools (not that they are
> relevant to this issue).  Basically, anything that wants to
> check a block device belonging to a given class (i.e. SCSI, IDE, etc).

Don't you think major/minor is a bad interface for this?
/me thinks ioctls are better

> They are used as timestamps between PVs to determine which VGDAs can make
> up the quorum.  For a VG with a single PV, there are two VGDA copies on
> that PV, so the timestamp is used to determine which one is complete/newer.
> For a multi-PV VG, there are at least 3 VGDA copies, so we use the timestamp
> to determine which are identical, and we need a quorum of identical VGDA
> copies to determine what represents the state of the VG.  If we have half
> of the PVs with one VGDA, and half with a different VGDA, then the timestamp
> is used (like in the single PV case) to determine which is newer.

Nice :-)

> 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?

> > So, I still think we need resize-the-start, for metadata
> > at the front.
> 
> 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.

Sorry: s/need/need for "plugins" that store O(volume-size) metadata
at the front/

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!

> Given that you previously said that Windows will corrupt an MSDOS
> filesystem which is not the same size as the device, I think the
> only way to reasonably support a wide range of situations is to have
> either compatibility volumes which we don't touch, or to (hopefully
> transparently) migrate the data into an LVM-style virtual volume which
> allows us to move the data around easily without touching the contents.

Well, I think the Windows problem is a bit of red herring,
because it only obliterates FAT partitions that have a
partition type ID of (insert about 20 numbers here), indicating
that it is a FAT partition.

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.

Andrew Clausen