Robert Milkowski
2009-Sep-25 16:54 UTC
[zfs-discuss] cannot hold ''xxx'': pool must be upgraded
Hi, I have a zfs send command failing for some reason... # uname -a SunOS XXXX 5.11 snv_123 i86pc i386 i86pc Solaris # zfs send -R -I archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 >/dev/null cannot hold ''archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50'': pool must be upgraded cannot hold ''archive-1/archive/xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59'': pool must be upgraded cannot hold ''archive-1/archive/xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14'': pool must be upgraded cannot hold ''archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59'': pool must be upgraded # zfs list -r -t all archive-1/archive/xxxx NAME USED AVAIL REFER MOUNTPOINT archive-1/archive/xxxx 65.6G 7.69T 8.69G /archive-1/archive/xxxx archive-1/archive/xxxx at rsync-2009-04-21_14:52--2009-04-21_15:13 11.9G - 12.0G - archive-1/archive/xxxx at rsync-2009-05-01_07:45--2009-05-01_08:06 12.0G - 12.1G - archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 12.2G - 12.3G - archive-1/archive/xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59 8.26G - 8.37G - archive-1/archive/xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14 12.6G - 12.7G - archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 0 - 8.69G - The pool is at version 14 and all file systems are at version 3. Ahhh... if -R is provided zfs send now calls zfs_hold_range() which later fails in dsl_dataset_user_hold_check() as it checks if dataset is not below SPA_VERSION_USERREFS which is defined as SPA_VERSION_18 and in my case it is 14 so it fails. But I don''t really want to upgrade to version 18 as then I won''t be able to reboot back to snv_111b (which supports up-to version 14 only). I guess if I would use libzfs from older build it would work as keeping a user hold is not really required... I can understand why it was introduced I''m just unhappy that I can''t do zfs send -R -I now without upgrading a pool.... Probably no point sending the email, as I was looking at the code and dtracing while writing it, but since I''ve written it I will post it. Maybe someone will find it useful. -- Robert Milkowski http://milek.blogspot.com -- This message posted from opensolaris.org
Chris Kirby
2009-Sep-25 17:10 UTC
[zfs-discuss] cannot hold ''xxx'': pool must be upgraded
On Sep 25, 2009, at 11:54 AM, Robert Milkowski wrote:> Hi, > > I have a zfs send command failing for some reason... > > > # uname -a > SunOS XXXX 5.11 snv_123 i86pc i386 i86pc Solaris > > # zfs send -R -I archive-1/archive/ > xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 archive-1/archive/ > xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 >/dev/null > cannot hold ''archive-1/archive/ > xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50'': pool must be upgraded > cannot hold ''archive-1/archive/ > xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59'': pool must be upgraded > cannot hold ''archive-1/archive/ > xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14'': pool must be upgraded > cannot hold ''archive-1/archive/ > xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59'': pool must be upgraded > > > # zfs list -r -t all archive-1/archive/xxxx > NAME > USED > AVAIL REFER MOUNTPOINT > archive-1/archive/xxxx > 65.6G 7.69T 8.69G /archive-1/archive/xxxx > archive-1/archive/xxxx at rsync-2009-04-21_14:52--2009-04-21_15:13 > 11.9G - 12.0G - > archive-1/archive/xxxx at rsync-2009-05-01_07:45--2009-05-01_08:06 > 12.0G - 12.1G - > archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 > 12.2G - 12.3G - > archive-1/archive/xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59 > 8.26G - 8.37G - > archive-1/archive/xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14 > 12.6G - 12.7G - > archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 > 0 - 8.69G - > > > The pool is at version 14 and all file systems are at version 3. > > > Ahhh... if -R is provided zfs send now calls zfs_hold_range() which > later fails in dsl_dataset_user_hold_check() as it checks if dataset > is not below SPA_VERSION_USERREFS which is defined as SPA_VERSION_18 > and in my case it is 14 so it fails. > > But I don''t really want to upgrade to version 18 as then I won''t be > able to reboot back to snv_111b (which supports up-to version 14 > only). I guess if I would use libzfs from older build it would work > as keeping a user hold is not really required... > > I can understand why it was introduced I''m just unhappy that I can''t > do zfs send -R -I now without upgrading a pool.... > > Probably no point sending the email, as I was looking at the code > and dtracing while writing it, but since I''ve written it I will post > it. Maybe someone will find it useful.Robert, That''s useful information indeed. I''ve filed this CR: 6885860 zfs send shouldn''t require support for snapshot holds Sorry for the trouble, please look for this to be fixed soon. -Chris
Robert Milkowski
2009-Sep-25 19:43 UTC
[zfs-discuss] cannot hold ''xxx'': pool must be upgraded
Chris Kirby wrote:> On Sep 25, 2009, at 11:54 AM, Robert Milkowski wrote: > >> Hi, >> >> I have a zfs send command failing for some reason... >> >> >> # uname -a >> SunOS XXXX 5.11 snv_123 i86pc i386 i86pc Solaris >> >> # zfs send -R -I >> archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 >> archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 >> >/dev/null >> cannot hold >> ''archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50'': >> pool must be upgraded >> cannot hold >> ''archive-1/archive/xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59'': >> pool must be upgraded >> cannot hold >> ''archive-1/archive/xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14'': >> pool must be upgraded >> cannot hold >> ''archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59'': >> pool must be upgraded >> >> >> # zfs list -r -t all archive-1/archive/xxxx >> NAME >> USED AVAIL REFER MOUNTPOINT >> archive-1/archive/xxxx >> 65.6G 7.69T 8.69G /archive-1/archive/xxxx >> archive-1/archive/xxxx at rsync-2009-04-21_14:52--2009-04-21_15:13 >> 11.9G - 12.0G - >> archive-1/archive/xxxx at rsync-2009-05-01_07:45--2009-05-01_08:06 >> 12.0G - 12.1G - >> archive-1/archive/xxxx at rsync-2009-06-01_07:45--2009-06-01_08:50 >> 12.2G - 12.3G - >> archive-1/archive/xxxx at rsync-2009-07-01_07:45--2009-07-01_07:59 >> 8.26G - 8.37G - >> archive-1/archive/xxxx at rsync-2009-08-01_07:45--2009-08-01_10:14 >> 12.6G - 12.7G - >> archive-1/archive/xxxx at rsync-2009-09-01_07:45--2009-09-01_07:59 >> 0 - 8.69G - >> >> >> The pool is at version 14 and all file systems are at version 3. >> >> >> Ahhh... if -R is provided zfs send now calls zfs_hold_range() which >> later fails in dsl_dataset_user_hold_check() as it checks if dataset >> is not below SPA_VERSION_USERREFS which is defined as SPA_VERSION_18 >> and in my case it is 14 so it fails. >> >> But I don''t really want to upgrade to version 18 as then I won''t be >> able to reboot back to snv_111b (which supports up-to version 14 >> only). I guess if I would use libzfs from older build it would work >> as keeping a user hold is not really required... >> >> I can understand why it was introduced I''m just unhappy that I can''t >> do zfs send -R -I now without upgrading a pool.... >> >> Probably no point sending the email, as I was looking at the code and >> dtracing while writing it, but since I''ve written it I will post it. >> Maybe someone will find it useful. > > Robert, > That''s useful information indeed. I''ve filed this CR: > > 6885860 zfs send shouldn''t require support for snapshot holds > > Sorry for the trouble, please look for this to be fixed soon.Thank you. btw: how do you want to fix it? Do you want to acquire a snapshot hold but continue anyway if it is not possible (only in case whene error is ENOTSUP I think)? Or do you want to get rid of it entirely? -- Robert Milkowski http://milek.blogspot.com
Chris Kirby
2009-Sep-25 19:54 UTC
[zfs-discuss] cannot hold ''xxx'': pool must be upgraded
On Sep 25, 2009, at 2:43 PM, Robert Milkowski wrote:> Chris Kirby wrote: >> On Sep 25, 2009, at 11:54 AM, Robert Milkowski wrote: >> >> That''s useful information indeed. I''ve filed this CR: >> >> 6885860 zfs send shouldn''t require support for snapshot holds >> >> Sorry for the trouble, please look for this to be fixed soon. > Thank you. > btw: how do you want to fix it? Do you want to acquire a snapshot > hold but continue anyway if it is not possible (only in case whene > error is ENOTSUP I think)? Or do you want to get rid of it entirely?In this particular case, we should make sure the pool version supports snapshot holds before trying to request (or release) any. We still want to acquire the temporary holds if we can, since that prevents a race with zfs destroy. That case is becoming more common with automated snapshots and their associated retention policies. -Chris
Robert Milkowski
2009-Sep-25 21:59 UTC
[zfs-discuss] cannot hold ''xxx'': pool must be upgraded
Chris Kirby wrote:> On Sep 25, 2009, at 2:43 PM, Robert Milkowski wrote: > >> Chris Kirby wrote: >>> On Sep 25, 2009, at 11:54 AM, Robert Milkowski wrote: >>> >>> That''s useful information indeed. I''ve filed this CR: >>> >>> 6885860 zfs send shouldn''t require support for snapshot holds >>> >>> Sorry for the trouble, please look for this to be fixed soon. >> Thank you. >> btw: how do you want to fix it? Do you want to acquire a snapshot >> hold but continue anyway if it is not possible (only in case whene >> error is ENOTSUP I think)? Or do you want to get rid of it entirely? > > > In this particular case, we should make sure the pool version supports > snapshot > holds before trying to request (or release) any. > > We still want to acquire the temporary holds if we can, since that > prevents a race with zfs destroy. That case is becoming more common > with automated snapshots and their associated retention policies. >Yeah, this makes sense.