LVM에서 파티션을 교환 하시겠습니까?

스왑 파티션을 논리 볼륨 그룹에 넣는 데 단점 (예 : 성능)이 있는지 또는 별도의 기본 / 논리 파티션으로 사용하는 것과 "단지"같은지 궁금합니다.

필요한 경우 쉽게 크기를 조정할 수 있지만 가능한 단점은 확실하지 않습니다.

적용 사례 : CentOS 7 웹 서버.

— 레위 사람
소스

"스왑 파티션을 LVM 그룹에 넣음"이 무슨 뜻인지 잘 모르겠습니다. 논리 볼륨을 교체하여 의미하는 바를 이해합니다. 과거의 컴퓨터와 현재 개인 워크 스테이션에서이 작업을 수행했습니다. 나는 어떤 문제도 발견하지 못했고 문제가 발생하는 이유를 생각할 수도 없다. 현재 컴퓨터에서는 스왑이 많이 사용되지만 사용됩니다.

— Faheem Mitha

당신은 맞습니다, 믹스 업을 위해 sry, 방금 편집했습니다! 그리고 응답을위한 thx는 그때 그렇게 할 것입니다!

— Levite

이것을 정식으로 대답해야합니까?

— Faheem Mitha

물론 주요 목표는 우선 스왑을 사용할 필요가 없다는 것입니다.

가장 중요한 것은 스왑 공간이 연속적 일 때 성능이 가장 좋거나 lvcreate -C옵션 을 사용하여 스왑 공간을 사용하기 때문에 스왑 파일을 만들 때와 마찬가지로 시스템이 여전히 최신 상태 일 때 스왑 LVM 볼륨을 만드는 것입니다 . 논리 볼륨을 구성하는 실제 디스크 블록은 디스크 전체에서 조각화되기를 원하지 않습니다. 이러한 이유로 스왑 볼륨의 크기를 조정하지 않는 경우가 종종 있습니다.

Andrew Morton 은 Linux 커널의 주요 개발자 중 하나 라고 말합니다 .

커널은 스왑 시간에 스왑 오프셋-> 디스크 블록의 맵을 생성 한 다음 해당 맵을 사용하여 모든 캐싱, 메타 데이터 및 파일 시스템 코드를 무시하고 기본 디스크 큐에 대해 스왑 I / O를 직접 수행합니다.

이것은 모든 LVM 코드를 무시하고 스왑은 디스크로 바로 이동합니다. 따라서 성능 측면에서 스왑 파티션, 스왑 파일 또는 LVM 볼륨에는 차이가 없습니다.

— HBruijn
소스

자세한 설명은 훌륭한 답변입니다. " That bypasses all the LVM code as well, swap goes straight to disk.", 내가 찾던 것! 크기 조정 문제와 관련하여 : 이러한 이유로 스왑 볼륨을 설치 후 -C 옵션을 사용하여 연속하여 유지되도록 스왑 볼륨을 다시 만드는 것이 합리적입니까? 처럼 lvcreate -C y -L 10G VolGroup -n swap(참조 : blog.zelut.org/2009/03/10/force-contiguous-extents-in-lvm )

— Levite

결코 발견하지 -C, 그 밖을 가리키는 감사를 스위치를!

— HBruijn

"모든 캐싱, 메타 데이터 및 파일 시스템 코드를 무시하고 기본 디스크 큐에 대해 직접 스왑 I / O를 수행하기 위해 해당 맵을 사용합니다."-파일 시스템 (ext3 / reiserfs) 저널링에 대한 답변이지만 실제로 md를 무시하는지 궁금합니다. 습격 ... 그것은 꽤 사용 / 우둔 습격에 스왑에 대한 조언의 톤을 만들 것입니다 ...

— Erk

@Erk raid와 관련하여 파일 시스템은 여전히 IO 장치 위에 추상화 계층이라는 점에 주목하십시오. 즉, raid를 스왑에 사용할 경우 하드 또는 소프트웨어 레이드에 관계없이 모든 일반적인 고려 사항이 여전히 적용됩니다.

— HBruijn

@HBruijn : 아하, 글쎄, 이제 lmd (md raid에서)에 스왑 기능이있는 머신이 있는데 적어도 타지 않습니다 ...

— Erk