Avamar：由於資料分割區稀疏檔案的差異，格線進入管理模式

Summary: 本文解決資料分割區之間的稀疏檔案數量不同，導致格線進入管理模式的問題。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

所有備份和複寫目的地活動均失敗。

Avamar Server 處於管理模式。

容量低於 diskreadonly 價。

所有資料分割區的等量大小類似：

status.dpn
Thu Jul 16 09:41:28 CEST 2015  [avamar.emc.com] Thu Jul 16 07:41:27 2020 UTC (Initialized Thu Jan 16 16:42:42 2014 UTC)
Node   IP Address     Version   State   Runlevel  Srvr+Root+User Dis Suspend Load UsedMB Errlen  %Full   Percent Full and Stripe Status by Disk
0.0     10.10.10.10  7.1.1-145  ONLINE fullaccess mhpu+0hpu+0000   1 false   0.03 35759 80935381   1.6%   1%(onl:1414)  1%(onl:1418)  1%(onl:1408)  1%(onl:1414)  1%(onl:1414)  1%(onl:1412)
Srvr+Root+User Modes = migrate + hfswriteable + persistwriteable + useraccntwriteable

System ID: 1434729928@00:50:56:8A:24:53

All reported states=(ONLINE), runlevels=(fullaccess), modes=(mhpu+0hpu+0000)
System-Status: ok
Access-Status: admin

No checkpoint yet
No GC yet
No hfscheck yet

Maintenance windows scheduler capacity profile is active.
  The backup window is currently running.
  Next backup window start time: Thu Jul 16 20:00:00 2020 CEST
  Next maintenance window start time: Thu Jul 16 12:00:00 2020 CEST
 

以下命令的輸出表明網格處於管理模式，因為稱為 diskbeat：
（diskbeat 是變更伺服器存取模式的活動）

avmaint nodelist --xmlperline=99 | grep activityaccess 
<activityaccessmodes adminuser="mhpu+0hpu+0hpu" checkpoint="mhpu+0hpu+0hpu" conversion="mhpu+0hpu+0hpu" diskbeat="mhpu+0hpu+0000" garbagecollect="mhpu+0hpu+0hpu" 
heartbeat="mhpu+0hpu+0hpu" hfscheckserver="mhpu+0hpu+0hpu" hfscheckexecute="mhpu+0hpu+0hpu" nodebeat="mhpu+0hpu+0hpu" runlevel="mhpu+0hpu+0hpu" 
testintegrity="mhpu+0hpu+0hpu" removehashes="mhpu+0hpu+0hpu" rebuildstripe="mhpu+0hpu+0hpu" diskfull="mhpu+0hpu+0hpu" hashrefcheck="mhpu+0hpu+0hpu"/>
 

可使用 df 命令顯示資料分區之間存在很大差異：

範例：

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             7.9G  6.2G  1.4G  82% /
udev                   18G  288K   18G   1% /dev
tmpfs                  18G     0   18G   0% /dev/shm
/dev/sda1             130M   62M   61M  51% /boot
/dev/sda7             1.5G  227M  1.2G  17% /var
/dev/sda9              77G   50G   23G  70% /space
/dev/sdb1             1.0T  190G  835G  19% /data01
/dev/sdc1             1.0T  183G  842G  18% /data02
/dev/sdd1             1.0T  185G  839G  19% /data03
/dev/sde1             1.0T  416G  608G  41% /data04
/dev/sdf1             1.0T  190G  835G  19% /data05
/dev/sdg1             1.0T  187G  838G  19% /data06

在此輸出中，使用 /data04 為 41%，而其他資料分割的使用率為 18% 至 19%。

資料分區之間的大小差異超過 freespaceunbalance 價。
(freespaceunbalance 是資料分區之間的最大容量差異）

 

進一步的調查顯示：

檢查點 (cp) 所有資料分區的開銷類似，但一或多個分區的 cur 大小較低：

cps -blk 
Checkpoint usage by partition:
  188.020 /data01/cur
  181.944 /data02/cur
  186.020 /data03/cur
  435.234 /data04/cur
  190.617 /data05/cur
  187.797 /data06/cur
    0.540 /data01/cp.20200716082941
    0.542 /data02/cp.20200716082941
    0.548 /data03/cp.20200716082941
    0.038 /data04/cp.20200716082941
    0.523 /data05/cp.20200716082941
    0.493 /data06/cp.20200716082941
    0.759 /data01/cp.20200716080454
    0.777 /data02/cp.20200716080454
    0.781 /data03/cp.20200716080454
    0.336 /data04/cp.20200716080454
    0.751 /data05/cp.20200716080454
    0.721 /data06/cp.20200716080454

GB used     %use Total checkpoint usage by node:
 6593.815        Total blocks on node           Thu Jul 16 10:41:56 2020
 5198.045  78.83 Total blocks available
 1369.633  20.77 cur                            Thu Jul 16 10:33:14 2020
    2.683   0.04 cp.20200716082941              Thu Jul 16 10:32:42 2020
    4.125   0.06 cp.20200716080454              Thu Jul 16 10:14:15 2020
 1376.440  20.87 Total blocks used by dpn
 

CUR 分區 表觀 大小（應用程式看到的大小）和 CUR 磁碟使用方式（檔案佔用的實際空間）之間存在很大差異：

du -sh --apparent-size /data??/cur
458G    /data01/cur
456G    /data02/cur
456G    /data03/cur
455G    /data04/cur
457G    /data05/cur
456G    /data06/cur 
du -sh /data??/cur
176G    /data01/cur
170G    /data02/cur
174G    /data03/cur
406G    /data04/cur
178G    /data05/cur
175G    /data06/cur

Cause

一個或多個數據分區具有比其他數據分區更多的稀疏檔。

稀疏檔是一種檔類型，當分配給檔的塊大部分為空時，它會嘗試更有效地使用文件系統空間。
（例如：僅包含零或不包含任何內容的塊實際上並未存儲在磁碟上。

相反，它會將表示空塊的簡短資訊（元數據）寫入磁碟。

 

此問題通常與高更改率有關，這會導致檢查點開銷急劇增加。

Resolution

1.執行下列命令：

status.dpn 
avmaint nodelist --xmlperline=99 | grep activityaccess 
df -h 
cps -blk
du -sh --apparent-size /data??/cur
du -sh /data??/cur
 

2.請參考本文並提供上述的輸出結果，與 Dell Technologies Avamar 支援團隊建立服務要求。

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000036449
Article Type: Solution
Last Modified: 17 Jun 2025
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.