Re: [zones-discuss] code review for 6495558
Frank Batschulat (Home) wrote: 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: # 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 here's the new webrev for your consideration: http://cr.opensolaris.org/~batschul/onnv-vplat/ Frank, Looks fine to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
lgtm. ed On Thu, Dec 17, 2009 at 07:34:08PM +0100, Frank Batschulat (Home) wrote: > 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: > > > # 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 > > > here's the new webrev for your consideration: > > http://cr.opensolaris.org/~batschul/onnv-vplat/ > > thanks! > frankB ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
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:
# 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
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)
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.
>
>
> -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.
>
>
>
> 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
>
>
> 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.
>
>
> 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
> 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 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
Re: [zones-discuss] code review for 6495558
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.
-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.
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
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.
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
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 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
Re: [zones-discuss] code review for 6495558
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 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 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
On 12/11/09 05:24 AM, Frank Batschulat (Home) wrote: friends, may I request code review for the earth-shattering fix to: 6495558 zoneadm -z 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! Hi Frank, Your fix looks fine to me. Thanks, Jordan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review for 6495558
Frank Batschulat (Home) wrote: friends, may I request code review for the earth-shattering fix to: 6495558 zoneadm -z 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. Frank, Looks fine to me. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
