web-dev-qa-db-ja.com

LVMによって報告されたサイズとdf-hによって報告されたサイズの間に不一致があるのはなぜですか?

私はLVMを初めて使用し、これに非常に混乱しています。

大きなファイルを、約1.5テラバイトのスペースがあると思ったパーティションに転送しています。転送の終わり近くで、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に従って使用可能なスペースと一致させる方法はありますか?

4
Steven D

これがext3ファイルシステムの場合、以下を実行してLVサイズに拡張できます。

resize2fs /dev/system/var

これがext3以外の場合は、適切なツールを使用してください。 xfs_growfs /varXFSの場合。

これは絶対に恐れることはありません。私は10年以上にわたっていくつかのオペレーティングシステムで数百のファイルシステムを拡張してきましたが、その操作がいかなる種類の混乱にもつながるのを見たことがありません。

6
unixtippse