> > The short answer is that I do not consider it part of the header :)
> > the longer is that doing it this way will work with any length or
> > location in the file without requiring the use of MAX_PATH_LEN which
> > from the comments I saw is not always available or even the same
size
>
> This is a valid point (and one that I had forgotten about).  However,
this
> seems to call for a (large) hardcoded constant in the COW code.  It
doesn't
> imply the necessity of removing the filename from the headers.
>
Ok, 2nd version, why not have a variable length file name in a variable
length section, rather than picking a large (not nice) hardcoded (even
worse) constant?
Perhaps I am just gun shy from work where they finally got some 125,000
line FORTRAN subroutines parameterized

> > Example 1 has a array ~8 * #of_sectors always present in the file it
> > does not seem to useful as the point was to keep the file small...
and
> > 1 in 64 is overhead at best, here instead of a bitmap we have a
64bit
> > offset so the bitmap has grown by a factor of 64, but it should be
> > quite fast to find the sectors
>
> This is the most sensible example I know of right now.  It would be
handy
> on hosts that don't have sparse files, which I think is basically
every
> non-Unix out there.
>
Ok, I have been practicing with this one to see how it works, the
simplest way to do a completely different layout, like ISAM, is to just
replace cow.h/open_COW/read_COW/write_COW/close_COW which works easily
but my tests at merging my current COW with ISAM so far have produced
messes, the header will need extra fields and so will devinfo the
index_offset/index_length/current_index (for paging)/index map* can
aliased to cow_offset/cow_length/cow_current/cow_bitmap* but ISAM will
also need the current cow_mode and at least a current data index
otherwise we will end up scanning all the current indexes to find the
last used data sector, and the other examples require more bookkeeping
also, I am still trying to find a good way to generalize this so it does not
make a mess.

The only one of those fields used by the ubd_*.c files is data_length to
get the sector count

Of course we will want to drop the seek to end of file and write zeros  why ISAM on a non-sparse filesystem and then create a max sized file ;)

I did try the f-ops version but it did not seem to gain much over having
case statements in read_COW/write_COW/close_COW it may be faster but it
can make a mess of the code e.g. from ubd_*.c
dev->info->COWfops.read_COW(dev, buf, length, offset) COWfops can be
dropped from that list though, 3 pointers to look up from each devinfo
struct vs a cow_mode var and a case statement looks like nearly a wash.

By the way, I was aiming to have ISAM stack on top of or under the other
COW formats V3->ISAM->V1->V2->backing file for example.

> > Do you have some thoughts on this matter as putting in the hooks for
> > this I would really like some more ideas of what we are aiming for
so
> > that we don't end up wasting programming time/code bloat/executing
> > time on features no-one will use or that won't support what we want,
>
> All I want right now is a cow_format field, which is always
initialized to
> 0.  When someone has a brainstorm for a new format, they can set it to
1
> (or COW_FORMAT_MAX + 1 if there is more than one format by then) and
drop
> their implementation without disturbing how anything currently works.
>
> Obviously, official and permanent assignment of a cow_header value
would be
> done by whoever runs the UML tree (i.e. me).
>
> > Even if it all worked now, the users would need the ability to
choose
> > which type of COW header to create e.g.
>
> True, but that doesn't sound like a tough problem.
>
> Jeff
>
>