Date: Sun, 22 Oct 2000 08:18:02 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Dag-Erling Smorgrav <des@thinksec.com> Cc: arch@FreeBSD.ORG Subject: Re: Ideas concerning fsck Message-ID: <200010221518.e9MFIUX53822@cwsys.cwsent.com> In-Reply-To: Your message of "22 Oct 2000 01:42:50 %2B0200." <xzpsnpprcat.fsf@des.thinksec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzpsnpprcat.fsf@des.thinksec.com>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010221518.e9MFIUX53822>