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
