Re: [Evms] Questions about portability

[Christoph Hellwig]

On Sun, Nov 12, 2000 at 10:30:33AM -0200, Andrew Clausen wrote:
> "align" depends on the on-disk file system (not merely the file system
> type).
> For example, if you have an ext2 file system, that starts at sector 63
> (512
> byte unit), and the file system has a block size of 2k, then:
> 
>       new_start = old_start + X * block_size

This _is_ a simple rule, isn't it?

> max_size might be a function of certain properties of the file system,
> like the block size.  (it is rather difficult to grow the block size,
> and if the resizer can't handle it, then this is going to be a factor)
> However, there is no way a front-end can know this, unless it asks
> the resizer.

Right.  What I currently do in lvmadm is just ignoring that fact and let
the LV in it's new, big size and the fs in it's all small.  This is
not the right error recovery, thus my current working tree version resizes
the LV back.

> I disagree.  ext2 doesn't follow simple rules, and I don't think it's
> braindead.  FAT is braindead, and it also doesn't follow simple rules :p

I'm not completly familar with the ext2 size rules, but I've mostly seen
simple rules like X (some not to difficult to retain variable) * blocksize.

You are more familar with the limits, so please tell me the most difficult
to calculate value, that has a real value for resizing ext2.

And of course ext2 is not braindead - also it has a few small designe flaws.


> >  And I don't think we should overdesign the whole system just to
> > support completly braindead filesystems.
> 
> I think we should!  The "overdesigned system" (libparted) is clean
> enough
> for me.  (Heck, people are always trying to make it uglier, but I don't
> let them ;-)

I haven't said that libparted is overdesined - but I would lead to a over-
design if you make it capable of dealing with each messy fs'es strange
limitations.

> I mean, why bother with partitioning, except for compatibility?
> Partitions suck!

I completly agree with you on that!

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

As you said before the old-style partitions tables should be considered
legacy...

> Maybe this is true, but the block size doesn't tell you anything about
> the constraints.  It's the *resizer* that has the constraints.  Only the
> resizer knows what it can and can't do.  My FAT resizer USED to be
> unable
> to shrink the cluster size, or move the start... but now it can.

As we agreed on before moving the start of a fs should not be the fs
resizers job.  Shrinking the cluster size usually (always) happens by
powers of two - so there shouldn't be a real problem either.

And btw I don't know about any operating system that has problems with
filesystems that are smaller then the underlying partitions.

> Comparison between programs and libraries:
> (1) programs and libraries have interfaces

true.

> (2) programs are easy to interface with users, but difficult to
> interface
> with other programs (i.e. difficult to be used by other programs).  When
> I say "difficult", I mean for non-trivial stuff.

I can't agree 100% with you on this.
Yes, the library interface is easier to use in programs in the first time,
but not very much (when the interface to the program is designed right),
but the program interface is _much_ more flexible.  Just for loading
different libraries with the same interface you need to play tricks with
libdl, and loading libraries written in another language or just as shell
script are extremly diffcult if not impossible.

> (3) libraries are easy to interface with programs (i.e. used by other
> programs), but difficult to interface with users

Yes.

> 
> (4) and (5) follow from (2) and (3):
> 
> (4) libraries are easily wrapped by programs, to provide an interface to
> users

True. (wether this is a good design principle or not is another question ...)

> (5) programs are difficult to wrap in a library interface

At least more difficult than a native libarary ...

> However, I think file systems and partitions (and maybe LVMs) have
> Initimate Relationships TM.  Actually, they aren't very intimate (hence,
> libparted is able to be very modular), but they are too intimate to be
> separated completely (unfortunately).

Right.

> I can see that the last point is contentious, but I don't see any
> disadvantages to taking this attitude.
> 
> Here's another interesting option: libparted is structured such that
> it would be very trivial to write resize.ext2 and resize.fat front
> ends.  VERY TRIVIAL (such frontends would be about 30 lines of code).

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.  I don't have any problem with multiple
resizers sharing some common code - as long as they are separate programs,
and one can code another such program without having to use the common code.

> 
> Maybe, we should keep libparted as-is for partition table stuff,
> but use the simpler front ends for LVM.

Yes! - but they could of course share code for e.g. fs resizing by moving
them into programs use by both.

Eg. we could have:

        libresize       (common fs resizing functions)
        libparted       (partition handling stuff)
        liblvm          (lvm handling)

        parted          (frontend for partion handling)
        lvmadm          (frontend for lvm handling)

> 
> However, is this sufficient for conversion between LVM types,
> or converting from file-systems-on-partitions to physical volumes
> containing a logical volume with the old file system?

Yet another frontend just for this purpose Do one thing right ...)
that uses both middle and backends.

> 
> Maybe it is possible...
> 

If you are interested in such a thing I would help out on the LVM part.

> In the case of FAT/Windows: if the file system type and the partition
> type don't match, M$ chokes.  There are 12 different partition types
> (numbers)
> corresponding to different types of FAT partitions.  These correspond to
> various permutations of:
> 
> (1) FAT12/16/32
> (2) the size of the file system (some brain-damage, WRT small file
> systems)
> (3) whether the partition is "hidden"
> (4) whether M$ should use LBA
> 
> (1) and (2) should be determined by the file system code.  You could
> hack around this, by creating different file systems for fat12, fat16
> and fat32, but this seems dubious to me.

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

> (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 ;)

> 
> I think my Mac example was bogus... the partition types need to be
> right,
> but it is merely a function of the file system type.  I'm sure other
> cases will pop-up... Sun disk labels for example, allow partitions
> and the disk label metadata to overlap, so you have to be careful
> about which file system you use, so as not to clobber the disk label.
> (ext2, and new linux-swap don't use the first 1k of the partition)
>

That's really odd (besides the BSDish slice X = whole partition thing ...)
But a offset option for the hints file and the fs resizer could easi

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

> > Why should the generic resize frontend want to know about that?
> 
> Automatic partitioning, and "planning ahead".  (Eg: figuring out how
> you want to rearrange your partitions, and then clicking "go!".  It's
> nicer to know before hand, if it's going to work)

And why does it help the automatic partitioning tool when it knows
wether the filesystem uses sparse supers?  It will get a few megabytes
more if the filesystem has sparse supers enabled - but that shouldn't
really matter (IMHO).

> > One example: For whatever reason I just want to resize the LV, and
> > not mess with the fs.  In my way I would just call the spezific
> > lowlevel tool and be done - no additional overhead.
> > With your lib you could either not do it - or you would have to
> > add another frontend or at least a new command line switch.
> 
> Not true.  You already can do it!
> 
> Parted has a fake "raw" partition table, that has exactly one
> partition that occupies the entire device.  So:

Actually the fake partition table is a cludge that would not be
needed with separate programs...
On the other hand: why do I need a fake partition table to resize
the LV? - Once parted has LVM support this should not be needed and
I doubt it will do anything usefull before that point ;)


>       # parted /dev/hda1 (or the LV device) resize 1 0 [new-size]
> 
> (where 1 = the fake "partition" number, and 0 = the new start)

Isn't that the parted syntax for resizing the partion _and_ the fs?

> libparted is easy to port to... (in fact, both the ext2 and fat
> resizers were originally separate programs)  You could almost write
> a sed script to do it!

But what is when the new resizer is not written in C?

        Christoph

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