On Sun, Feb 5, 2012 at 4:07 PM, C. Masloch <c...@bttr-software.de> wrote:
> Hello devs, especially Jeremy,
> I reviewed your recent commit 1702 to build 2041 regarding sector sizes
> larger than 512. Here are my thoughts and suggestions.
> - First, dsk.h defines the maximum sector size (MAX_SEC_SIZE) as 2048 (as
> the commit comment says) while the relevant LoL entry (maxsecsize) in
> kernel.asm is initialised to 4096.

Yes - this is simply for testing purposes; I plan to default both to
512.  I would prefer both set from the same define to ensure they stay
in sync - I am aware they are different, I am tracking down how to fix
support for larger than 2KB sectors and MAX_SEC_SIZE will be set to
4096 to test or possibly eliminated in favor of using only maxsecsize.

> - Second, maxsecsize is erroneously used once in dsk.c while everything
> else uses the value from the dsk.h definition.

maxsecsize is what should be used, I intend for maxsecsize to be
dynamically adjusted same as MSDOS.  That currently is not done.
Initially hard coded sizes are being used, but I would like to work
towards using the dynamic value for allocations.

> - Third, if I'm not entirely mistaken, the patch makes all buffers grow to
> 2048 bytes, even in the absence of any block devices with large sectors.
> This will unnecessarily waste memory on most systems.

yes, buffers are allocated using size of max sector size so will waste
lots of memory if > 512 byte sectors are used.  I will be committing
updates to ensure max sector size defaults to 512 so as to avoid waste
of space.

> MS-DOS initializes its 'maxsecsize' to 512 and will increase it (along
> with each buffer's size) during CONFIG processing whenever a block device
> with larger sectors is registered. (As far as I know/deduced, this works
> up to a sector size of 8192 bytes.) This way, if the need for large
> buffers wasn't apparent during CONFIG, they will stay smaller.

and I hope to implement similar for the FreeDOS kernel

> This scheme could obviously be extended by additional tools/interfaces to
> increase the buffer size later on, and a CONFIG option to artificially
> increase it in anticipation of a post-CONFIG requirement.

agreed, a config option to allow manually specifying a larger value
than needed at boot time - should buffers be extended to
BUFFERS=COUNT#,READAHEAD#,SECTORSIZE# or would it be better to add a
whole new command MAXSECSIZE=SECTORSIZE#  ?  (the latter seems simpler
so the one I will plan on for now).

> - Fourth, apart from the other points, I fail to see why you should not be
> able to simply increase MAX_SEC_SIZE to 8192. 4096 is definitely in need
> as evidenced by the list's requests for precisely that size.

agreed, though currently any value > 3KB causes memory corruption if
too many buffers are specified (I have successfully gotten 4KB sectors
to finish booting by changing buffers=2).

> - Fifth, I think MS-DOS supports sector sizes below 512 too. If you were
> to look into that, I believe it wouldn't be too hard to implement. Due to
> the filesystem (size of directory entries), 32 bytes is the absolute
> minimum.
> I believe all sizes below 512 will require a slight change to the BPB
> loading (What to do about the sector end signature location?) while you
> might have to get creative for the very small sizes, because a full BPB
> would not fit. I'd suggest just expecting the BPB to stretch several
> sectors then; the filesystem already allows reserved sectors to be
> properly implemented using the BPB.

I don't see us using max sector size < 512, but using tdsk with
smaller than 512 sector size does seem to work - though at this time I
don't see me researching  if it correctly works or merely happens to
work on my test setup.

> Regards,
> C. Masloch

Thank you for reviewing the patches.  I currently have tracked down
part of my issue to allocation problems if buffers is too large, but
still working on relearning the init time segment relocations and
order to determine a proper fix for buffer allocations.  It would help
if printf worked correctly in all the init code...


Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Freedos-kernel mailing list

Reply via email to