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
lab I
confirmed it behaves as expected and similar to UFS:
<snip end>
# uname -a
SunOS lab234 5.10 Generic_139555-08 sun4u sparc sun4u
# pkginfo -l VRTSvxfs
PKGINST: VRTSvxfs
NAME: VERITAS File System
CATEGORY: system,utilities
ARCH: sparc
VERSION: 5.0,REV=5.0A55_sol
# fsck -F vxfs -o p /dev/rdsk/c1t14d0s0
/dev/rdsk/c1t14d0s0:file system is clean - log replay is not required
<snip end>
here's the new webrev for your consideration:
http://cr.opensolaris.org/~batschul/onnv-vplat/
thanks!
frankB
On Tue, 15 Dec 2009 08:37:49 +0100, Frank Batschulat (Home)
<frank.batschu...@sun.com> wrote:
> 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
> ignorance)
>
> in fact "-o p" is documented in the generic fsck(1M) man page.
>
> <snip fsck(1M)>
> -o specific-options
>
> p
> 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:
>
> http://sfdoccentral.symantec.com/sf/5.0MP3/solaris/manpages/vxfs/man1m/fsck_vxfs.html
>
> <snip>
> p
> 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.
>
> thanks!
> frankB
>
> 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.
>>
>> ed
>>
>> 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
>>> http://cr.opensolaris.org/~batschul/onnv-vplat/
>>>
>>> backround:
>>>
>>> Evaluation
>>>
>>> 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[0] = "fsck";
>>> 826 argv[1] = "-m";
>>> 827 argv[2] = (char *)rawdev;
>>> 828 argv[3] = NULL;
>>> 829
>>> 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
>>> fails,
>>> the latter will have to be done anyways. the latter however kind of implies
>>> the former.
>>>
>>> thanks!
>>> --
>>> frankB
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
