From owner-svn-src-head@FreeBSD.ORG Mon Oct 1 18:38:07 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D44B2106568C; Mon, 1 Oct 2012 18:38:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3118FC12; Mon, 1 Oct 2012 18:38:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F16CDB91E; Mon, 1 Oct 2012 14:38:06 -0400 (EDT) From: John Baldwin To: "Andrey V. Elsukov" Date: Mon, 1 Oct 2012 14:07:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209291647.q8TGlvbr058837@svn.freebsd.org> <201210010753.59816.jhb@freebsd.org> <5069B53F.5040004@yandex.ru> In-Reply-To: <5069B53F.5040004@yandex.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201210011407.41767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 01 Oct 2012 14:38:07 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r241053 - in head/sys/boot: common i386/libi386 uboot/lib userboot/userboot X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:38:08 -0000 On Monday, October 01, 2012 11:22:39 am Andrey V. Elsukov wrote: > On 01.10.2012 15:53, John Baldwin wrote: > >> Introduce new cache layer to resolve this problem. It is independent > >> and doesn't need initialization like bcache, and will work by default > >> for all loaders which use the new DISK API. A successful disk_open() > >> call to each new disk or partition produces new entry in the cache. > >> Even more, when disk was already open, now opening of any nested > >> partitions does not require reading top level partition table. > >> So, if without this cache, partition table metadata was read around > >> 20-50 times during boot, now it reads only once. This affects the booting > >> from GPT and MBR from the UFS. > > > > ...and removes support for removable media like floppies. That may be the > > proper thing to do at this stage (though I think that affects PC98 still > > perhaps?) However, removing suppot for removable media should be an > > intentional decision, not a side effect. The bcache was simplistic > > precisely to support floppies. > > Hi, John, > > I think it shouldn't affect floppies support. I'm unable to test this, > and I don't remember exactly, but floppies don't have partition tables, > or just have simple MBR. So, when access to the floppy will be > performed first time, the following cache entry will be created > "disk0: -> some_offset", probably an offset will be zero. And when you > change the floppy this offset still remain the same. There is a lot of > other places in the libstand, where similar behavior still remain (i > mean, one operation initiates several unneeded reads): The floppies used in BSD either have BSD labels or are a DOS floppy with no partition table. > * Each open() call initiates read file system metadata. > > * We have the support of different file systems. Some of those are real > file systems, other aren't - gzip, bzip, split. During boot loader tries > to open several files, which don't exists by default. Each this attempt > initiates reading of metadata of each file system several times. Why? > When we do first read we can determine that we have UFS on this media, > why do we trying search msdos or ext2fs here? Think about removable media. If you have replaced the media (such as a floppy), then what was once UFS may now be FAT16. > Ok, when we fail to open this file on the all of file systems, we are > going to try them again with ".gz" extension... Yes, the current code is not very optimal. The focus on it to date has been to make sure it works. It is only used for bootstrapping, not once the main system is up and running, so at least in the past performance has been less important than correctness. One could perhaps differentiate removable vs non-removable media (and allow more caching on non-removable media) so long as one distinguish a USB stick so as to mark it as removable media. (Either that or we say that we no longer support swapping removable media during the boot process.) -- John Baldwin