Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

> On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber <gjb_at_freebsd.org> wrote:
> 
> > Just replying to the first email in the thread, since it's a general
> > reply, and only related to the original topic at hand, and only for
> > informative purposes at this point.
> >
> > On Mon, Jul 11, 2016 at 11:01:51PM +0200, Ronald Klop wrote:
> > > Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
> > > Windows 10. It complained that the ISO is too big for my 700 MB CD-r.
> > >
> >
> > I have *something* semi-working, with a huge amount of help from Maxim
> > in private email.  There is still a nit or two to fix, I'm running into
> > them as I rebuild the ISO after fixing the prior issue.  But, right now,
> > I can get the ISO to boot enough to get to a shell (the "init failed due
> > to inability to mount '/'" shell, but it is still a shell).  :)
> >
> > Once I get what I have now into a state where it's somewhat committable,
> > I'm going to create a project branch to sand off the edges, instead of
> > doing it directly in head, since there might be some edge cases for
> > non-x86 architectures.  (But some other architectures do not have the
> > "too big" problem.)
> >
> > Once that is merged, I fully intend to merge this to stable/11, provided
> > there is no major fallout.  With what I have now, disc1.iso is 630M, and
> > the disc1.iso.xz is 554M.  I'll upload an image somewhere public for
> > people to test 11.0-BETA1 on hardware, KVM, etc.  One thing to note,
> > though, there appears to be a significantly non-zero speed decrease,
> > though this may just be because my CD-ROM is USB-based.  When I have the
> > ready-to-commit result, I'll test it on a machine with an internal CD
> > drive.
> >
> > Glen
> >
> >
On Wed, 13 Jul 2016 22:30:33 -0700 Maxim Sobolev <sobomax_at_freebsd.org> wrote

> Hi Glen, nice update, glad being of some help. The slowdown may be related
> to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
> typically, even if only single block from that cluster is requested. I
> imagine it might impact rc.d, which is essentially bunch of small(ish)
> shell scripts and I would not be surprised if their blocks would be
> scattered all over the place. There is some very basic caching in the
> geom_uzip module, but it is only one cluster deep. What might help if you
> still have some room on the CD is to decrease cluster size (-s parameter of
> mkuzip), to something like 32k or even 16k. That would make compression
> less effective, but would reduce the I/O bandwidth waste, which could also
> be important for the KVM setups. I might also look into making a bigger
> cache, as RAM is getting cheaper and more abundant every day. Another
> approach would be to make several "partitions", segregating for example
> /etc stuff so it's all tighly packed together and you can also use smaller
> cluster size for /etc and bigger for the rest. In any case, keep me posted
> with your findings.
> 
> -Max
> 
It's CPU, and IO bound mostly, and it's going to prove painful for some
with lesser powered hardware. But better than than the alternative. Right?

Hey, Glen. Just a nod, for taking the time to do this!

--Chris