From owner-freebsd-arch Sun Oct 22 8:19: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 0BED037B4CF for ; Sun, 22 Oct 2000 08:19:05 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA04881; Sun, 22 Oct 2000 08:19:02 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda04879; Sun Oct 22 08:18:43 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.0/8.9.1) id e9MFIgK18827; Sun, 22 Oct 2000 08:18:42 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdC18825; Sun Oct 22 08:18:31 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id e9MFIUX53822; Sun, 22 Oct 2000 08:18:30 -0700 (PDT) Message-Id: <200010221518.e9MFIUX53822@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdz53818; Sun Oct 22 08:18:03 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Ideas concerning fsck In-reply-to: Your message of "22 Oct 2000 01:42:50 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Oct 2000 08:18:02 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav = writes: > What do people think about dispensing with the Pass# argument in fstab > and instead using the following algorithm for 'fsck -p': > = > 1) if the device does not begin with a slash, assume this is a > pseudo-filesystem, and skip this entry. > = > 2) if the mountpoint is "none", skip this entry. > = > 3) if the fs type is known, run the appropriate command (which can > be null, e.g. for cd9660), and skip to the next entry. > = > 4) if the fs type is unknown, but fsck_${fstype} exists, run it and > skip to the next entry. > = > 5) print a big fat "Unknown file system type" warning and skip to > the next entry. > = > As for which order to fsck file systems in, do / first, and everything > else in parallell afterwards (possibly with additional logic to try to > identify file systems that are on the same device and fsck them > sequentially to avoid thrashing) The additional logic to identify filesystems that are on the same = device would have to be a mandatory requirement, as fsck already avoids = thrashing by fscking filesystems on the same device serially. For that = matter specifying pass# 1 for / and 2 for all others already does what = you suggest -- except for the additional error checking. > = > I'm willing to write the code if people think it's a good idea. Other than making the fsck process more windows-like by reducing the = control the admin would have over the fsck process and giving people = with little or no UNIX experience an easier time managing FreeBSD = systems, I fail to see the benefit of this change -- the additional = error checking excepted. I would be in favour of the above logic you specify within the bounds = of a pass#. Then to implement the logic you've outlined above all one = would need to do is specify pass# 1 for each filesystem. Ideally to hasten boot, we could modify fsck to only execute pass# X = and have mount only mount filesystems of pass# X. This could be used = for example as follows: 1. fsck pass# 1 2. mount all filesystems of pass# 1. 3. fsck pass# 2 in background. 4. Bring up system services that don't need files in pass# 2 (while = fsck pass# 2 runs in the background). 5. Wait for fsck pass# 2 to complete. 6. mount all filesystems of pass# 2. 7. Bring up the rest of the services that do require pass# 2. While system services that don't need filesystems listed as pass# 2 are = being initiated, we are also fscking less critical filesystems in = parallel, hopefully reducing the time it requires to boot. This of course would require fsck and mount argument changes and use of = some kind of locking mechanism. To argue against my own arguments above, what I suggest can also be = creatively implemented using noauto and rc.local. Either way, taking = control away from the admin of a critical part of system initiation = doesn't sit right with me. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message