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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19507 invoked from network); 7 Mar 2023 02:05:37 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2023 02:05:37 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 00AD041234; Tue, 7 Mar 2023 12:05:32 +1000 (AEST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by minnie.tuhs.org (Postfix) with ESMTPS id 1D8D841225 for ; Tue, 7 Mar 2023 12:05:26 +1000 (AEST) Received: by mail-wr1-x42e.google.com with SMTP id v16so10773741wrn.0 for ; Mon, 06 Mar 2023 18:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678154724; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qnw+WE1EOsRmYEn9LDkbce3ZVhZiDEac730WJJ4d50g=; b=LbiDn6z9pWczYSQSv2FfdBGEaIudi5sf/SWrHT/Dg/M+BI+2sDXTJ7CPCJl4jF/LE6 Vkb5ezjWud2vhSVvd31/tzZbdELqgOg4sirhCCibbp8IKNw1r84Meijd2dAyCFVc1R3+ PvK1hHkVo95wzoQp5FnJG5H5gxVvBjTcdTNmO5KNQhDMSN5OuGJ6+/AHSvQAViHVkTTR M59jIuSfJ4AhsIXzE2bScN6ZKFwoCM3lH2RLGeZ6JDP8cae6DZUURNLDLvg1Ca4AZgQf 3Sj+H05LxY4fy5qdkJsgo/Sgiw1N+6EpV855kAgWkmar+DtNfS6+/YOKr4ZUo2x0a8nG qlvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678154724; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qnw+WE1EOsRmYEn9LDkbce3ZVhZiDEac730WJJ4d50g=; b=QEZ5GukVsq8AABEx2RrdFnDoRwjSRjuiRqHm07yBttPe1kvLAi/prwxmN+6ildhX4V TLsV8zU5vSIXju+4MapVhYlss3n2hQ1UJUJvBC0aM9MgqiIgSeeNo6aux+Bz4HgMcgfl mjezlE3LnFrkJbEP5EC87TYtI2P8QS0YXsHJeISJwG6sYXboVcTII8BEr08BIeeptbZj qjdwnu4AYbedO7NXVFDmbztgcmpao+6urivW/j6mXp5pTT6MDTyl+s7V670FtW/ZoAbS CKam05qbGcX3B3L0k5etACd563t2doN09W84ljBsbSYt0x1hUiGQXo9n5tr5CPlldRb9 Wk9A== X-Gm-Message-State: AO0yUKUghNyOMrWh3iZN66WxZkqeKEXzRDCBA7Y0iigVsnjH6rWdsx68 hax5kJhSrHdVzwhdhTQt8Bh7jUYIrWOaSD+nIJ1P/cES X-Google-Smtp-Source: AK7set+5LGoYWfBs0wgbP+5Fuy2mEMHnGrrxLVTP4sYVQVDahikvqUTnPzulhz8TSh8SqKVPGuu0uQJhgjtZyHnbuP0= X-Received: by 2002:a5d:408f:0:b0:2c9:b9bf:e239 with SMTP id o15-20020a5d408f000000b002c9b9bfe239mr3585722wrp.2.1678154724049; Mon, 06 Mar 2023 18:05:24 -0800 (PST) MIME-Version: 1.0 References: <20230306081427.4F81A18C083@mercury.lcs.mit.edu> In-Reply-To: From: Kenneth Goodwin Date: Mon, 6 Mar 2023 21:05:13 -0500 Message-ID: To: Jonathan Gray Content-Type: multipart/alternative; boundary="00000000000034898705f645d882" Message-ID-Hash: XZHO3SO6PRJ5YZAMJJIVTL56JD3F3Q2I X-Message-ID-Hash: XZHO3SO6PRJ5YZAMJJIVTL56JD3F3Q2I X-MailFrom: kennethgoodwin56@gmail.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: Noel Chiappa , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix v7 icheck dup problem List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000034898705f645d882 Content-Type: text/plain; charset="UTF-8" Anyone remember PFSCK, aka parallel fsck that fired up multiple parallel fsck instances, one per filesystem and used bidirectional pipes to pass commands from the operator to each individual fsck stream. Cut boot times down quite a bit on healthy systems. I believe the filesystem MOUNT table file on ROOT had fields related to controlling PFSCK behavior I remember hacking it for some reason related to performance, But GOK why...... On Mon, Mar 6, 2023, 3:59 AM Jonathan Gray wrote: > On Mon, Mar 06, 2023 at 03:14:27AM -0500, Noel Chiappa wrote: > > > > I've also been amusing myself trying to figure out who wrote: > > > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c > > According to Guy Harris in > https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/4mcL76lKbmMJ > > 'they had to replace "icheck" and "dcheck" with a new program which > would do most of the dirty work of file system repair for them - > Hal wrote one called "fcheck", which cleaned V6 file systems, and > which appeared in source-code form on the PWB/UNIX 1.0 distribution > tape. Unfortunately, PWB/UNIX 1.0 modified the V6 file system so > that it didn't support "huge" files, and the eighth indirect pointer > pointed directly to a block as the other seven did, so the "fcheck" > there wouldn't fix a vanilla PWB/UNIX file system, but it worked > just fine on a vanilla V6 FS.' > --00000000000034898705f645d882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Anyone remember PFSCK,=C2=A0 aka parallel fsck that fired= up multiple parallel fsck instances, one per filesystem and used bidirecti= onal pipes to pass commands from the operator to each individual fsck strea= m.=C2=A0 Cut boot times down quite a bit on healthy systems.

I believe the filesystem MOUNT table file on= ROOT had fields related to controlling PFSCK behavior=C2=A0

I remember hacking it for some reason re= lated to performance,=C2=A0 But GOK why......

On Mon, Mar 6, 202= 3, 3:59 AM Jonathan Gray <jsg@jsg.id.au= > wrote:
On Mon, Mar 06, 202= 3 at 03:14:27AM -0500, Noel Chiappa wrote:
>
> I've also been amusing myself trying to figure out who wrote:
>
>=C2=A0 =C2=A0http://ana-3.lcs.mit.= edu/~jnc/tech/unix/s1/fcheck.c

According to Guy Harris in
https://groups.google.co= m/g/net.unix/c/-H9x36DMOBQ/m/4mcL76lKbmMJ

'they had to replace "icheck" and "dcheck" with a n= ew program which
would do most of the dirty work of file system repair for them -
Hal wrote one called "fcheck", which cleaned V6 file systems, and=
which appeared in source-code form on the PWB/UNIX 1.0 distribution
tape.=C2=A0 Unfortunately, PWB/UNIX 1.0 modified the V6 file system so
that it didn't support "huge" files, and the eighth indirect = pointer
pointed directly to a block as the other seven did, so the "fcheck&quo= t;
there wouldn't fix a vanilla PWB/UNIX file system, but it worked
just fine on a vanilla V6 FS.'
--00000000000034898705f645d882--