Chinaunix首页 | 论坛 | 博客
  • 博客访问: 58898
  • 博文数量: 44
  • 博客积分: 1245
  • 博客等级: 中尉
  • 技术积分: 255
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-08 10:41
文章分类

全部博文(44)

文章存档

2013年(1)

2012年(5)

2011年(38)

我的朋友

分类: 服务器与存储

2011-09-13 12:45:23

Description

How can I tell if a SnapVault rollback is progressing?

SnapVault remains in a quiescing state after the transfer has been aborted.
Procedure

During the rollback process that occurs after an aborted SnapVault transfer, the storage controller takes a new snapshot of the filesystem in its present state with the data incompletely transferred. Then it performs a filesystem comparison between the current SnapVault base snapshot and the new one, reverting changes to the base snapshot along the way. This occurs until the filesystem has returned to its former consistent state. After the process completes, both cleanup and base snapshots are removed and a new base snapshot for that SnapVault or qtree SnapMirror relationship is created.

There is no sure-fire way to speed up a rollback operation. Since it is a background process on a busy storage controller, user operations such as Network File System (NFS), Common Internet File System protocol (CIFS), iSCSI, and FCP data transfer will take precedence. The number of inodes and kilobytes to be rolled back and the ongoing system load (CPU and disk) both affect its duration. Once a rollback has started, there's no way to stop or abort the process.

However, it is possible to determine what sort of progress is being made with the rollback operation over a period of time by examining the number of changed kilobytes between the base and cleanup snapshots in the output of the snap delta command, and comparing it to the rate of change as shown in df command for a given period of time. This is easier to do with volumes that contain fewer SnapVault destinations.

It is also possible to see the number of inodes that will be removed from the active filesystem by examining the output of snapvault status -l on the SnapVault primary system.  Because SnapVault replicates inodes before actual user data, the active filesystem will lose the number of inodes listed in Total files to transfer rather than total files transferred.

# snapvault status -l

Source:                       ossv:/usr
Destination:                  controller:/vol/sv_sec_dest/ossv-usr
Status:                       Idle with restart checkpoint
State:                        Source
Lag:                          -
Mirror Timestamp:             -
Base Snapshot:                -
Current Transfer Type:        -
Contents:                     -
Last Transfer Type:           -
Last Transfer From:           -
Last Transfer Size:           6242 MB
Last Transfer Duration:       00:27:28
Total files to transfer:      733547
Total files transferred:      529365
Current File Size:            4608
Current File Progress:        4608
Current File Name:            /usr/test/file-545233
Transfer Error ID:            -
Transfer Error Message:       -

In the example below, the cleanup snapshot has just been created.  The snap delta command tells us that 4248144-kilobyte (KB) of changes separate the base snapshot from the cleanup snapshot.

Volume sv_sec_dest

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-cleanup.0      Active File System   211416              2s   380548800.000
-base.5         -cleanup.0           4248144        0d 02:07  2002791.828
 
From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-base.5         Active File System   4459560       0d 02:07   2101913.589
 
Filesystem                   kbytes       used      avail   capacity  Mounted on
/vol/sv_sec_dest/           16777216    7894212    8883004      47%  /vol/sv_sec_dest/
/vol/sv_sec_dest/.snapshot   4194304     129404    4064900       3%  /vol/sv_sec_dest/.snapshot
 
Filesystem              iused      ifree   %iused  Mounted on
/vol/sv_sec_dest/      884747    1115241     44%  /vol/sv_sec_dest/
 

After 21 seconds, the df command shows 600-megabyte (MB) of changes and 210000 files have been removed from the active filesystem.

After an additional 15 seconds:

Volume sv_sec_dest

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-cleanup.0      Active File System   244768           23s     38311513.043
-base.5         -cleanup.0           4248144     0d 02:07     2002791.828
 
From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-base.5         Active File System   4492912      0d 02:07    2111827.027
 
Filesystem                    kbytes      used       avail   capacity  Mounted on
/vol/sv_sec_dest/             16777216    7321080    9456136      44%  /vol/sv_sec_dest/
/vol/sv_sec_dest/.snapshot     4194304     760476    3433828      18%  /vol/sv_sec_dest/.snapshot
 
Filesystem               iused      ifree  %iused  Mounted on
/vol/sv_sec_dest/       670298    1329690     34%  /vol/sv_sec_dest/

After 46 seconds, an additional 2.4-gigabyte (GB) of data has been removed from the active filesystem.  We can see the destination volume's snapshot usage growing, as well.

After an additional 61 seconds:

Volume sv_sec_dest

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-cleanup.0      Active File System   328400             59s   20037966.101
-base.5         -cleanup.0           4248144        0d 02:07  2002791.828
 
From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-base.5         Active File System   4576544        0d 02:08  2141073.216
 
Filesystem                    kbytes      used      avail    capacity  Mounted on
/vol/sv_sec_dest/             16777216    4888680   11888536      29%  /vol/sv_sec_dest/
/vol/sv_sec_dest/.snapshot     4194304    3275068     919236      78%  /vol/sv_sec_dest/.snapshot
 
Filesystem               iused      ifree  %iused  Mounted on
/vol/sv_sec_dest/       366428    1633560     18%  /vol/sv_sec_dest/

For systems undergoing a very large rollback, a second-by-second look will not be as useful as comparing the amount of data that is removed over a longer period of time, such as 30 minutes or an hour.

Afer 84 seconds:

Volume sv_sec_dest

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-cleanup.0      Active File System   384828         0d 00:01  18471744.000
-base.5         -cleanup.0           4248144        0d 02:07  2002791.828
 
From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-base.5         Active File System   4632972        0d 02:08  2162974.867
 
Filesystem                    kbytes      used      avail    capacity  Mounted on
/vol/sv_sec_dest/             16777216    4005872   12771344      24%  /vol/sv_sec_dest/
/vol/sv_sec_dest/.snapshot     4194304    4410556          0     105%  /vol/sv_sec_dest/.snapshot
 
Filesystem               iused      ifree  %iused  Mounted on
/vol/sv_sec_dest/       231544    1768444     12%  /vol/sv_sec_dest/

Finally, there are no more rollback changes to be made so the base and cleanup snapshots will be removed.

After 97 seconds:

Volume sv_sec_dest

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------
-base.6         Active File System   17936               5s   12913920.000
 
Filesystem                   kbytes       used      avail   capacity  Mounted on
/vol/sv_sec_dest/            16777216    3600504   13176712      21%  /vol/sv_sec_dest/
/vol/sv_sec_dest/.snapshot    4194304        476    4193828       0%  /vol/sv_sec_dest/.snapshot
 
Filesystem               iused      ifree  %iused  Mounted on
/vol/sv_sec_dest/       166002    1833986      8%  /vol/sv_sec_dest/

If you need further assistance, post a question in the NetApp Support Community.
阅读(645) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~