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
>>
>> It is always possible to agglutinate multiple separate problems
>> into a single complex interdependent solution.
>> In most cases this is a bad idea.
>> _______________________________________________
>> zones-discuss mailing list
>> zones-discuss@opensolaris.org
> 



-- 
frankB

It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution.
In most cases this is a bad idea.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to