Re: [Evms] Questions about portability

[Christoph Hellwig]

On Sun, Nov 12, 2000 at 03:40:01PM -0200, Andrew Clausen wrote:
> yep.  The rules are resizer dependent.  I intend to change the resizer,
> so it duplicates all metadata it changes, so it can do resize the start
> (which isn't important for LVM, but is important for partition tables)

We also agreed on viewing old-style partition tables as legacy.
If we implement the partition table support as part of a LVMS,
it should be easy to do LVM-like resizing even on partition tables.
We only have to take care of having the full resize done before any
other OS tries to access it.

> > > > These filesystem would usually be foreign fses and only occur on one 
> > > > partition
> > > > type, so the hints can be added. (Yes, that's _horribly_ ugly, but less 
> > > > ugly
> > > > than messing up the whole design).
> > >
> > > I don't follow.  How do the hints work?
> > 
> > If you have e.g. the mac partition table format the chance that a hfs(+) fs
> > will be created on it is very big.  If hfs had a strange limitation, the
> > mac partition table resizer would just deal with this strange limitation
> > (for example - just hypothetically it must have a size of 7 times the block
> > size) even if an ext2fs would be created on it.
> 
> Just, the limitations usually must be computed from hard-to-access (and
> resizer-specific) stuff, like "2 * # directory blocks".
>  
> > And btw I don't know about any operating system that has problems with
> > filesystems that are smaller then the underlying partitions.
> 
> DOS/Windows have problems.  In some circumstances, DOS/Windows computes
> information about the file system (like, the size of the FATs, the size
> of
> the file system, etc.) from the size of the partition.  This is VERY
> braindead, I know, but spent a month reverse engineering it, to figure
> out the algorithm.  (It's a VERY brain-damaged algorithm!  It took
> me a day to prove that it never calculated an invalid file system)

Hmm. Last time I installed DOS I had no problems with that - 
but as you have stated above that might be a special case.
(Braindead DOS ...)

> Program interfaces aren't good at giving back information.  It's only
> good when program A calls program B, and A gives information to B,
> but B doesn't give information to A.

True.

> 
> > but the program interface is _much_ more flexible.
> 
> When B needs to give A information (like constraints, etc.), then I
> disagree...

Ok.  That's the case I would use ascii files for - but the resizer
case looks more difficult then others when everything you said is
right.

> > Good.  And when (if) you start doing this frontends you can simply move
> > the code that is only used by one program into this program and make the
> > 'parted' program call them.
> 
> This is not true.  The simple frontends can't communicate the
> constraints.
> (well, you could do somthing like: resize.ext2 --print-constraints, but
> I don't like it!)

Also it is not what I call a really clean design I like this more then
a doit all library.

> Do you feel like becoming more familiar with libparted?  This
> kind of thing might be possible, but I think we need to discuss
> the "guts" a bit more ;-)

Sure - this was just a quick idea...

> > I would really prefer that - fat{12,16,32} _are_ different filesystem,
> > even if they are very similar - you might easily put all the code in
> > one binary if that makes sense - and just make those behave differently
> > when called as resizefs.fat12 and resizefs.fat32
> 
> What happens if another feature gets introduced, that can be enabled
> on fat12/16/32, and affects the partition type?

Actually I'm not really initersted in alls this partition type stuff.
But when the different resizers are actually the same binary it
should be trivial.

> Basically, I'm paranoid
> of idiots doing stupid things (as has happened many times in the
> past...)

Hehe.  

> > > (For example: progams
> > > might get confused when the resizer automagically converts from fat16
> > > to fat32, or whatever)
> > 
> > Right - but this is actually an argument for my standpoint ;)
> 
> Why?  No-one should care about a change from fat16 -> fat32.  If you
> are doing a whole series of operations on a partition, should you
> have to check the file system type every second, to make sure you're
> calling the right function?  (compulsive obsessive disorder! yay!)

Win < 95b and NT < 2000 cares.

> > > But, it's useful to know how much free space you need, before hand,
> > > so you can plan ahead.  (Think: automatic partitioning)
> > 
> > I'm not really sure wether it does matter if the user gets 1024 or
> > 950MB when he specifies 1GB.
> 
> It does, if you're trying to plan some complicated manuevre...
> (which you often need to do... eg: swapping the order of two partitions,
> which might be necessary, say, to get your computer to boot with
> brain-damaged BIOSes, or to move free space together, or something!)

I don't see the point.

Why does it matter wether my 1024MB partition contains 1000MB or 950MB
of actual data in this example?

        Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.