From owner-freebsd-questions@FreeBSD.ORG Mon Oct 8 16:23:20 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AA281065744 for ; Mon, 8 Oct 2012 16:23:17 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 793F98FC0C for ; Mon, 8 Oct 2012 16:23:16 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q98GMqLH029828; Mon, 8 Oct 2012 11:22:52 -0500 (CDT) Date: Mon, 8 Oct 2012 11:22:52 -0500 (CDT) From: Robert Bonomi Message-Id: <201210081622.q98GMqLH029828@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, lbc@bnrlabs.com In-Reply-To: <5072EDCC.4040303@bnrlabs.com> Cc: Subject: Re: what is an "in-core" disklabel ? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:23:20 -0000 > Date: Mon, 08 Oct 2012 17:14:20 +0200 > From: "Lucas B. Cohen" > Subject: what is an "in-core" disklabel ? > > Hi, > > I've seen the term "in-core" a couple times while reading up about BSD > disk labels. Does it refer to data that is cached in kernel memory ? > > Context examples : > > - fdisk(8) outputs "parameters extracted from in-core disklabel" > > - bsdlabel(8)'s manual explains that the -n (dry run) parameter "does > not install the new label either in-core or on-disk". 'cached' is not _technically_ exactly accurate, but you have the concept basically correct. The O/S reads the label information and stores it in an internal data structure, Then, when it needs to use that data (frequently!:) it uses the values in that internal structure, rather than attempting to re-read from the disk, itself. Technically, it's _not_ "cached" -- cached data is used to short-circuit a 'read' attempt, using an in-memory block of byte instead of an actual disk transfer. The -effect- is similar, but there are *important* differences. 'Cache' data is integrated with I/O operations, and a _write_ to the place where the data was read from -invalidates- the cached data, whereupon, the next read attempt will *not* be short-circuited, and the actual on-disk data will be returned. In the case of the disk label, it is read (once) into the internal data structure, and only the internal data is used after that. A userland app can change the 'on disk' data -- or trash it completely -- and what the O/S "thinks" the label info is will NOT be affected by that change to the 'on disk' data. The warnings you see in the documentation, are reminders that the O/S's 'internal' data and the 'on disk' data are *NOT* necessarily the same. That looking at _one_ source of that data does *not* guarantee that what you see =there= is the same as what is in the other place.