Hey Ed, Steve, Jordan, Jerry,
I got it in writing from Veritas Engineering that they do not have any heartburn
over using "fsck -o p" on VxFS and inside the zone and also by testing in the
confirmed it behaves as expected and similar to UFS:
# uname -a
SunOS lab234 5.10 Generic_139555-08 sun4u sparc sun4u
# pkginfo -l VRTSvxfs
NAME: VERITAS File System
# fsck -F vxfs -o p /dev/rdsk/c1t14d0s0
/dev/rdsk/c1t14d0s0:file system is clean - log replay is not required
here's the new webrev for your consideration:
On Tue, 15 Dec 2009 08:37:49 +0100, Frank Batschulat (Home)
> valid point, Ed!
> ignoring the minor detail that my fix should really
> do 'fsck -o p" (new webrev is in progress, thanks Steve for catching my
> in fact "-o p" is documented in the generic fsck(1M) man page.
> <snip fsck(1M)>
> -o specific-options
> Check and fix the file system non-interactively
> ("preen"). Exit immediately if there is a problem
> requiring intervention. This option is required to
> enable parallel file system checking.
> <snip end>
> and VxFS does support it as well, and it has the same net effect as on UFS,
> a log reply without operator intervention:
> Allows parallel log replay for several VxFS file systems. Each message from
> fsck is prefixed with the device name to identify the device. This suboption
> does not perform a full file system check in parallel; that is still done
> sequentially on each device, even when multiple devices are specified. This
> option is compatible only with the -y|Y option (that is, non-interactive full
> file system check), in which case a log replay is done in parallel on all
> specified devices. A sequential full file system check is performed on
> devices where needed.
> <snip end>
> however the part "compatible only with the -y|Y option" sounds a bit
> ambiguous to me
> so I pinged a friend as VRTS to clarify this for me.
> worst case would be to add code differentiating between vxfs and ufs here.
> I'll be back once I have the confirmation.
> On Tue, 15 Dec 2009 00:37:52 +0100, Edward Pilatowicz
> <edward.pilatow...@sun.com> wrote:
>> so just one question.
>> the '-p' preen option is only documented in the fsck_ufs(1m) man page,
>> and not in fsck(1m). so i'm wondering is are there zones which may be
>> installed on other filesystems which supply an fsck utility which may
>> not support the preen option? (or perhas '-p is defined as something
>> else for those versions of fsck?) specifically vxfs comes to mind since
>> i know that some s10 deployments use that.
>> On Fri, Dec 11, 2009 at 02:24:49PM +0100, Frank Batschulat (Home) wrote:
>>> friends, may I request code review for the earth-shattering fix to:
>>> 6495558 zoneadm -z <zone> boot should not only check but repair filesystems
>>> when booting a zone, zoneadm ( ie. vplat.c:dofsck() ) should perform the
>>> same tasks as the /usr/sbin/mountall script,
>>> which does a 'is suitable for mounting' (fsck -m) check first, followed by
>>> a preen fsck (fsck -p) if the former failed.
>>> the obvious quick fix would be to change the code in vplat.c:dofsck()
>>> 825 argv = "fsck";
>>> 826 argv = "-m";
>>> 827 argv = (char *)rawdev;
>>> 828 argv = NULL;
>>> 830 status = forkexec(zlogp, cmdbuf, argv);
>>> 831 if (status == 0 || status == -1)
>>> 832 return (status);
>>> 833 zerror(zlogp, B_FALSE, "fsck of '%s' failed with exit status
>>> %d; "
>>> 834 "run fsck manually", rawdev, status);
>>> 835 return (-1);
>>> to always just run fsck in preen mode (shouldn't cause any real problem) or
>>> fork off a 2nd fsck in preen mode
>>> if the first fsck -m failed.
>>> actually the fix will be to just execute fsck in preen mode (fsck -p)
>>> rather then
>>> doing the 'is suitable for mounting' and preen fsck dance. if the former
>>> the latter will have to be done anyways. the latter however kind of implies
>>> the former.
zones-discuss mailing list