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.