Avamar: Veri bölümlerindeki farklılıklar nedeniyle kılavuz yönetici moduna girer: seyrek dosyalar

Summary: Bu makalede, seyrek dosya sayısının veri bölümleri arasında farklılık göstermesi ve kılavuzun yönetici moduna girmesine neden olması sorunu ele alınmaktadır.

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.

Symptoms

Tüm yedeklemeler ve çoğaltma hedefi etkinlikleri başarısız oluyor.

Avamar Server yönetici modunda.

Kapasite diskreadonly değer.

Tüm veri bölümlerindeki şerit sayısı benzerdir:

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
 

Aşağıdaki komutun çıktısı, ızgaranın adı verilen bir işlem nedeniyle yönetici modunda olduğunu gösterir. diskbeat:
(diskbeat sunucu erişim modunu değiştiren etkinliktir)

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"/> 
 

Komutta df Komut, veri bölümleri arasında büyük bir tutarsızlık olduğunu gösteriyor:

Örneğin:

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 

Bu çıktıda, /data04 %41 kullanılırken, diğer veri bölümleri %18-%19 oranında kullanılır.

Veri bölümleri arasındaki bu boyut farkı, freespaceunbalance değer.
(freespaceunbalance veri bölümleri arasındaki maksimum kapasite farkıdır)

 

Daha fazla araştırma şunları gösterir:

Kontrol noktası (cp) Veri bölümleri arasında benzer ek yük, ancak CUR boyutu bir veya daha fazla bölümde daha düşüktür:

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 bölümünün görünen boyutu (uygulamalar tarafından görülen boyut) ile CUR disk kullanımı (dosyalar tarafından ne kadar gerçek alan kullanıldığı) arasında büyük bir fark vardır:

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

Bir veya daha fazla veri bölümü, diğer veri bölümlerinden daha seyrek dosyalara sahip.

Seyrek dosya, dosyaya ayrılan bloklar çoğunlukla boş olduğunda dosya sistemi alanını daha verimli kullanmaya çalışan bir dosya türüdür.
(Örneğin: Yalnızca sıfır içeren veya hiçbir şey içermeyen bloklar aslında diskte depolanmaz.)

Bunun yerine, boş blokları temsil eden kısa bilgileri (meta veriler) diske yazar.

 

Bu sorun genellikle yüksek bir değişim oranıyla ilişkilendirilir ve bu da kontrol noktası ek yükünün önemli ölçüde artmasına neden olur.

Resolution

1. Aşağıdaki komutları çalıştırın:

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 Destek ekibi ile bu makaleye referans vererek ve yukarıda toplanan çıktıyı sağlayarak bir Servis İsteği oluşturun.

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.