Hi everyone,
Sorry for crossposting but it seems I have stumbled upon a problem
that affects both. I have a V490 running Solaris 10u3 with a 16x750GB
raid array connected to it. I''ve created an 8TB zfs filesystem called
data1 and created a zfs filesystem called data1/zones mounted to
/zones. The structure looks like this
data1 208K 8.03T 24.5K /data1
data1/zones 103K 8.03T 29.5K /zones
data1/zones/mytest 24.5K 8.03T 24.5K /zones/mytest
Anyway, I then create a new sparse zone with the root in
/zones/mytest. It looks like this (just a barebone setup)
# zonecfg -z mytest
zonecfg:mytest> info
zonename: mytest
zonepath: /zones/mytest
autoboot: false
pool:
limitpriv:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
When I execute zoneadm -z mytest install I get the following error:
# zoneadm -z mytest install
zoneadm: /zones/mytest: Value too large for defined data type
could not verify zonepath /zones/mytest because of the above errors.
zoneadm: zone mytest failed to verify
Is this due to a too large filesystem or something like this? Sure,
8TB is quite big but not that large by todays standard (and yes, we
really want an 8TB filesystem here. it is not a production system).
If I look at the truss output it looks like a call to statvfs()
returns EOVERFLOW which probably isn''t a good thing.
resolvepath("/zones/mytest", "/zones/mytest", 1024) = 13
stat("/zones/mytest", 0xFFBFE870) = 0
open("/etc/zones/index", O_RDONLY) = 5
fstat64(5, 0xFFBFC928) = 0
fstat64(5, 0xFFBFC7D0) = 0
ioctl(5, TCGETA, 0xFFBFC8B4) Err#25 ENOTTY
read(5, " # C o p y r i g h t ".., 8192) = 398
read(5, 0x0005942C, 8192) = 0
llseek(5, 0, SEEK_CUR) = 398
close(5) = 0
resolvepath("/zones/mytest/..", "/zones", 1024) = 6
stat("/zones", 0xFFBFE870) = 0
statvfs("/zones/mytest", 0xFFBFDFD4) Err#79 EOVERFLOW
fstat64(2, 0xFFBFCC80) = 0
zoneadmwrite(2, " z o n e a d m", 7) = 7
: write(2, " : ", 2) = 2
/zones/mytestwrite(2, " / z o n e s / m y t e s".., 13) = 13
: write(2, " : ", 2) = 2
Value too large for defined data typewrite(2, " V a l u e t o o l
a".., 37) = 37
write(2, "\n", 1) = 1
could not verify zonepath write(2, " c o u l d n o t v e".., 26)
= 26
/zones/mytestwrite(2, " / z o n e s / m y t e s".., 13) = 13
because of the above errors.
write(2, " b e c a u s e o f ".., 30) = 30
stat("/lib", 0xFFBFDC5C) = 0
stat("/platform", 0xFFBFDC5C) = 0
stat("/sbin", 0xFFBFDC5C) = 0
stat("/usr", 0xFFBFDC5C) = 0
zoneadmwrite(2, " z o n e a d m", 7) = 7
: zone write(2, " : z o n e ", 7) = 7
mytestwrite(2, " m y t e s t", 6) = 6
failed to verify
write(2, " f a i l e d t o v".., 18) = 18
_exit(1)
Is there a solution here but to move the zone root to a smaller disk?
cheers,
Nickus
On Thu, Mar 29, 2007 at 01:18:31PM +0300, Niclas Sodergard wrote:> Sorry for crossposting but it seems I have stumbled upon a problem > that affects both. I have a V490 running Solaris 10u3 with a 16x750GB > raid array connected to it. I''ve created an 8TB zfs filesystem called > data1 and created a zfs filesystem called data1/zones mounted to > /zones. The structure looks like this > > data1 208K 8.03T 24.5K /data1 > data1/zones 103K 8.03T 29.5K /zones > data1/zones/mytest 24.5K 8.03T 24.5K /zones/mytest > > When I execute zoneadm -z mytest install I get the following error: > > # zoneadm -z mytest install > zoneadm: /zones/mytest: Value too large for defined data type > could not verify zonepath /zones/mytest because of the above errors. > zoneadm: zone mytest failed to verify > > Is this due to a too large filesystem or something like this? Sure, > 8TB is quite big but not that large by todays standard (and yes, we > really want an 8TB filesystem here. it is not a production system). > > If I look at the truss output it looks like a call to statvfs() > returns EOVERFLOW which probably isn''t a good thing.> Is there a solution here but to move the zone root to a smaller disk?Set a quota (10G should work just fine) on the filesystem and then perform the zone install. Afterwards remove the quota. Ed Plese
On 3/29/07, Ed Plese <ed at edplese.com> wrote:> > > Is there a solution here but to move the zone root to a smaller disk? > > Set a quota (10G should work just fine) on the filesystem and then > perform the zone install. Afterwards remove the quota.Thanks, seems to work just fine. It solved my immediate problem. But... I also like to do clones of my zone and utilize zfs for this but that doesn''t seem to work. It has the same problem If I do a "zoneadm -z mytest2 clone mytest" I get the same value too large error. The problem is that I don''t have a filesystem yet for mytest2 since it needs to be cloned from mytest. cheers, Nickus
Jerry Jelinek
2007-Mar-29 14:01 UTC
[zfs-discuss] Re: [zones-discuss] Zones on large ZFS filesystems
Niclas Sodergard wrote:> Hi everyone, > > Sorry for crossposting but it seems I have stumbled upon a problem > that affects both. I have a V490 running Solaris 10u3 with a 16x750GB > raid array connected to it. I''ve created an 8TB zfs filesystem called > data1 and created a zfs filesystem called data1/zones mounted to > /zones. The structure looks like this...> When I execute zoneadm -z mytest install I get the following error: > > # zoneadm -z mytest install > zoneadm: /zones/mytest: Value too large for defined data type > could not verify zonepath /zones/mytest because of the above errors. > zoneadm: zone mytest failed to verifyWhile this doesn''t help with your immediate issue, this is a known bug: 6433526 zoneadm should use statvfs64 It was fixed in opensolaris in b44 and it is also fixed in S10u4, although that is not available yet. Jerry
Niclas Sodergard
2007-Mar-29 14:07 UTC
[zfs-discuss] Re: [zones-discuss] Zones on large ZFS filesystems
On 3/29/07, Jerry Jelinek <Gerald.Jelinek at sun.com> wrote:> > # zoneadm -z mytest install > > zoneadm: /zones/mytest: Value too large for defined data type > > could not verify zonepath /zones/mytest because of the above errors. > > zoneadm: zone mytest failed to verify > > While this doesn''t help with your immediate issue, this is a known > bug: > > 6433526 zoneadm should use statvfs64 > > It was fixed in opensolaris in b44 and it is also fixed in S10u4, although > that is not available yet.Hi Jerry, Thanks for the info. I just have to revise my setup plans a bit then because I can''t wait for u4. cheers, Nickus
Bill Sommerfeld
2007-Mar-29 15:58 UTC
[zfs-discuss] Re: [zones-discuss] Zones on large ZFS filesystems
On Thu, 2007-03-29 at 17:07 +0300, Niclas Sodergard wrote:> On 3/29/07, Jerry Jelinek <Gerald.Jelinek at sun.com> wrote: > > > > # zoneadm -z mytest install > > > zoneadm: /zones/mytest: Value too large for defined data type > > > could not verify zonepath /zones/mytest because of the above errors. > > > zoneadm: zone mytest failed to verify > > > > While this doesn''t help with your immediate issue, this is a known > > bug: > > > > 6433526 zoneadm should use statvfs64 > > > > It was fixed in opensolaris in b44 and it is also fixed in S10u4, although > > that is not available yet. > > Hi Jerry, > > Thanks for the info. I just have to revise my setup plans a bit then > because I can''t wait for u4.as a general rule you can work around "xxx should use statvfs64"-related bugs by setting an under-2TB quota on the filesystem. (I''ve long thought that statvfs space reporting should have been defined so that it returns the maximum value which fits in the field instead of failing with EOVERFLOW when the actual value doesn''t fit, but for whatever reason, the standards gurus didn''t do that) - Bill
Niclas Sodergard
2007-Mar-29 18:17 UTC
[zfs-discuss] Re: [zones-discuss] Zones on large ZFS filesystems
On 3/29/07, Bill Sommerfeld <sommerfeld at sun.com> wrote:> On Thu, 2007-03-29 at 17:07 +0300, Niclas Sodergard wrote: > > On 3/29/07, Jerry Jelinek <Gerald.Jelinek at sun.com> wrote: > > > > > > # zoneadm -z mytest install > > > > zoneadm: /zones/mytest: Value too large for defined data type > > > > could not verify zonepath /zones/mytest because of the above errors. > > > > zoneadm: zone mytest failed to verify > > > > > > While this doesn''t help with your immediate issue, this is a known > > > bug: > > > > > > 6433526 zoneadm should use statvfs64 > > > > > > It was fixed in opensolaris in b44 and it is also fixed in S10u4, although > > > that is not available yet. > > > > Hi Jerry, > > > > Thanks for the info. I just have to revise my setup plans a bit then > > because I can''t wait for u4. > > as a general rule you can work around "xxx should use statvfs64"-related > bugs by setting an under-2TB quota on the filesystem. > > (I''ve long thought that statvfs space reporting should have been defined > so that it returns the maximum value which fits in the field instead of > failing with EOVERFLOW when the actual value doesn''t fit, but for > whatever reason, the standards gurus didn''t do that)Well, the 2TB quota will save me until I have access until 10u4. cheers, Nickus
On March 29, 2007 1:18:31 PM +0300 Niclas Sodergard <nickus at gmail.com> wrote:> Anyway, I then create a new sparse zone with the root in > /zones/mytest. It looks like this (just a barebone setup)I thought zone root on zfs was not supported. -frank
On 3/30/07, Frank Cusack <fcusack at fcusack.com> wrote:> On March 29, 2007 1:18:31 PM +0300 Niclas Sodergard <nickus at gmail.com> > wrote: > > Anyway, I then create a new sparse zone with the root in > > /zones/mytest. It looks like this (just a barebone setup) > > I thought zone root on zfs was not supported.Not supported if you want to be able to upgrade the system without problems but this is not an issue for this system. Otherwise it works perfectly. cheers, Nickus
Niclas Sodergard wrote:> On 3/29/07, Ed Plese <ed at edplese.com> wrote: >> >> > Is there a solution here but to move the zone root to a smaller disk? >> >> Set a quota (10G should work just fine) on the filesystem and then >> perform the zone install. Afterwards remove the quota. > > Thanks, seems to work just fine. It solved my immediate problem. But... > I also like to do clones of my zone and utilize zfs for this but that > doesn''t seem to work. It has the same problem > > If I do a "zoneadm -z mytest2 clone mytest" I get the same value too > large error. The problem is that I don''t have a filesystem yet for > mytest2 since it needs to be cloned from mytest.You can work around this by setting the quota on an ancestor of the to-be-created clone. Also, implementing RFE 6364688 "method to preserve properties when making a clone" would make workaround #1 (set a quota on the first fs) work for the cloned zone as well. --matt
On 4/3/07, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:> You can work around this by setting the quota on an ancestor of the > to-be-created clone. Also, implementing RFE 6364688 "method to preserve > properties when making a clone" would make workaround #1 (set a quota on > the first fs) work for the cloned zone as well.I should probably try that as well. In the end I decided to put the zoneroot on a separate zfs pool on the internal disks and all the data on the big zfs pool. It is not as smooth when I need to clone the zone but it works really well. cheers, Nickus