`<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>I can show you what I did on the cli, and there are more questions about this as well.</div><div><br></div><div>This is on an openinidana system, which I guess doesn't make any difference. My intentions are to use omnios for this SAN controller, but at the moment I use my old OI host as SAN controller.</div><div><br></div><div><div>root@san1:~# zfs list -t snapshot</div><div>NAME USED AVAIL REFER MOUNTPOINT</div><div>rpool/ROOT/openindiana-1@install 69.8M - 2.79G -</div><div>rpool/ROOT/openindiana-1@2012-11-18-17:40:45 136M - 3.28G -</div><div>root@san1:~# zfs snapshot mainpool/os/node1@test3</div><div>root@san1:~# zfs list -t snapshot</div><div>NAME USED AVAIL REFER MOUNTPOINT</div><div>mainpool/os/node1@test3 0 - 3.06G -</div><div>rpool/ROOT/openindiana-1@install 69.8M - 2.79G -</div><div>rpool/ROOT/openindiana-1@2012-11-18-17:40:45 136M - 3.28G -</div><div><br></div><div>Here I added a rather big file, which is reflected in the change of the size in the snapshot:</div><div><br></div><div>root@san1:~# zfs list -t snapshot</div><div>NAME USED AVAIL REFER MOUNTPOINT</div><div>mainpool/os/node1@test3 95.6M - 3.06G -</div><div>rpool/ROOT/openindiana-1@install 69.8M - 2.79G -</div><div>rpool/ROOT/openindiana-1@2012-11-18-17:40:45 136M - 3.28G -</div><div><br></div><div>Here I remove view and LU, since the rollback wasn't possible when the LU was registred with stmf, it seemed. I tried first to offline the LU, but that wasn't enough, zfs said device was busy.</div><div><br></div><div>root@san1:~# stmfadm remove-view -l 600144F0CD16CB00000050F00BBE0001 0</div><div>root@san1:~# stmfadm offline-lu 600144F0CD16CB00000050F00BBE0001</div><div>root@san1:~# stmfadm list-lu -v 600144F0CD16CB00000050F00BBE0001</div><div>LU Name: 600144F0CD16CB00000050F00BBE0001</div><div> Operational Status: Offline</div><div> Provider Name : sbd</div><div> Alias : os_node1</div><div> View Entry Count : 0</div><div> Data File : /dev/zvol/rdsk/mainpool/os/node1</div><div> Meta File : not set</div><div> Size : 10737418240</div><div> Block Size : 512</div><div> Management URL : not set</div><div> Vendor ID : OI </div><div> Product ID : COMSTAR </div><div> Serial Num : not set</div><div> Write Protect : Disabled</div><div> Writeback Cache : Enabled</div><div> Access State : Active</div><div>root@san1:~# stmfadm delete-lu 600144F0CD16CB00000050F00BBE0001</div><div>root@san1:~# zfs rollback mainpool/os/node1@test3</div><div><br></div><div>Here I make a new LU and view</div><div><br></div><div>root@san1:~# stmfadm create-lu -p alias=os_node1 /dev/zvol/rdsk/mainpool/os/node1</div><div>Logical unit created: 600144F0CD16CB00000050F017DF0002</div><div>root@san1:~# stmfadm add-view -n 0 -h node1 600144F0CD16CB00000050F017DF0002</div><div>root@san1:~# stmfadm list-lu -v 600144F0CD16CB00000050F017DF0002</div><div>LU Name: 600144F0CD16CB00000050F017DF0002</div><div> Operational Status: Online</div><div> Provider Name : sbd</div><div> Alias : os_node1</div><div> View Entry Count : 1</div><div> Data File : /dev/zvol/rdsk/mainpool/os/node1</div><div> Meta File : not set</div><div> Size : 10737418240</div><div> Block Size : 512</div><div> Management URL : not set</div><div> Vendor ID : OI </div><div> Product ID : COMSTAR </div><div> Serial Num : not set</div><div> Write Protect : Disabled</div><div> Writeback Cache : Enabled</div><div> Access State : Active</div><div>root@san1:~# zfs list -t snapshot</div><div>NAME USED AVAIL REFER MOUNTPOINT</div><div>mainpool/os/node1@test3 7.69M - 3.06G -</div><div>rpool/ROOT/openindiana-1@install 69.8M - 2.79G -</div><div>rpool/ROOT/openindiana-1@2012-11-18-17:40:45 136M - 3.28G -</div><div>root@san1:~# </div></div><div><br></div><div>Note the differencies in snapshot size since I rolled back.</div><div><br></div><div>Anyway, when I boot up the host, it goes fine, but the file I put in the host AFTER I made the snapshot is still there. If the snap worked, the file shouldn't have been there, right?</div><div><br></div><div>Rgrds Johan</div><br><br><font color="#990099">-----Eric Sproul <esproul@omniti.com> skrev: -----</font><div style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">Till: Johan Kragsterman <johan.kragsterman@capvert.se><br>Från: Eric Sproul <esproul@omniti.com><br>Datum: 2013.01.11 17:41<br>Kopia: omnios-discuss <omnios-discuss@lists.omniti.com><br>Ärende: Re: [OmniOS-discuss] snapshot and rollback of volume<br><br><div><font face="Courier New,Courier,monospace" size="3">On Fri, Jan 11, 2013 at 11:13 AM, Johan Kragsterman<br><johan.kragsterman@capvert.se> wrote:<br>> Is there anybody that knows if there is any differencies between snapping a<br>> filesystem or a volume? According to oracle admin guide for zfs it seems not<br>> any diff.<br><br>That is correct. ZFS filesystems and volumes are just different<br>representations of the underlying object store.<br><br>> What I done so far, is to make snapshots of an OS LUN volume, change the OS<br>> like putting a new file there, and then rollback the snapshot. But after I<br>> booted the server again, on what I thought was the "old" LUN/volume from the<br>> snapshot, it shows that the new file is there, so it hasn't been any<br>> change...<br><br>That seems the reverse of what I would expect. I could understand the<br>snapshot *not* having a file that was thought to exist at the time of<br>the snapshot, due to buffering by the host OS, but to *have* a file<br>that was thought *not* to exist at the time of the snapshot sounds<br>odd. Can you illustrate the sequence of events that led you to<br>conclude there was no apparent change?<br><br>In general, as with other SAN systems, getting a consistent snapshot<br>of the block storage device requires coordination with the client OS<br>that is using it, to ensure that in-flight state changes are committed<br>and further changes postponed until the snapshot operation completes.<br><br>Eric<br><br></font></div></div></div><div></div></font>
`