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>