From owner-freebsd-current@freebsd.org Thu Jul 14 05:30:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3705B97736 for ; Thu, 14 Jul 2016 05:30:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74EDC1EB2 for ; Thu, 14 Jul 2016 05:30:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22a.google.com with SMTP id u186so39350010ita.0 for ; Wed, 13 Jul 2016 22:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hfYp8+1/aBYj8aDnr15OnutDEGo6Bnyg/Q9UApPl6Gw=; b=XGfINdLwaM+br+lCMnhH2dA9sCqadyIuSE0LVZpKpIk4a3F7QIGOvbnukTFMJw9T6u 6D/v4bUwmIGICjBFH4vHcQ8uVj26QR0TsMfnvjb7v+QPNZcLwXL27mOlkr4DWb1cBMKs jNlpIU22D+qPjfscUYOLX/BsCj6HEQMVHxD8uk6BDMS6/ZIKqWYDjfmtFLSMQHmGDH3T goJ7hBo/R4pMfxEY9xn+n/pA5nrfI6WhD1uxMY95ayPBcxno6bcNoBge94/yRoJI50M+ cR7h6W+LGzj8hcOGAnl4HD+jQMmnrRHK6+5iyA2HobAXNmRg5xcqJclxQBsNTsSVHIN5 8cDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hfYp8+1/aBYj8aDnr15OnutDEGo6Bnyg/Q9UApPl6Gw=; b=cKAua/jFkS6IpDCXIa3UaPFN/2AGX0Cg2YoLM9kgJg7N/jVEoL6blyG2vZnw8vHO0j oSJ+b5w6bWpOKEB/d2VGVfWFTCVOY8YVI7W8ebi22E52+mCrxVjtgjF3OAI8ITC98lvK 6fLt6jsbm5FezpjCiOrP00bMDHtbiAoOU7Y6zSiQOKnpfniDLZyvjHUsNG/eNxLrZ9JJ EcFkUas7Cd+jn97hlsOue6a2qjkMxVnBkkF9hobAn/yqUVrzAaC1ebP6oBf5b5i6woFa RdNYScu2eGrjgB8QskWqb7MUW2e1SJ2QcPn93zJB4Y/61nDXyqrV7/oQobreXvTStqKW 8K1g== X-Gm-Message-State: ALyK8tLBWVN60WVpGVSawZOrCMKeeGHhgtcQ9IZfAgX5Yr1nmdkp/yhHIyEAO54VGPZKo1d/1mh7557FEsd/MypI X-Received: by 10.36.188.65 with SMTP id n62mr26823220ite.61.1468474234777; Wed, 13 Jul 2016 22:30:34 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Wed, 13 Jul 2016 22:30:33 -0700 (PDT) In-Reply-To: <20160713221253.GU1520@FreeBSD.org> References: <20160713221253.GU1520@FreeBSD.org> From: Maxim Sobolev Date: Wed, 13 Jul 2016 22:30:33 -0700 X-Google-Sender-Auth: SZbx5tpFazSV4mIDTg9FqN3uv2M Message-ID: Subject: Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r To: Glen Barber Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 05:30:35 -0000 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 On Wed, Jul 13, 2016 at 3:12 PM, Glen Barber 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 > >