I just tried moving a dump volume form rpool into another pool so I used zfs send/receive to copy the volume (to keep some older dumps) then ran dumpadm -d to use the new location. This caused a panic. Nothing ended up in messages and needless to say, there isn''t a dump! Creating a new volume and using that worked fine. This was on Solaris 10 update 8. Has anyone else seen anything like this? -- Ian.
On 05/12/10 04:29 AM, Ian Collins wrote:> I just tried moving a dump volume form rpool into another pool so I > used zfs send/receive to copy the volume (to keep some older dumps) > then ran dumpadm -d to use the new location. This caused a panic. > Nothing ended up in messages and needless to say, there isn''t a dump! > > Creating a new volume and using that worked fine. > > This was on Solaris 10 update 8. > > Has anyone else seen anything like this? >The fact that a panic occurred is some kind of bug, but I''m also not surprised that this didn''t work. Dump volumes have specialized behavior and characteristics and using send/receive to move them (or any other way to move them) is probably not going to work. You need to extract the dump from the dump zvol using savecore and then move the resulting file. Lori
On 05/13/10 03:27 AM, Lori Alt wrote:> On 05/12/10 04:29 AM, Ian Collins wrote: >> I just tried moving a dump volume form rpool into another pool so I >> used zfs send/receive to copy the volume (to keep some older dumps) >> then ran dumpadm -d to use the new location. This caused a panic. >> Nothing ended up in messages and needless to say, there isn''t a dump! >> >> Creating a new volume and using that worked fine. >> >> This was on Solaris 10 update 8. >> >> Has anyone else seen anything like this? >> > > The fact that a panic occurred is some kind of bug, but I''m also not > surprised that this didn''t work. Dump volumes have specialized > behavior and characteristics and using send/receive to move them (or > any other way to move them) is probably not going to work. You need > to extract the dump from the dump zvol using savecore and then move > the resulting file. >I''m surprised. I thought the volume used for dump is just a normal zvol or other block device. I didn''t realise there was any relationship between a zvol and its contents. One odd think I did notice was the device size was reported differently on the new pool: zfs get all space/dump NAME PROPERTY VALUE SOURCE space/dump type volume - space/dump creation Wed May 12 20:56 2010 - space/dump used 12.9G - space/dump available 201G - space/dump referenced 12.9G - space/dump compressratio 1.01x - space/dump reservation none default space/dump volsize 16G - space/dump volblocksize 128K - space/dump checksum on default space/dump compression on inherited from space space/dump readonly off default space/dump shareiscsi off default space/dump copies 1 default space/dump refreservation none default space/dump primarycache all default space/dump secondarycache all default space/dump usedbysnapshots 0 - space/dump usedbydataset 12.9G - space/dump usedbychildren 0 - space/dump usedbyrefreservation 0 - zfs get all rpool/dump NAME PROPERTY VALUE SOURCE rpool/dump type volume - rpool/dump creation Thu Jun 25 19:40 2009 - rpool/dump used 16.0G - rpool/dump available 10.4G - rpool/dump referenced 16K - rpool/dump compressratio 1.00x - rpool/dump reservation none default rpool/dump volsize 16G - rpool/dump volblocksize 8K - rpool/dump checksum off local rpool/dump compression off local rpool/dump readonly off default rpool/dump shareiscsi off default rpool/dump copies 1 default rpool/dump refreservation none default rpool/dump primarycache all default rpool/dump secondarycache all default -- Ian.
On Wed, May 12, 2010 at 2:19 PM, Ian Collins <ian at ianshome.com> wrote:> space/dump ?compression ? ? ? ? ? on ? ? ? ? ? ? ? ? ? ? inherited from > spaceI''m pretty sure you can''t have compression or dedup enabled on a dump volume. -B -- Brandon High : bhigh at freaks.com
On 12/05/2010 22:19, Ian Collins wrote:> On 05/13/10 03:27 AM, Lori Alt wrote: >> On 05/12/10 04:29 AM, Ian Collins wrote: >>> I just tried moving a dump volume form rpool into another pool so I >>> used zfs send/receive to copy the volume (to keep some older dumps) >>> then ran dumpadm -d to use the new location. This caused a panic. >>> Nothing ended up in messages and needless to say, there isn''t a dump! >>> >>> Creating a new volume and using that worked fine. >>> >>> This was on Solaris 10 update 8. >>> >>> Has anyone else seen anything like this? >>> >> >> The fact that a panic occurred is some kind of bug, but I''m also not >> surprised that this didn''t work. Dump volumes have specialized >> behavior and characteristics and using send/receive to move them (or >> any other way to move them) is probably not going to work. You need >> to extract the dump from the dump zvol using savecore and then move >> the resulting file. >> > I''m surprised. I thought the volume used for dump is just a normal > zvol or other block device. I didn''t realise there was any > relationship between a zvol and its contents. > > One odd think I did notice was the device size was reported > differently on the new pool: > > zfs get all space/dump > NAME PROPERTY VALUE SOURCE > space/dump type volume - > space/dump creation Wed May 12 20:56 2010 - > space/dump used 12.9G - > space/dump available 201G - > space/dump referenced 12.9G - > space/dump compressratio 1.01x - > space/dump reservation none default > space/dump volsize 16G - > space/dump volblocksize 128K - > space/dump checksum on default > space/dump compression on inherited > from space > space/dump readonly off default > space/dump shareiscsi off default > space/dump copies 1 default > space/dump refreservation none default > space/dump primarycache all default > space/dump secondarycache all default > space/dump usedbysnapshots 0 - > space/dump usedbydataset 12.9G - > space/dump usedbychildren 0 - > space/dump usedbyrefreservation 0 - > > zfs get all rpool/dump > NAME PROPERTY VALUE SOURCE > rpool/dump type volume - > rpool/dump creation Thu Jun 25 19:40 2009 - > rpool/dump used 16.0G - > rpool/dump available 10.4G - > rpool/dump referenced 16K - > rpool/dump compressratio 1.00x - > rpool/dump reservation none default > rpool/dump volsize 16G - > rpool/dump volblocksize 8K - > rpool/dump checksum off local > rpool/dump compression off local > rpool/dump readonly off default > rpool/dump shareiscsi off default > rpool/dump copies 1 default > rpool/dump refreservation none default > rpool/dump primarycache all default > rpool/dump secondarycache all default >zvol used as a dump device has some constraints in regards to its settings like checksum, compressions, etc. For more details see: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zvol.c#1683 See that space/dump has checksums turned on, compression turned on, etc. while rpool/dump doesn''t. Additionally all blocks need to be pre-allocated (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zvol.c#1785) - but zfs send|recv should replicate it I think. -- Robert Milkowski http://milek.blogspot.com