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
      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:



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

Reply via email to