Fellow Bering-users,
in case you will never use a floppy based Bering
system, please stop reading now in order not to waste
your time. Possibly, you could record for future use
that a maniac wrote something and you will be able to
find it in the list archive, should need arise. The
end conclusion is that 1730 kB payload can reliably
be achieved on one floppy.
I will have some words to say on floppies of size
1743k and 1760k. The intention was to see how much
space I can extract.
My testing method was to create a msdos/mtools file
system, populate it with Bering-uClibc 3.0 beta3 and
activate it with syslinux. Then test the image using
vmplayer and two 586-based computers from 1997 and
1998, respectively. Unfortunately I could not match
the discarded harddisk in my possession where
Windows 95 or 98 still is present with its original
computer, so Microsoft complained at every boot up.
You all know that song of complaint. Therefore I do
not know whether Windows can manipulate the images.
The bad news comes first. I could write the 1760k
image with correct md5-verification, but neither
computer would boot off the floppy diskett. In
contrast vmplayer did boot all the way until the
code in linuxrc started to give strange messages
and finally stating "kernal panic" at line 277 of
linuxrc, caused by the incapability of mounting
something relating to the minix initrd image.
This idea of using 1760k seems like a dead end!
Size 1743k is a pure success and well worth of
putting to use. Since my first posting a week ago
on these floppy stretching ideas, I grew suspicious
of "mkdosfs" since I cannot control its full behav-
iour. Therefore I switched to mformat/mtools. (That
is the way Debian constructs raw boot floppy images
with syslinux on them.)
I tested three different builds of file systems with
none, one, two extra build parameters on top of
the /dev/fdnu1743 mandatory parameters. All lead to
fully functional booting discs for Bering-uClibc,
with vmplayer as well as both computers. It was even
possible to leave /dev/fd0u1680 standing in leaf.cfg
and syslinux.cfg, without any effect on booting. The
only harmless event was that one of the computers
had reading errors when verifying the fdformat of
/dev/fd0u1743 and also at the end of writing the
image file to /dev/fd0u1743 using dd. The written
floppy was still fully functional for booting.
The other computer did no trickery whatsoever.
The standard form of 1743k floppies produces
msdos compatible file systems with
3431 clusters of 512 bytes, i.e, 1715.7kB.
Restriction the root directory to 48 files (3 sectors)
gives us
3460 clusters of 512 bytes, i.e. 1730 kB.
Finally, 48 root files and each FAT using 6 sectors
yields a minimal gain:
1735 clusters of 1024 bytes, making 1735 kB.
A priori, it is not clear if this gain of 5 kB
really is useful, since the larger cluster size
is more wastful and there is no tail packing available
as in the Reiser file system.
My conclusion of this fairly obfuscated investigation
is that one can reliably reach 1730 kB for a floppy
carrying Bering-uClibc. The additional gain of 5kB
is irrelevant as long as the lrp-packages are not
optimized for use of storage space (replacing
whitespace with tabs in configuration files).
Still here? I told you all to stop reading while
you had the chance and that I would become a
nuicance. Right?
Regards
Mats E Andersson
_________________________________________________________
Flyger tiden iväg? Fånga dagen med Yahoo! Mails inbyggda
kalender. Dessutom 250 MB gratis, virusscanning och antispam. Få den på:
http://se.mail.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
