Re: Grub and the VSTa filesystem

["Thomas J. Erdos" <erdost@usxchange.net> writes:]

>The problem with this solution is that the same subroutines in the stage2 read
>the menu.lst file , the kernel and the modules the same way. That means the fi
>rst
>(512-320) bytes must be filled with comments for the menu.lst and the kernel a
>nd
>modules have to be modified and recompiled the same way like the stage2 file.
>Again - if I didn't explain it clearly- the same subroutines are used once at
>the
>installation to read in and mark the blocks used by the stage2 file on the
>filesystem and once at startup when the menu.lst, the kernel and the modules
>are
>read into the memory.
>If any questions left unanswered, I hope I can return an answere.

Ah, thanks for clarifying it!

Well, as far as telling stage1 where to get blocks, what you describe is
fine for loading stage2; the boot file will be at offset 0 in the first
block. You'd have to make sure you never used this copy of stage2 for any
other type of filesystem(!).

If stage2's disk I/O is organized so that the filesystem specific code has
to return the block # where the data starts, then yes, it does sound like a
problem for the other files. But I was thrown off a bit by the fact that
the fsys_table[] has a read_func vector, which the common read() routine in
disk_io.c uses. But now I see that there's a NO_BLOCK_FILES which I guess
is avoiding this code path? But I still don't see the block map connection
in the fsys_table... my snapshot's pretty old, maybe that's the problem.

But are you *sure* this is really a problem? I thought from your note on
Saturday that your stage2 was accessing kernel and modules from vstafs?

Anyway, yes, we'll have to pad all of'em the same way. I still maintain
that it'd be screwy, but could be made to work.

OTOH, two changes to vstafs would take care of the problem. The format of
the file header could be changed so the 192 bytes of storage are first,
followed by the inode-type information. This would handle the case of short
files, like a short menu.lst. Second, vstafs could be changed so that files
> 192 bytes would start at offset 0 in the next sector. So larger files
would waste the 192 bytes, but that's only ~38% waste in the worst case, and
drops to less than 5% waste by the time you reach just 4k. vstafs was coded
at a time when disk space efficiency mattered a little bit, but since then
$$$/MB makes this sort of small-scale optimization moot.

This'll require rebuilding any existing vstafs. mkfs should be OK after a
recompile. fsck will need a bit of work. The block allocator in the
filesystem's where most of the action is. It'll also have to handle copying
the "short file" contents upward to the new block when file size starts <=
192 and grows beyond it subsequently.

Andy Valencia
Received on Sun Aug 1 19:45:02 1999