Re: [Evms] Questions about portability

[Andrew Clausen]

Christoph Hellwig wrote:
> 
> 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.

Yes.

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

What is "LVM-like resizing"?  Do you mean resize.ext2, etc?  (If this
is the case, then I disagree, obviously, hehe)

> We only have to take care of having the full resize done before any
> other OS tries to access it.

Parted does resizing off-line (it's userspace).  Although, we intend
to interface the online resizers too...
 
> 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 ...)

I still haven't figured out what the special conditions are, but when
things go wrong, things go HORRBILY wrong.  (you get a different
root directory cluster / sectors, inconsistent FATs, scandisk
completely obliterates your file system...)

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

Exactly.

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

s/Also/Although/  ?

Well, I certainly think it's good to have both a program AND a library
interface.  (I want to have the do-it-all library, even if it delegates
things out by exec()ing other programs)

Your (only?) arguments in favour of having the do-it-all library calling
other programs (as opposed to the programs calling the do-it-all
library)
is language compatibility issues and "forced" code sharing?

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

Tell me when you're ready ;-)
 
> > > 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.

I can imagine!

> But when the different resizers are actually the same binary it
> should be trivial.

You mean, when the resizers + the partition table code...

Anyway, it isn't trivial, because the code needs to maintainable and
modular,
and needs to have a consistent interface (to be useful).

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

Yeah, you should warn the user about it... but Linux tools shouldn't
care.  BTW, this is another argument for a library.  How does an
all-in-one front-end (eg: a GUI installer, an automatic partitioner,
or whatever) communicate error messages?  What if the user has
multiple ways of resolving an error (eg: retry, ok, cancel, etc.)

One solution would be to read/write to stdin/stdout, etc., but then you
need more conventions on the protocol (i.e. user interface for the
low level tool).  This get's tricky, with i18n issues.

The programs-that-are-a-front-end-to-a-big-library approach doesn't
have this problem.

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

Sometimes, the last 10Mb makes a difference, if you're low on disk
space.  (or, a particular free-space region is small - not necessarily
the whole disk)

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

Yes.

Andrew Clausen