From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1843 invoked from network); 9 Mar 2023 15:13:17 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 9 Mar 2023 15:13:17 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id E9AE6412E6; Fri, 10 Mar 2023 01:13:12 +1000 (AEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by minnie.tuhs.org (Postfix) with ESMTPS id 625F54128A for ; Fri, 10 Mar 2023 01:13:09 +1000 (AEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C7A1E5C0107; Thu, 9 Mar 2023 10:13:08 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 09 Mar 2023 10:13:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ronnatalie.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm3; t= 1678374788; x=1678461188; bh=M3b2gUlPG45YISoRtmnVeBA86Qq4501nX/y y7utDqM8=; b=TXpW94GZlOCx7UnnWm5gVK11bT+QsLfci24zQUgwlWP6FbZRa73 zSyng27gncCNDVMdYk5N2+drMAZxRsgGcnVPBHEadps/7cZxxWD9YimdNw1skFuK Lc6ymB0Rg2Lkc9fb8JGGkJJqRoxR4Ofow9E0YBqicXwa7OCfZC1gOh4sDfgxumr5 b+SkHgbxutgVtKd9VN97RWCWXDq7jDbSaDTyHUTe34Rgsee6fQHdqunn/PB00HKN LLK6viA5uccvtGzPxm+HElnU0I4L7FsT1iEtyAd2O0lOGQXo64Cj5baEmKPLEj0v LTgRogRg3wPbzq2GmRadgI+JIgvJBPx+8/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1678374788; x=1678461188; bh=M 3b2gUlPG45YISoRtmnVeBA86Qq4501nX/yy7utDqM8=; b=OJQIlxuopicylFzer BxaEUx9Np4+PwgWGFGgD0n3wkA3Ae0tfN5KmkCso26yAKrKy1EflVpDsScnF+meK CN5nEvDkJE7o4DlzBzOODBKBmcb27chzt+sIoSgF1TvrLJgTXwxW9eK3Pa64KgCi d7yeqTeQrUafDSE1gO3sMA4aBS5viuvO/pbKhvYyxszINB+tBMgtaSi7TDAKvevT 3/pMk8dicEbXMblYfC4mWJrYi1vpar1mEogAf5KmAChdpzuVu54F0dAm9k7dLAqy CGQbnEhBXDCMrmWVseYuou+wwoRne7Uy2Qi5VDKm8kZxduPIDOwh6lT4v+xoCOHz CXhVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdduiedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufevfffkjghfrhgfgggtsegrtderredtreejnecuhfhrohhmpedftfho nhcupfgrthgrlhhivgdfuceorhhonhesrhhonhhnrghtrghlihgvrdgtohhmqeenucggtf frrghtthgvrhhnpeejheetudfhgfeiheeukeetgeelfedvfeelhfekfedtieegjeejkedu ffejueeltdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehrohhnsehrohhnnhgrthgrlhhivgdrtghomh X-ME-Proxy: Feedback-ID: iaba146ad:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Mar 2023 10:13:08 -0500 (EST) From: "Ron Natalie" To: "Ron Natalie" , "Kenneth Goodwin" , "Noel Chiappa" Date: Thu, 09 Mar 2023 15:13:07 +0000 Message-Id: In-Reply-To: References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> User-Agent: eM_Client/9.2.1608.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBB9ACF004-1B82-4265-94D9-35A2D0F5A25D" Message-ID-Hash: MSP4IWISQJ4R25EJYE37R5F6RT5V5JI5 X-Message-ID-Hash: MSP4IWISQJ4R25EJYE37R5F6RT5V5JI5 X-MailFrom: ron@ronnatalie.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Reply-To: Ron Natalie Subject: [TUHS] Re: 'Huge' file support removed from PWB1 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------=_MBB9ACF004-1B82-4265-94D9-35A2D0F5A25D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable That should read eight blocks in the inode not four in the first=20 sentence (and up to eight later). ------ Original Message ------ >From "Ron Natalie" To "Kenneth Goodwin" ; "Noel Chiappa"=20 Cc "The Eunuchs Hysterical Society" Date 3/9/2023 10:07:17 AM Subject [TUHS] Re: 'Huge' file support removed from PWB1 >In the version 6 file system, If the file was less than 4K, the four=20 >blocks in the inode refer directly to the disk blocks containing the=20 >file data. >After thef ile grows past that, the large bit is set in the inode and=20 >these blocks contain the single indirect blocks, referencing 256 data=20 >blocks each, until you used up seven of these. >The last one was the double indirect block that pointed to other=20 >indirect blocks. The file size was stored in 24 bits, and the block=20 >numbers were 16 bit. > >As Noel points out, PWB uses the same file system as V6 but with the=20 >HUGE (last double indirect) code commented out. I have no idea why and=20 >I never noticed it before. While we used a lot of stuff from the PWB=20 >distribution (notably SCCS) we had no real interest in using the PWB=E2=80= =99s=20 >kernel because our V6 kernel had diverged sharply from the Bell=20 >versions. > >Version 7 came around with a different filesystem layout. File sizes=20 >were 32 bits, and the disk block indexes were 24 bits. The latter was=20 >stored as a series of bytes on the disk but expanded into longs in=20 >memeory. >There was no large bit anymore. The first 8 blocks addresses in the=20 >inode were always single indirect, the next two were single indirect,=20 >and the last one was double indirect. (If my memory serves me right) > >At BRL, we modified our very-hacked V6 kernel to have the ability to=20 >mount either V6 or V7 filesystems. > >We never ran V5, but I think V5 is essentially the V6 file system=20 >without the HUGE support again. > >-Ron --------=_MBB9ACF004-1B82-4265-94D9-35A2D0F5A25D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That should read eight b= locks in the inode not four in the first sentence (and up to eight later).<= /div>

=0A

=0A
=0A
=0A
------ Original Message ------
=0A
From "R= on Natalie" <ron@ronnatalie.com>
=0A= =0A
Cc "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
=0A
Date 3/9/2023 10:07:17 AM
=0A=
Subject [TUHS] Re: 'Huge' file support removed from PWB1

=0A
=0A
In the version 6 file system, If the file was le= ss than 4K, the four blocks in the inode refer directly to the disk blocks= containing the file data.
After thef ile grows past that, the lar= ge bit is set in the inode and these blocks contain the single indirect blo= cks, referencing 256 data blocks each, =C2=A0until you used up seven of the= se.
The last one was the double indirect block that pointed to ot= her indirect blocks. =C2=A0 The file size was stored in 24 bits, and the bl= ock numbers were 16 bit.

As Noel points out, PWB = uses the same file system as V6 but with the HUGE (last double indirect) c= ode commented out. =C2=A0I have no idea why and I never noticed it before. = =C2=A0 While we used a lot of stuff from the PWB distribution (notably SCC= S) we had no real interest in using the PWB=E2=80=99s kernel because our V6 = kernel had diverged sharply from the Bell versions.

=
Version 7 came around with a different filesystem layout. =C2=A0 =C2= =A0File sizes were 32 bits, and the disk block indexes were 24 bits. =C2=A0 = The latter was stored as a series of bytes on the disk but expanded into l= ongs in memeory.
There was no large bit anymore. =C2=A0 The first = 8 blocks addresses in the inode were always single indirect, the next two= were single indirect, and the last one was double indirect. =C2=A0 (If my m= emory serves me right)

At BRL, we modified our v= ery-hacked V6 kernel to have the ability to mount either V6 or V7 filesyste= ms.

We never ran V5, but I think V5 is essential= ly the V6 file system without the HUGE support again. =C2=A0
-Ron
=0A
=0A --------=_MBB9ACF004-1B82-4265-94D9-35A2D0F5A25D--