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,MIME_QP_LONG_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1177 invoked from network); 9 Mar 2023 15:07:29 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 9 Mar 2023 15:07:29 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DDA2A412A0; Fri, 10 Mar 2023 01:07:24 +1000 (AEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by minnie.tuhs.org (Postfix) with ESMTPS id 35D924128A for ; Fri, 10 Mar 2023 01:07:20 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 478CA5C018C; Thu, 9 Mar 2023 10:07:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 09 Mar 2023 10:07:18 -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= 1678374438; x=1678460838; bh=+4c9ABZXymcdw7AS9kAXFOBn6k2oh6soEO0 qMSXJsnc=; b=HrUx0NkBz1p+gtoXTvJeDaIWvmnziOrLL99B5p94xCFtUq2KNNv 3mx6iC4+P9EED/nspynvv1LejsulWIyVUHW9VkigmOpSw0QZK1sy8+K129Y0uWFi LNI/oa3j1N4TyLFjGAf74JeIvJg8kLF5j0Kz//ZHyroe/3/4y4gETxg+IKnWJnqM Deh1DjtmspPTNiJPCwA3+/+RT7w4syaFcgGDPyOGL9ATsNB5Aynjhep06A2rECMI C05UNcKNlcA+yIqK6YB2ufGLum1K3x51eBNU0AwRKdCkR/fN2g/dpT7D4/FBzJ6g FI8cNiOrkWX0MaOUMgcKERpMkj1LhQypEew== 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=1678374438; x=1678460838; bh=+ 4c9ABZXymcdw7AS9kAXFOBn6k2oh6soEO0qMSXJsnc=; b=pnqIhhn7cQsUrTWLB 6ouyOLogc9yDtymH+knl7bd8HApQs8+mcGu0Jb+/jYlT7DugE1KcqL2vk3w4MhDW eiGjs+BiLvZBZ1zGwZjDTh2yZvwD0UHkVquCd1dLq9bdKHFkSWclweIBzFjfZxBq yCjUWj8EEC+1Z5hkufkQ8d+0dRqwK9gfAWmqV0VzPDRtlVG+3yvDS4F2HMYXsPR4 TQAXcxlHJ3HVVu3wCnXGuyc9CIkNouTMoqBh9sUaspOQZ0apFApiMklmU4gjjHmJ LjdpKaADfpkrkXZtNAXzBNOb+QuSUVJm5/RBl7+KDv4luEtKa68973llm7sQtpRw hmRFQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdduiedgjeduucetufdoteggodetrfdotf 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:07:17 -0500 (EST) From: "Ron Natalie" To: "Kenneth Goodwin" , "Noel Chiappa" Date: Thu, 09 Mar 2023 15:07:17 +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="------=_MB59B85585-165C-4253-9E13-D33DD35AFD62" Message-ID-Hash: THC2OCSWG6EG26WR3RVGG274QO7JQNIS X-Message-ID-Hash: THC2OCSWG6EG26WR3RVGG274QO7JQNIS 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: --------=_MB59B85585-165C-4253-9E13-D33DD35AFD62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 --------=_MB59B85585-165C-4253-9E13-D33DD35AFD62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div>In the version 6 file system, If the file was less than 4K, the four bl= ocks in the inode refer directly to the disk blocks containing the file dat= a.
After thef ile grows past that, the large bit is set in the in= ode and these blocks contain the single indirect blocks, referencing 256 da= ta blocks each, =C2=A0until you used up seven of these.
The last= one was the double indirect block that pointed to other indirect blocks.= =C2=A0 The file size was stored in 24 bits, and the block numbers were 16 bit= .

As Noel points out, PWB uses the same file sys= tem as V6 but with the HUGE (last double indirect) code 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 SCCS) we had no real inter= est in using the PWB=E2=80=99s kernel because our V6 kernel had diverged sh= arply from the Bell versions.

Version 7 came aro= und with a different filesystem layout. =C2=A0 =C2=A0File sizes were 32 bit= s, 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 longs in memeory.
There was no large bit anymore. =C2=A0 The first 8 blocks addresses in th= e inode were always single indirect, the next two were single indirect, and = the last one was double indirect. =C2=A0 (If my memory serves me right)

At BRL, we modified our very-hacked V6 kernel to h= ave the ability to mount either V6 or V7 filesystems.

We never ran V5, but I think V5 is essentially the V6 file system wit= hout the HUGE support again. =C2=A0

-Ron
= =0A --------=_MB59B85585-165C-4253-9E13-D33DD35AFD62--