LVMで報告されたサイズがdf -hで報告されたサイズと一致しないのはなぜですか?

LVMで報告されたサイズがdf -hで報告されたサイズと一致しないのはなぜですか?

私はLVMに初めて触れていて、それについて非常に混乱しています。

約1.5TBのスペースがあるパーティションに大容量ファイルを転送しています。転送がほぼ終了すると、rsyncはパーティションがいっぱいであるというエラーで終了します。調査した結果、次の事実が見つかりました。

$ sudo lvm lvs
  LV        VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  home      system -wi-ao  97.66G                                      
  log       system -wi-ao  48.81G                                      
  log.audit system -wi-ao   9.75G                                      
  root      system -wi-ao 341.59G                                      
  swap      system -wi-ao   4.88G                                      
  temp      system -wi-ao  97.66G                                      
  var       system -wi-ao   1.46T  

これは、/ var(転送しようとしているパーティション)に予想される記憶容量があることを意味しているようです。しかし私は次を見る:

$ sudo df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/system-root
                      331G  1.3G  313G   1% /
/dev/mapper/system-temp
                       95G  188M   90G   1% /tmp
/dev/mapper/system-var
                       95G   90G     0 100% /var
/dev/mapper/system-home
                       95G  188M   90G   1% /home
/dev/mapper/system-log
                       48G  264M   45G   1% /var/log
/dev/mapper/system-log.audit
                      9.5G  340M  8.7G   4% /var/log/audit
/dev/sda1              99M   25M   70M  26% /boot
tmpfs                 8.0G     0  8.0G   0% /dev/shm

ある時点で音量レベルの調整に関係があると思います。安定したバックアップがありますが、バックアップの実行と復元中にサービスを停止したくありません。もしそうなら、OSが見るファイルシステムをデータを失うことなくlvmの空き容量と一致させる方法はありますか?

ベストアンサー1

ext3ファイルシステムの場合は、次のコマンドを実行してLVサイズに拡張できます。

resize2fs /dev/system/var

ext3でない場合は、適切なツール(xfs_growfs /varXFSなど)を使用してください。

これはまったく恐れることではありません。私は過去10年間、いくつかのオペレーティングシステムで何百ものファイルシステムを拡張してきましたが、これは何らかの種類のハングが発生したことを見たことがありません。

おすすめ記事