몇 주 전에 나는 이전에 본 적이 없는 것을 만났습니다: 파티션 없이 저장 장치에 마운트된 파일 시스템(내 생각에는 ext3이라고 생각합니다). 본질적으로/dev/sdb 예전에는전체 파일 시스템. 많은 파일 시스템을 빈 공간으로 확장할 수 있다는 것을 알고 있으므로 LVM이나 다른 유형의 볼륨 관리자를 다루지 않고도 그렇게 할 수 있지만 이런 방식으로 저장소를 설정하면 다른 이점이 있습니까?
내가 보고 있는 특정 상황은 부팅 볼륨과 루트 볼륨이 서로 다른 저장 장치의 완전히 전통적인 파티션인 숫자 처리 서버를 위한 임시 데이터 볼륨입니다. -
답변1
장점: 파티션 테이블에서 단일 디스크 섹터를 낭비하지 않습니다. (응.)
장점: 디스크는 PC 스타일 파티셔닝을 지원하지 않는 운영 체제에서 사용할 수 있습니다. (하나를 사용하는 것과 같습니다.)
단점: 이는 일반적이지 않으며 공동 시스템 관리자를 혼란스럽게 할 수 있습니다. (바라보다?)
단점: 다른 운영 체제를 설치하면 디스크에 쓰레기가 포함되어 있다고 생각할 수 있으며 잘못된 디스크를 선택하여 실수로 덮어쓰기가 쉽고 운영 체제는 종종 이해하지 못하는 유형의 파티션을 유지합니다.
중요하지 않습니다. 파티션보다 디스크에서 직접 파일 시스템을 확장하는 것이 더 쉽지 않으며 그 반대의 경우도 마찬가지입니다. (LVM을 사용하면 작업이 더 쉬워집니다.)
결론: 효과는 있지만 좋은 생각은 아닙니다.
답변2
가상 환경에서 이 작업을 수행하면 실질적인 이점을 얻을 수 있습니다. VMDK는 NAS에 저장되므로 동적으로 확장할 수 있습니다.
파티션을 사용하는 경우 LVM(및 이와 관련된 오버헤드)을 사용하고 파티션을 함께 연결해야 하거나 gparted와 같은 기능을 사용하려면 호스트(또는 사용하지 않는 경우 파일 시스템)를 종료해야 합니다.
그러나 파티션이 아닌 전체 디스크를 사용하는 경우 SCSI 디스크를 강제로 다시 검색하고 resize2fs를 사용하여 파일 시스템이 온라인 상태이고 사용 중인 동안 파일 시스템을 늘릴 수 있습니다.
답변3
이것이 Linux에 어떻게 적용될지는 확실하지 않지만 기본 ZFS의 경우 파티션이 아닌 전체 디스크에 풀을 만드는 것이 권장되는 한 가지 이유는 전자의 경우 디스크 쓰기 캐싱을 활성화할 수 있기 때문입니다.
여기에는 몇 가지 다른 이유가 언급되어 있습니다.
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools
결론: 작동하며 파일 시스템에 따라 좋은 생각일 수 있습니다.
답변4
아직 나열되지 않은 대답은 파티션을 생성하지 않으면 커널이 이를 감지할 때까지 기다릴 필요가 없다는 것입니다. 이는 재부팅 후에만 감지될 수 있습니다.
한 가지 사용 사례는 노드에 추가하고 처음 부팅 시 초기화하려는 EC2 EBS 볼륨일 수 있습니다.
초기화 프로세스에서 파티션을 생성하는 경우 커널이 새로 생성된 파티션을 확인하려면 재부팅이 필요할 수 있습니다. 일반적으로 다음과 같은 메시지가 표시됩니다.
오류: /dev/xvde1 파티션 수정과 관련된 오류를 커널에 알리는 중 - 장치 또는 리소스가 사용 중입니다. 이는 재부팅할 때까지 Linux가 /dev/xvde1에 대한 변경 사항을 알 수 없음을 의미합니다. 따라서 재부팅하기 전에 이를 설치하거나 어떤 방식으로든 사용해서는 안 됩니다.
이 경우 초기화 프로세스를 다시 시작하고 새로 생성된 파티션에 파일 시스템을 계속 추가해야 합니다.
파티션이 하나만 필요하다는 것을 알고 있다면 재부팅할 필요가 없도록 건너뛰는 것이 좋습니다.