나에게 파티션 판매

필자는 드라이브를 파티셔닝하는 데 특히 Unixy OS (/ usr, / var 등)에서 왜 그런 열정이 있는지 궁금해했습니다. 이것은 Windows 설치에서 공통적 인 주제가 아닌 것 같습니다.

파티셔닝은 하나의 파티션을 채울 가능성을 크게 증가시키는 반면 다른 파티션은 많은 여유 공간을 가지고있는 것으로 보입니다. 분명히 이것은 신중한 디자인과 계획으로 예방할 수 있지만 상황은 바뀔 수 있습니다. 나는 기계에서 여러 번, 주로 다른 사람들이 설치 한 기계에서, 또는 해당 OS의 기본 설치 설정에서 이것을 경험했습니다.

내가 들었던 또 다른 주장은 백업을 단순화한다는 것입니다. 백업을 어떻게 단순화합니까? 또한 신뢰성이 향상된다고 들었습니다. 또 어떻게?

디스크 스토리지에서 겪은 거의 100 %의 문제는 디스크의 물리적 장애와 관련이 있습니다. 동일한 디스크의 한 파티션에서 다른 파티션으로 데이터를 이동하거나 복사 할 때 디스크가 스 래싱하기 때문에 파티셔닝이 하드웨어 오류를 가속화 할 수 있다고 주장 할 수 있습니까?

나는 배를 너무 많이 흔들지 않으려 고합니다. 오래된 관리자 관행에 대한 정당성을보고 싶습니다.

• 더 빠른 fsck. 어떤 이유로 시스템이 실패한다고 가정하고 재부팅 할 때 fsck를 실행해야합니다. fsck가 영구적으로 사용할 수있는 매우 큰 파티션을 사용하면 전체 시스템의 fsck가 완료 될 때까지 시스템에서 아무것도 작동하지 않습니다. 루트 파티션이 아주 작도록 시스템을 분할하면 더 큰 볼륨의 fsck가 완료 될 때까지 시스템을 시작하고 일부 기본 서비스를 실행할 수 있습니다.
  • 시스템에 작은 드라이브가 있거나 시스템에 하나의 서비스 만있는 경우에는 이것이 중요하지 않을 수 있습니다.
  • 저널 파일 시스템의 경우 대부분의 경우 중요하지 않지만 때로는 저널 파일 시스템의 경우 전체 fsck를 실행해야합니다.
• fs 읽기 전용을 마운트 할 수 있으므로 보안이 향상되었습니다.
  • 예를 들어 정상적인 사용 중에는 아무도 / usr에 쓸 필요가 없습니다. 따라서 파일 시스템을 마운트하여 읽기 전용이 아닌 이유는 무엇입니까? 파일 시스템을 작성할 필요가 없을 때 파일 시스템을 읽기 전용으로 설정하면 일부 스크립트-키디 공격을 막을 수 있습니다.
  • 업데이트를 적용해야 할 때 시스템을 읽기 / 쓰기로 다시 마운트해야하므로 시스템 유지 관리가 더 어려워 질 수 있습니다.
• 특정 서비스 / 사용에 대한 성능, 기능 향상
  • 일부 파일 시스템은 특정 서비스 / 응용 프로그램에 더 적합하거나 경우에 따라 파일 시스템이 더 잘 작동하도록 파일 시스템을 구성 할 수 있습니다. 작은 파일이 많은 파일 시스템이 있고 더 많은 inode가 필요할 수 있습니다. 또는 큰 파일 몇 개, 가상 디스크 이미지를 저장해야 할 수도 있습니다.

많은 파티션을 설정하는 것이 모든 시스템에서 수행해야 할 작업이라고 생각하지 않습니다. 개인적으로 대부분의 Linux 서버에서 하나의 큰 파티션을 설정했습니다. 대부분의 시스템에는 작은 드라이브가 있으며 단일 용도이며 일부 인프라 역할 (dns, dhcp, 방화벽, 라우터 등)을 제공하기 때문입니다. 파일 서버에서 시스템과 데이터를 분리하기 위해 파티션을 설정합니다.

동일한 디스크의 한 파티션에서 다른 파티션으로 데이터를 이동하거나 복사 할 때 디스크가 스 래싱하기 때문에 파티셔닝이 하드웨어 오류를 가속화 할 수 있다고 주장 할 수 있습니까?

잘 파티션 된 시스템이 실패 할 가능성이 높아질 것입니다.

/ home /을 별도로 유지해야하는 한 가지 이유는 운영 체제를 다시 설치하고 사용자 데이터 손실에 대해 걱정할 필요가 없기 때문입니다. 그 외에도 모든 것을 읽기 전용 또는 noexec로 마운트하는 데 많은 보안이 필요합니다. 사용자가 코드를 작성할 수있는 곳에서 코드를 실행할 수없는 경우 공격 벡터가 줄어 듭니다.

한 파티션에 디스크 공간이 부족하지만 다른 파티션에 디스크 공간이 있다는 단점은 심각한 성가신 일이기 때문에 공용 컴퓨터에서만 그 문제를 해결할 것입니다. 동적으로 파티션의 크기를 쉽게 조정할 수 있어야하는 소프트웨어 RAID 또는 ZFS와 같이이 문제를 해결할 수있는 방법이 있지만 경험이 없습니다.

• 백업 단순화

원하지 않는 항목이 아니라 원하는 것을 백업 (덤프 파일 등을 통해) 할 수 있습니다. dump (1)은 tar (1)보다 나은 백업 시스템입니다.

• 파티션 채우기

그것은 또한 파티셔닝에 대한 논쟁입니다. homedir을 채우는 사용자는 서버를 망가 뜨리지 않고 웹 서버를 중단 시키며 로그가 발생하지 않도록하고 루트가 로그인하지 않도록합니다.

또한 데이터 섹션 (예 : / home)을 다른 디스크로보다 투명하게 이동할 수 있습니다. 복사하여 마운트하십시오. 쉐도우 복사본 / 스냅 샷 / 무엇이든 허용하는 것을 사용하는 경우에도 가능합니다.

나는 항상 / var를 별도의 파티션에 보관하도록 배웠으므로 제어 로그 파일을 벗어나면 전체 드라이브가 아닌 단일 파티션을 막을 수 있습니다. 다른 시스템과 동일한 공간에 있고 전체 디스크를 100 % 채우면 충돌이 발생하여 불쾌한 복원을 수행 할 수 있습니다.

Zoredache가 제시 한 모든 주장은 유효합니다. 하나는 세부 사항에 약간의 문제가있을 수 있습니다 (기계를 더 빨리 작동 시키면 다른 파일 시스템을 fsck'ing하는 것은 시스템의 이유가 다른 파일 시스템에있는 경우별로 좋지 않습니다) ; 그러나 그것들은 모두 사실에 대한 약간의 정당화입니다.

아주 오래된 시절에는 별도의 파티션에 파일 시스템이 없었습니다. 디스크가 실제로 작기 때문에 별도의 디스크에 파일 시스템이있었습니다. 10MB를 생각하십시오. (1) 작은 / 파티션, / var 디스크, / usr 디스크, / tmp 디스크 및 / home 디스크가 있습니다. 더 많은 공간이 필요하면 다른 디스크를 구입하십시오.

그런 다음 "큰"50MB 디스크는 moon 프로그램보다 비용이 적게 들기 시작했고 갑자기 전체 시스템을 사용 가능한 공간이있는 하나의 디스크에 넣을 수있게되었습니다.

그럼에도 불구하고 디스크 크기는 컴퓨터가 생성 할 수있는 것보다 작고 / var 및 / opt 및 / home을 분리하여 컴퓨터를 채우지 않아도 컴퓨터를 다운시키지 않는 것이 좋습니다.

오늘날 엔터프라이즈 환경에서는 OS를 분할하지 않습니다. 특히 사용자가 생성 한 경우 데이터가 분할됩니다. 그러나 종종 그것은 일종의 고속 및 / 또는 중복 디스크 어레이에 있기 때문입니다. 그러나 / var 및 / usr은 모두 /와 동일한 파티션에 있습니다.

가정 환경에서 / home은 별도의 디스크 / 배열에 있어야하므로 원하는 OS 버전을 설치 / 업그레이드 / 중단 / 수정할 수 있습니다.

그 이유는 / var 또는 / usr 또는 나무가 무엇이든 짐작할 수 있더라도 엄청나게 잘못되었거나 엄청나게 과도하게 커밋하기 때문입니다. 내 오래된 학교 동료 중 한 명이 파티션을 나누면서 맹세하며, 내가 만든 시스템에서 180 일 fsck를 거치게되면 항상 그에게 슬픔을 느낍니다. 그러나 나는 한 번에 내 경력 전체를 채우고 무언가를 채우고 시스템을 무너 뜨린 횟수를 계산할 수 있으며, 올해 한 손을 다른 사람의 / var은 1GB 이상일 필요가 없으며 잘못되어 시스템의 다른 곳에서 전체 / var 및 '00s의 무료 GB를 쳐다 볼 수 있습니다. 모두가 달에 있었을 수도 있습니다. 그들은 나를 잘합니다.

오늘날의 큰 디스크 세계에서는 OS 트리를 분할해야 할 실질적인 이유가 없습니다. 사용자 데이터입니다. 그러나 / var 및 / usr 및 / var / spool 등을위한 별도의 파티션? 아니.

(1) = 그리고 나는 그 크기를 고르면 10MB 라는 의견에 누군가를 데려 갈 것 입니까? 사치. 왜 우리 디스크가 ...

에 회신하여 :

파티셔닝은 하나의 파티션을 채울 가능성을 크게 증가시키는 반면 다른 파티션은 많은 여유 공간을 가지고있는 것으로 보입니다.

Linux 시스템에서는이를 방지하기 위해 LVM (논리 볼륨 관리)이 사용됩니다. 대부분의 파일 시스템은 크기 조정을 허용합니다 (일부는 온라인). 다른 용도로 다른 파티션을 만들고 다른 파일 시스템으로 포맷합니다 (예 : 빠르게 삭제할 수있는 큰 다운로드 파일의 경우 xfs). 더 많은 공간이 필요하십니까? 새 드라이브를 마운트하고 데이터를 이동 한 다음 데이터가 있던 위치에 마운트하십시오. 사용자 및 응용 프로그램과 완벽하게 호환됩니다.

LVM을 사용하면 디스크 또는 파티션을 볼륨 그룹에 추가 한 다음 해당 그룹에 논리 볼륨을 생성 할 수 있습니다. 볼륨 그룹에 여유 공간을두면 채워지는 파티션을 늘릴 수 있습니다. 파일 시스템이이를 지원하는 경우 (ext3, ext4, reiserfs) 할당 한 파티션을 축소 할 수 있습니다.

예를 들면 다음과 같습니다. / dev / sda1에 부트 파티션을 만듭니다. 포맷되지 않은 두 번째 파티션 인 / dev / sda2를 만듭니다.

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

/ downloads에 더 많은 공간이 필요한 경우 (파일 시스템이 마운트 된 동안) :

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

이제 150GB 다운로드 파티션이 있습니다. 집과 비슷합니다. 사실 저는 오늘 ext4 lvm "파티션"의 크기를 조정했습니다. 다른 한편으로, 논리 볼륨은 실제로 파티션이 아니며 파티션에 대해 개인적인 경험으로 잘못된 크기의 지브가된다고 말한 것 (가치보다 더 많은 문제).

전통적인 유닉스 파티셔닝 구성표는 예전처럼 유용하지 않은 구식 사례입니다. 유닉스 시스템 가동 시간이 몇 년 만에 측정 된 당시, 수백 명의 사용자가 쉘을 가지고 놀았으며 / usr을 읽기 전용으로 마운트하는 것이 시스템을 보호하는 유용한 방법이었습니다. 이제 패치하기 위해 파일 시스템을 다시 마운트하면 노동 집약적이고 유용하지 않은 것으로 보입니다.

좋은 시절에 대학에서 유닉스 클러스터는 표준 유닉스 도구를 갖춘 읽기 전용 파일 시스템을 가지고 있었고 애드온 응용 프로그램은 / usr / local에 있었고 NFS는 AFS 파일 시스템이었습니다. 고속, 4Mb 또는 10Mb 네트워크를 통해 앱을 실행할 수있을 때 클러스터의 12 개 상자에서 소프트웨어를 다시 컴파일하고 싶어했던 편의가 그 중 하나였습니다. 오늘날 적절한 패키지 관리자와 저렴한 디스크가 많기 때문에 그렇게 큰 문제는 아닙니다.

베리타스 볼륨 관리자가 1999 년경 썬 박스에서 프로세스가 바뀌기 시작한 것으로 생각되어 디스크를 옮기는 데 따른 어려움을 크게 줄였습니다.

오늘은 파티셔닝을 생각할 때 데이터 보호 및 성능 측면에서 생각하고 있습니다. 예시적인 예 :

• Tier 1 SAN은 매우 빠르며 가용성이 높으며 (5 9) 복제되고 비용이 많이 듭니다. 미션 크리티컬 데이터베이스 또는 트랜잭션 로그가 존재합니다.
• Tier 2 SAN은 빠르고 사용 가능하며 (4 9) 비싸다. 애플리케이션 또는 우선 순위가 낮은 데이터는 여기에 있습니다.
• Tier 3 SAN을 저렴하게 사용할 수 있습니다 (4 9). 성능에 민감하지 않은 것들이 거기에 있습니다.

이러한 고려 사항은 Windows에도 적용됩니다. 약 40 만 개의 클라이언트를 관리하는 SCCM 서버가 있습니다. 데이터베이스 및 로그는 mega-buck IBM DS8000 디스크에 있습니다. 소프트웨어 패키지는 GB 당 비용이 60 % 저렴하고 느린 SATA 디스크가있는 EMC Celerra에 있습니다.

이 질문이 OS별로 다르지 않다는 것을 알고 있습니다.

Windows에서는 모든 컴퓨터에 가능한 한 적은 수의 파티션을 제공하지만 SYSTEM 및 DATA는 두 개 이상입니다. 머신에 두 개의 물리적 디스크가있는 경우 하나 (작은)는 SYSTEM이고 다른 하나는 DATA입니다. 디스크가 하나만 있으면 두 개의 파티션으로 나눕니다.

그 이유는 하나입니다-컴퓨터를 다시 설치해야 할 때 (그리고 그런 시간이있을 것입니다), SYSTEM 파티션의 내용에 대해 걱정할 필요가 없습니다. 새로 설치하십시오. 이것은 물론 내 문서 (바람직하게는 데스크톱도)가 DATA의 폴더에 매핑되어야하지만 특히 Vista 이상에서는 쉽게 수행 할 수 있음을 의미합니다.

또한 (GAMES, MUSIC, MOVIES 등과 같은) 더 많은 partiton을 만들려고 시도했지만 그중 일부만 다른 사람에게 넘쳐서 순서보다 더 많은 혼란을 초래했습니다.

내가 넣어 (하나의 대용량 디스크를 사용할 수있는 가정) home과 var별도의 파티션에 "제어 [사용자 | 로그 파일]에서 모든 공간을 채우고"제어 문제를, 그리고 감동 집없이 쉽게 OS 업그레이드를 허용하지만, 떠나 함께 쉬십시오.

구형 하드웨어에서는 언젠가 boot는 부트 로더가 커널 이미지에 접근 할 수 있도록 별도의 파티션 이 필요했습니다 .

하나의 디스크 채우기에 대해 언급하고 다른 디스크에는 여유 공간이 있습니다. 즉, 파티션하는 이유 중 하나입니다. 특정 파티션 이 채워 지지 않도록 할 수 있기 때문 입니다. 할당량을 관리하는 방식은 다른 파티션에서 모든 사용자에게 0 할당량을 할당해야합니다. 디렉토리를 찾을 수있는 경우 파일을 숨기지 않도록해야합니다. 쓸 수 있었다.

백업 단순화-각 파티션의 최대 크기를 알고 있다면 단일 테이프에 꼭 맞는 크기인지 확인하고 정해진 시간 안에 완료 할 수 있습니다.

안정성에 관해서는, 내가 생각할 수있는 유일한 것은 모니터링입니다. 주어진 파티션이 언제 성장해야하는지 더 쉽게 알 수 있고 조사 할 이유가 있습니다.

...이 모든 것을 말하지만, 우리는 각 사용자가 공유 컴퓨터에서 20MB의 할당량을 거의받지 않은 날과는 거리가 멀습니다. 오래된 습관 중 일부는 의미가 없지만 프로세스가 미쳐서 / var을 채우면 /가 채워지고 멈추게 될 때 생산 기계에 대한 보호가 그렇게 나쁘지는 않습니다. .

집에는 파티션이 있지만 설치된 OS를 더 쉽게 관리 할 수 ​​있도록하기 위해서입니다.

개인적으로 나는 내 아이의 컴퓨터에서만 파티셔닝을 사용합니다. OS를위한 큰 파티션과 OS 파티션의 이미지를위한 작은 파티션을 생성하여 머신이 부팅되면 이미지에서 신속하게 복원 할 수 있습니다.

엔터프라이즈 환경에서는 파티셔닝에 대한 설득력있는 주장을 들어 본 적이 없습니다.

중재에있는 모든 것은 좋은 일입니다. 디스크가 가득 차거나 파일 시스템이 손상되는 등 오류가있을 때 문제를 격리하는 좋은 도구가 될 수 있습니다.

하드웨어 장애와 혼용하지 마십시오. 하드웨어 중복 (RAID)으로 처리해야합니다.

그러나 오늘날의 파일 시스템은 실패 빈도가 낮습니다. 심지어 ZFS와 같은 온라인 무결성 검사도 수행합니다. 따라서 오프라인 fsck가 언젠가는 사라질 것입니다 ...

반면에, 과도하게 행동한다는 것은 결국 더 많은 일 (귀하와 팀을위한)을 의미 할뿐입니다.