파티션이없는 파일 시스템의 장점

39

몇 주 전에는 본 적이없는 무언가가 발생했습니다. 파일 시스템 (ext3)은 파티션없이 스토리지 장치에 설치되었습니다. 본질적 /dev/sdb 으로 전체 파일 시스템이었습니다. 많은 파일 시스템을 빈 공간으로 확장 할 수 있다는 것을 알고 있으므로 LVM이나 다른 종류의 볼륨 관리자를 처리하지 않고도 확장 할 수 있지만이 방법으로 저장소를 설정하면 다른 이점이 있습니까?

내가 본 구체적인 사례는 다수의 크 런칭 서버에 대한 임시 데이터 볼륨이고, 부팅 및 루트 볼륨은 완전히 다른 스토리지 장치의 기존 파티션이었습니다. -

filesystems partition lvm

— sysadmin1138
소스

"로컬 스토리지"에 대해서도 Oracle VM이이를 수행합니다.

— Nils

3

나는이 질문을 그리워하고 같은 근거를 다루는 새로운 질문을 시작했습니다 : unix.stackexchange.com/q/52389/4801 . 이 질문은 이제 종결되었지만 일부 답변은이 Q 독자에게 유용 할 수 있으며 여기에 병합 될 수 있습니다.

— dubiousjim

1

... 그리고 unix.stackexchange.com/questions/206141

— derobert

작동하지만 여기에 표시된대로 시간이 낭비되는 문제 ( access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…)로 이어집니다 .

— slm

24

장점 : 파티션 테이블에서 하나의 디스크 섹터를 낭비하지 않습니다. (예)

Pro : 디스크는 PC 스타일 파티션을 지원하지 않는 운영 체제에서 사용할 수 있습니다. (하나를 사용하는 것처럼)

단점 : 이것은 드문 일이며 공동 시스템 관리자를 혼란스럽게 할 수 있습니다. (보다?)

단점 : 다른 운영 체제를 설치하면 디스크에 가비지가 포함되어 있다고 생각할 수 있으며 잘못된 디스크를 선택하여 실수로 디스크를 덮어 쓸 수 있습니다. 반면 운영 체제는 일반적으로 해당 유형을 이해하지 못하는 파티션 만 남겨 둡니다.

관련이 없음 : 파일 시스템이 파티션에 있거나 디스크에 직접있는 경우 파일 시스템을 확장하는 것이 쉽지 않습니다. (LVM을 사용하면 더 쉬울 것입니다.)

결론 : 작동하지만 좋은 생각이 아닙니다.

— 질 'SO- 악마 그만해'
소스

2

혼란, 아호이! 내 내부 미터는 현재 "최적화 시도가 잘못되었습니다".

— sysadmin1138

6

또 다른 단점 : 나중에 파티션을 두 개로 나누기가 더 어려워집니다.

— Kim

3

이 수퍼 유저 Q & A를 통해 좋은 예제를 사용 hexdump하고 vs .. 설정으로 od진행되는 상황을 매우 구체적으로 보여줍니다 . /dev/sda/dev/sda1

— slm

4

먼저 파티션을 확장 할 필요가 없기 때문에 전체 디스크에서 볼륨을 확장하는 것이 조금 더 간단합니다.

— psusi

2

비상업적 환경에서 다른 OS를 설치하는 것이 적합 할 수 있습니다. 그러나 상업적 환경에서 누가 멀티 부팅합니까? 나는 이것이 정식 답변이라는 것을 두려워합니다. 그것이 의견이라는 것을 제외하고는 아무 문제가 없습니다. 나는 파티션이없는 디스크 사용에 대해 고민하고 있지만 몇 가지 좋은 이유는 다음과 같습니다.

— Graham Nicholls

18

이것이 Linux에 어떻게 적용되는지 확실하지 않지만 기본 ZFS에서는 파티션이 아닌 전체 디스크에 풀을 작성하는 것이 좋습니다. 이전의 경우 디스크 쓰기 캐시를 사용할 수 있습니다.

다른 몇 가지 이유도 여기에 언급되었습니다.

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

결론 : 작동하며 파일 시스템에 따라 좋은 아이디어 일 수 있습니다.

— 젤리아 그레
소스

알아 둘만 한. 이 특정한 경우 에는 클라우드에 있었습니다 ! 스토리지는 시스템 설정에 따라 상당히 추상화됩니다.

— sysadmin1138

1

디스크 쓰기 캐시는 파티션 테이블이 사용 중인지 여부와 관계가 있습니까?

— psusi

3

파티션 레벨에서 쓰기 캐시를 사용할 수 없습니다. 활성화되면 디스크 전체에 영향을줍니다. 파일 시스템이 전체 디스크를 사용하는 경우 해당 디스크를 "소유"하므로 부수적 위험없이 해당 캐시를 켜거나 끌 수 있습니다. 그렇지 않으면 캐시를 자체적으로 비활성화해야하는 다른 디스크 소비자에게 영향을 줄 수 있습니다.

— jlliagre

4

물론, 파일 시스템이나 원시 장치 소비자 요구 사항을 모르고 OS가 맹목적으로 캐시를 켜는 것은 신뢰할 수있는 방법이 아닙니다. 커밋 된 트랜잭션이 메모리뿐만 아니라 디스크에 있는지 확인해야하는 데이터베이스와 같은 응용 프로그램이 있습니다.

— jlliagre 2016 년

1

@psusi fsync가 디스크 캐시를 플러시할지 여부는 파일 시스템에 따라 달라집니다.

— jlliagre

16

이것이 가상 환경에서 이루어질 때 진정한 이점을 봅니다. VMDK는 NAS에 저장되므로 동적으로 확장 할 수 있습니다.

파티션을 사용하는 경우 LVM (및 이와 관련된 오버 헤드)을 사용하고 파티션을 함께 연결하거나 gparted와 같은 것을 사용하려면 호스트 (또는 사용하지 않는 경우 파일 시스템)를 중단해야합니다.

그러나 파티션 대신 전체 디스크를 사용하는 경우 SCSI 디스크를 강제로 다시 스캔하고 resize2fs를 사용하여 파일 시스템이 온라인 상태 일 때 (그리고 사용 중일 때) 파일 시스템을 확장 할 수 있습니다.

— 닉 가스 파로 비치
소스

좋은 지적! 가상 디스크 (필요에 따라 생성, 제거 및 크기 조정 가능)를 사용하면 파티션이 쓸모없는 계층 인 것 같습니다.

— pabouk

11

파티션을 만들지 않고 디스크 장치에 파일 시스템을 배치하는 것은 드문 일이 아닙니다.

장점 :

어쨌든 전체 공간을 사용하려면 파티션 도구를 사용하여 시간을 낭비 할 필요가 없습니다.
'표준'파티션 형식의 비 호환성에 대해 걱정할 필요가 없습니다 (btw, 표준, DOS 형식, BSD 형식의 파티션 형식은 무엇입니까?) 512 바이트 논리 섹터!
(현재) 특이한 섹터 크기 (예 : 4k)를 가진 드라이브에서 파티션으로 인한 정렬 문제에 대해 걱정할 필요가 없습니다. 물론, 현재 배포판은 다른 섹터 크기와 올바르게 정렬되는 파티셔닝 도구를 제공해야합니다.

원시 장치에서 파일 시스템의 크기를 조정할 수 있다고해서 좋은 이유는 아닙니다. 이렇게 저장 한 공간은 다른 용도로는 사용할 수 없습니다. 따라서 전체 장치에서 파일 시스템을 직접 만들 수 있습니다.

— 막스 sch 프
소스

2

나열되지 않은 대답은 파티션을 만들지 않으면 다시 부팅 한 후에 만 커널이이를 감지 할 때까지 기다릴 필요가 없다는 것입니다.

하나의 사용 사례는 노드에 추가하고 첫 번째 부팅시 초기화하려는 EC2 EBS 볼륨 일 수 있습니다.

초기화 프로세스에서 파티션을 생성하면 커널을 재부팅하여 새로 생성 된 파티션을 볼 위험이 있습니다. 일반적으로 다음과 같은 메시지가 표시됩니다.

오류 : / dev / xvde1 파티션에 대한 수정 사항을 커널에 알리는 오류-장치 또는 리소스가 사용 중입니다. 이것은 리눅스가 재부트 할 때까지 / dev / xvde1에 대한 변경 사항을 알지 못하므로 재부트하기 전에 마운트하거나 사용해서는 안됩니다.

이 경우 초기화 프로세스는 재부팅을 수행 한 다음 파일 시스템을 새로 생성 된 파티션에 계속 추가해야합니다.

단일 파티션 만 필요하다는 것을 알고 있다면이를 건너 뛰어 재부팅해야 할 위험을 감수하지 않아도됩니다.

— 로에 체
소스