> On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber <g...@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 <sobo...@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.
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!
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"