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년 동안 여러 운영 체제에서 수백 개의 파일 시스템을 확장해 왔지만 이 작업으로 인해 어떤 종류의 중단이 발생하는 것을 본 적이 없습니다.

관련 정보