Windows의 기본 파티션 / 드라이브 C :를 작게 유지해야하는 이유가 있습니까?

거의 20 년 전의 일에서 IT 전문가들은 다른 파티션에 비해 Windows의 주 파티션 (C 드라이브) 크기를 극히 작게 유지했습니다. 그들은 이것이 속도를 늦추지 않고 최적의 속도로 PC를 실행한다고 주장했다.

그러나 단점은 C : 드라이브가 작게 유지되면 쉽게 채워지고 곧 공간이 부족하여 새 소프트웨어를 설치할 수 없다는 것입니다. D : 드라이브에 소프트웨어를 설치하더라도 소프트웨어의 일부는 항상 C :에 복사되어 채워집니다.

내 질문은이 연습이 여전히 좋은가요? 왜 그런지. 주요 장점은 무엇입니까? 한 가지 확실한 것은 1 차 파티션이 충돌하면 2 차적으로 데이터가 안전하다는 것입니다.

이 질문을하는 이유는 Visual Studio를 업데이트하려고하기 때문에 기본 파티션에 24MB 만 남아 있기 때문에 할 수 없기 때문입니다.

거의 20 년 전의 일에서 IT 전문가들은 다른 파티션에 비해 Windows의 주 파티션 (C 드라이브) 크기를 극히 작게 유지했습니다. 그들은 이것이 속도를 늦추지 않고 최적의 속도로 PC를 실행한다고 주장했다. [...] 내 질문은이 연습이 여전히 좋은가요?

일반적으로 : 아니요 .

이전 Windows 버전에서는 주로 Windows에서 사용 하는 FAT 파일 시스템이 큰 파일 시스템을 제대로 지원하지 않았기 때문에 큰 드라이브 (보다 정확하게 : 큰 파일 시스템)에서 성능 문제가 발생했습니다 . 그러나 모든 최신 Windows 설치는 NTFS를 대신 사용하여 이러한 문제를 해결했습니다. 예를 들어 NTFS 용량이 5 ~ 6TB보다 큰 볼륨에서 크게 저하됩니까? 테라 바이트 크기의 파티션도 일반적으로 문제가되지 않음을 설명합니다.

요즘에는 일반적으로 하나의 큰 C : 파티션을 사용하지 않는 이유가 없습니다. Microsoft 자체의 설치 프로그램은 기본적으로 하나의 큰 C : 드라이브를 작성합니다. 별도의 데이터 파티션을 만들어야하는 충분한 이유가있는 경우 설치 관리자가이를 제공합니다. Microsoft에서 문제를 일으키는 방식으로 Windows를 설치해야하는 이유는 무엇입니까?

여러 드라이브에 대한 주된 이유는 복잡성이 증가하기 때문입니다. IT에서는 항상 좋지 않습니다. 다음과 같은 새로운 문제가 발생합니다.

• 어떤 드라이브에 어떤 파일을 넣을지 결정해야합니다 (설정을 적절하게 변경하려면 설치 프로그램에서 항목을 클릭하십시오).
• 일부 (잘못 작성된) 소프트웨어는 C와 다른 드라이브에 넣지 않는 것이 좋습니다.
• 한 파티션에는 여유 공간이 너무 적고 다른 파티션에는 여전히 여유 공간이 있으므로 수정하기가 어려울 수 있습니다

여러 파티션이 여전히 이해되는 특별한 경우 가 있습니다 .

• 이중 부팅을하려면 각 OS 설치마다 별도의 파티션이 필요하지만 설치마다 하나의 파티션 만 필요합니다.
• 하나 이상의 드라이브 (특히 SSD 및 HD와 같은 다른 특성을 가진 드라이브)가있는 경우 어디로 갈 것인지 선택하고 선택할 수 있습니다.이 경우 드라이브 C :를 SSD 및 D에 배치하는 것이 좋습니다. : HD에서.

소규모 / 별도의 파티션을 위해 종종 제기 된 몇 가지 주장을 해결하려면 :

• 작은 파티션은 백업하기가 더 쉽습니다.

어쨌든 모든 데이터를 실제로 백업해야 하므로 파티션간에 데이터를 분할해도 실제로 도움이되지 않습니다. 또한 실제로 필요한 경우 내가 아는 모든 백업 소프트웨어를 사용하면 파티션의 일부를 선택적으로 백업 할 수 있습니다.

• 한 파티션이 손상 되어도 다른 파티션은 여전히 ​​정상일 수 있습니다

이것이 이론적으로 사실이지만, 손상이 하나의 파티션으로 제한되지는 않을 것입니다 (그리고 문제가 발생했을 때이를 확인하기가 더 어렵습니다). 또한 중복 백업이 양호하면 일반적으로 추가 된 안전성이 작기 때문에 귀찮게됩니다. 그리고 백업이 없으면 훨씬 더 큰 문제가 있습니다 ...

• 모든 사용자 데이터를 데이터 파티션에두면 사용자 데이터가 없으므로 OS 파티션을 지우고 다시 설치하거나 백업하지 않을 수 있습니다

이론 상으로는 이것이 사실이지만 실제로는 많은 프로그램이 C :를 구동하기 위해 설정 및 기타 중요한 데이터를 씁니다. 따라서 IMHO 이것에 의존하는 것은 매우 위험합니다. 또한 좋은 백업이 필요하므로 (위 참조) 다시 설치 한 후 백업을 복원 할 수 있으므로 동일한 결과를 얻을 수 있습니다 (보다 안전). 최신 Windows 버전은 이미 사용자 데이터를 별도의 디렉토리 (사용자 프로필 디렉토리)에 보관하므로 선택적으로 복원 할 수 있습니다.

참조 는 Windows 시스템과 동일한 파티션에 소프트웨어를 설치할 것인가? 자세한 내용은.

이 관행의 역사적 이유는 회전 자기 HDD의 성능 특성에 기인합니다. 순차 액세스 속도가 가장 높은 디스크 회전 영역은 가장 바깥 쪽 섹터 (드라이브 시작 부근)입니다.

운영 체제에 전체 드라이브를 사용하는 경우 조만간 (업데이트 등을 통해) OS 파일이 디스크 표면 전체에 분산됩니다. 따라서 OS 파일이 물리적으로 가장 빠른 디스크 영역에 유지되도록하려면 드라이브 시작 부분에 작은 시스템 파티션을 만들고 나머지 드라이브를 원하는만큼 데이터 파티션에 분산시킵니다.

탐색 대기 시간은 부분적으로 헤드가 얼마나 멀리 이동해야하는지에 따라 달라 지므로 작은 파일을 모두 서로 가깝게 유지하면 회전 드라이브에도 유리합니다.

이 사례는 SSD 스토리지의 출현으로 모든 이유를 잃었습니다.

Windows의 기본 파티션 / 드라이브 C :를 작게 유지해야하는 이유가 있습니까?

몇 가지 이유는 다음과 같습니다.

1. 모든 시스템 파일과 OS 자체는 기본 파티션에 있습니다. 부팅 가능한 파티션을 계속 방해하고 파일을 혼합하면 실수로 시스템 파일이나 폴더를 삭제하는 등의 실수로 이어질 수 있기 때문에 다른 소프트웨어, 개인 데이터 및 파일과 파일을 분리하는 것이 좋습니다. 조직이 중요합니다. 그렇기 때문에 기본 파티션의 크기가 작아서 사용자가 모든 데이터를 덤프하지 못하게합니다.
2. 백업 -시스템의 목적에 따라 큰 파티션보다 작은 파티션을 백업하고 복구하는 것이 훨씬 쉽고 빠르며 효과적입니다. 의견에서 @computercarguy 가 언급했듯이 필요하지 않은 경우 전체 파티션을 백업하는 것보다 특정 폴더와 파일을 백업하는 것이 좋습니다.
3. 그것은 수 단단하게 눈에 띄는 방식으로, 그러나, 성능을 향상시킬 수 있습니다. 에 NTFS의 파일 시스템, 거기에 소위 마스터 파일 테이블 각 파티션에, 그리고 그 파티션에있는 모든 파일에 대한 메타 데이터를 포함합니다 :

   파일 이름, 타임 스탬프, 스트림 이름 및 데이터 스트림이 상주하는 클러스터 번호 목록, 인덱스, 보안 식별자 및 "읽기 전용", "압축", "암호화"등과 같은 파일 속성을 포함하여 볼륨의 모든 파일을 설명합니다.

이 수 정말 변화를하지 않는 한, 눈에 띄지 불구하고, 따라서이 무시 될 수있는 장점을 소개합니다. @ WooShell의 대답 은 여전히 ​​무시할 수 있지만 성능 문제와 관련이 있습니다.

또 한가지 주의는 , SSD가 + HDD를 갖는 경우는 HDD에서 SSD와 모든 개인 파일 / 데이터에 OS를 저장하는 방법이 더 나은 것입니다. 대부분의 개인 파일에 SSD를 사용하는 경우 성능 향상이 필요하지 않을 것입니다. 소비자 급 솔리드 스테이트 드라이브에는 일반적으로 공간이 많지 않으므로 개인 파일로 채우려 고하지 않습니다. .

누군가이 연습이 왜 수행되고 여전히 유효한지 설명 할 수 있습니까?

그 이유에 대해 설명했습니다. 그리고 예, 더 이상 좋은 습관은 아니지만 여전히 유효합니다. 가장 눈에 띄는 단점은 최종 사용자가 응용 프로그램에서 파일 설치를 제안하는 위치를 추적하고 해당 위치를 변경해야한다는 것입니다 (특히 전문가 / 고급 설치가 옵션 인 경우 거의 모든 소프트웨어 설치 중에 가능). t는 OS가 때때로 업데이트해야하기 때문에 채우지 않고 다른 단점은 한 파티션에서 다른 파티션으로 파일을 복사 할 때 실제로 파일을 복사해야하지만 동일한 파티션에있는 경우 MFT를 업데이트하고 메타 데이터는 전체 파일을 다시 쓸 필요가 없습니다.

불행히도 이들 중 일부는 더 많은 문제를 일으킬 수 있습니다.

1. 구조의 복잡성을 증가시켜 관리하기가 더 어렵고 시간이 많이 걸립니다.
2. 일부 응용 프로그램은 다른 파티션에 설치되어 있어도 파일 / 메타 데이터를 시스템 파티션 (파일 연결, 상황에 맞는 메뉴 등)에 기록하므로 백업하기가 더 어려워 파티션 간 동기화에 실패 할 수 있습니다. (@Bob의 의견 덕분에)

발생한 문제를 피하려면 다음을 수행해야합니다.

1. 항상 다른 파티션에 응용 프로그램을 설치하십시오 (기본 설치 위치 변경).
2. 부팅 가능한 파티션에는 중요한 소프트웨어 만 설치하십시오. 불필요하고 중요하지 않은 다른 소프트웨어는 소프트웨어 외부에 보관해야합니다.

또한 작은 기본 파티션을 가진 여러 파티션을 갖는 것이 가장 좋습니다. 그것은 모두 시스템의 목적에 달려 있으며 파일을 구성하는 더 좋은 방법을 소개하지만 현재 Windows 시스템에서는 전문가보다 더 많은 단점이 있습니다.

참고 : 앞에서 언급했듯이 부팅 가능한 파티션에 장애가 발생하는 경우 별도의 파티션에있는 데이터를 안전하게 유지합니다.

저는 소프트웨어 개발자이지만 "정규"/ 백 오피스 IT 작업을 수행하는 데 시간을 보냈습니다. 나는 일반적으로 OS와 응용 프로그램을 C : 드라이브에 보관하고 개인 파일은 D : 드라이브에 보관합니다. 이들은 반드시 별도의 물리적 드라이브 일 필요는 없지만, 현재는 "시스템"드라이브 (C :)로 비교적 작은 SSD를 사용하고 있으며 "일반"디스크 드라이브 (예 : 회전 마그네틱 플래터)를 "홈"으로 사용하고 있습니다. 드라이브 (D :).

모든 파일 시스템은 조각화 될 수 있습니다. SSD의 경우 이것은 기본적으로 문제가 아니지만 여전히 기존 디스크 드라이브의 문제입니다.

조각화로 인해 시스템 성능이 크게 저하 될 수 있습니다. 예를 들어, 드라이브 조각 모음 후 대규모 소프트웨어 프로젝트의 전체 빌드가 50 % 이상 개선되었다는 사실을 발견했습니다. 문제의 빌드가 한 시간 동안 더 나아 졌으므로 사소한 차이 가 아니 었 습니다.

개인 파일을 별도의 볼륨에 보관하면 다음을 발견했습니다.

• 시스템 볼륨이 거의 빠르게 (또는 심각하게) 조각화되지 않습니다.
• 모든 볼륨이있는 단일 볼륨보다 두 개의 개별 볼륨을 조각 모음하는 것이 훨씬 빠릅니다. 각 볼륨은 결합 된 볼륨만큼 20 % -25 %가 걸립니다.

여러 버전의 Windows가 설치된 여러 세대의 PC에서 이것을 관찰했습니다.

(평론가가 지적했듯이, 이것은 또한 백업을 용이하게하는 경향이 있습니다.)

필자가 사용하는 개발 도구는 많은 수의 임시 파일을 생성하는 경향이 있으며 이는 단편화 문제에 크게 기여하는 것으로 보입니다. 따라서이 문제의 심각성은 사용하는 소프트웨어에 따라 다릅니다. 당신은 차이를 느끼지 못할 수도 있습니다. (그러나 비디오 / 오디오 구성 및 편집과 같은 I / O 집약적 인 다른 활동이 있으며 사용 된 소프트웨어에 따라 많은 수의 임시 / 중간 파일이 생성 될 수 있습니다. 이 기능은 한 클래스의 사용자에게만 영향을줍니다.

주의 사항 : 최신 버전의 Windows (8 이상)에서는 C : 이외의 볼륨에있는 사용자 폴더가 더 이상 공식적으로 지원되지 않기 때문에 훨씬 더 어려워졌습니다. Windows 7에서 Windows 10으로 전체 업그레이드를 수행 할 수 없지만 YMMV (사용자 폴더를 재배치하는 방법에는 여러 가지가 있으며 어떤 영향을 받는지 모르겠습니다) .

추가 참고 사항 : 기존 드라이브에서 두 개의 개별 볼륨을 유지 관리하는 경우 D : 볼륨에서 페이지 파일을 설정해야 할 수 있습니다. WooShell의 답변에 설명 된 이유로 페이지 파일에 쓸 때 검색 시간이 줄어 듭니다.

짧은 대답 : 더 이상은 아닙니다.

내 경험 (20 년 이상의 IT 관리 업무)에서이 관행의 주요 이유 (아래에 나열되어 있음)는 사용자가 기본적으로 데이터와 하드 드라이브 공간으로 Windows를 신뢰하지 않았기 때문입니다.

Windows는 오랫동안 안정성을 유지하고 자체적으로 청소하며 시스템 파티션을 건강하게 유지하고 사용자 데이터에 대한 편리한 액세스를 제공하는 것으로 악명 높았습니다. 따라서 사용자는 Windows가 제공 한 파일 시스템 계층을 거부하고 자체 외부로 롤백하는 것을 선호했습니다. 시스템 파티션은 또한 Windows를 거부하기위한 빈민가로 작용하여 제한을 벗어난 혼란을 초래할 수 있습니다.

• Microsoft의 제품을 포함하여 깨끗하게 제거되지 않거나 호환성 및 안정성 문제를 일으키는 제품이 많이 있습니다 (가장 눈에 띄는 것은 파일과 레지스트리 항목이 모두 남아 있음 및 DLL 지옥입니다)모든 성육신에서). OS에서 생성 된 많은 파일은 이후에 정리되지 않으므로 (로그, Windows 업데이트 등) 시간이 지남에 따라 OS에서 더 많은 공간을 차지합니다. Windows 95 및 XP 시대에는 OS를 한 번에 완전히 다시 설치하라는 제안이 나왔습니다. OS를 다시 설치하려면 OS 및 해당 파티션을 완전히 지우고 (파일 시스템의 모든 가짜 데이터를 정리하기 위해) 다중 파티션 없이는 불가능한 기능이 필요했습니다. 그리고 데이터를 잃지 않고 드라이브를 분리하는 것은 전문화 된 프로그램을 통해서만 가능합니다 (나쁜 섹터가 발생할 때 데이터를 사용할 수없는 상태로 두는 것). 다양한 "정리"프로그램이 문제를 완화 시켰지만, 그들의 논리는 리버스 엔지니어링에 기반하고 행동을 관찰했습니다.RegCleanMS 자체의 유틸리티는 Office 2007 릴리스 이후에 기반을 두는 레지스트리에 대한 가정을 깨뜨린 후에 시작되었습니다. 많은 프로그램이 데이터를 임의의 장소에 저장했기 때문에 사용자와 OS 데이터를 분리하기가 더 어려워 져 사용자는 OS 계층 외부에서도 프로그램을 설치할 수 있습니다.
  • Microsoft는 다양한 수준의 성공 ( 공유 DLL , Windows 파일 보호 및 그 후속 제품인 TrustedInstaller, 병렬 서브 시스템 , 버전 및 공급 업체 충돌을 방지하는 스토리지 구조의 .NET 모듈을위한 별도의 리포지토리)으로 안정성을 향상시키는 여러 가지 방법을 시도했습니다. ). 최신 버전의 Windows Installer는 기본적인 의존성 검사 (아마도 해당 기능을 포함하기 위해 마지막으로 사용되는 주요 패키지 관리자)를 가지고 있습니다.
  • 모범 사례에 대한 타사 소프트웨어 규정 준수와 관련하여,이 소프트웨어는 간결하게 작성되었지만 충분히 사용 된 소프트웨어 (또는 사용자가 새 Windows 버전으로 업그레이드하지 않음)와의 호환성을 유지하는 방식을 사용했습니다. 문서화되지 않은 API 동작, 버그를 수정하기위한 타사 프로그램의 실시간 패치 및 일부 레벨 의 레지스트리 및 파일 시스템 가상화, 타사 공급 업체가 인증 로고와 같은 조치를 준수하도록 강제 하는 것 등 OS의 주요 문제 및 해결 방법 프로그램 및 드라이버 서명 프로그램 (Vista로 시작해야 함).
• 사용자 프로필 아래의 긴 경로에 묻혀있는 사용자 데이터로 인해 경로를 찾아 지정하는 것이 불편했습니다. 경로에는 긴 이름 을 사용하고 공백 (모든 곳의 명령 셸)과 국가 문자 (포괄적 인 유니 코드 지원을 가진 최신 언어를 제외한 프로그래밍 언어의 주요 문제)가 있었고 로케일 별 (!)이며 winapi 액세스 없이는 얻을 수 없었습니다 (!!) (대본으로 국제화 노력을 죽이는 것), 모두 문제를 해결하지 못했습니다.
  따라서 별도의 드라이브의 루트 디렉토리에 데이터를 두는 것이 Windows가 제공하는 것보다 편리한 데이터 구조로 간주되었습니다.
  • 이것은 최신 Windows 릴리스에서만 수정되었습니다. 경로 자체는 Vista에서 수정되어 긴 이름을 압축하여 공백과 현지화 된 이름을 제거했습니다. 브라우징 문제는 Win7에서 수정되어 사용자 프로필의 루트와 그 아래의 대부분의 다른 디렉토리 모두에 대한 시작 메뉴 항목과 파일 선택 대화 상자의 영구 "즐겨 찾기"폴더와 같은 Downloads것을 기본값 으로 사용하여 브라우징 필요성을 저장했습니다. 그들을 위해 매번.
• 결국, MS의 노력은 결국 결실을 맺었습니다. 대략 Win7 이후 OS, 정리 유틸리티를 포함한 재고 및 타사 소프트웨어는 안정적이고 올바르게 작동하며 HDD가 충분히 크므로 OS가 일반적인 워크 스테이션의 전체 수명 동안 재설치를 필요로하지 않습니다. 또한 재고 계층 구조는 일상적으로 실제로이를 수용하고 사용할 수있을 정도로 사용 가능하고 액세스 가능합니다.

이차적 인 이유는 다음과 같습니다.

• 초기 소프트웨어 (BIOS 및 OS에서 파일 시스템 및 파티셔닝 지원)는 대용량 데이터를 지원할 때 하드 드라이브보다 뒤떨어져 있었으므로 전체 용량을 사용할 수 있도록 하드 드라이브를 여러 부분으로 분할해야했습니다.
  • 이것은 주로 DOS와 Windows 95에서 문제였습니다. FAT32 (Windows 98)와 NTFS (Windows NT 3.1)의 출현으로이 문제는 당분간 해결되었습니다.
  • 최근 등장한 2TB 장벽은 최신 파일 시스템 ( ext4 및 최신 버전의 NTFS ), GPT 및 4k 디스크로 해결되었습니다 .
• 성능을 최적화하려는 다양한 시도. 회전 하드 드라이브는 내부 트랙보다 외부 트랙 (시작 섹터에 매핑 됨)에서 데이터를 읽을 때 약간 (약 1.5 배) 빠르므로 디스크 시작 부분 근처에 OS 라이브러리 및 페이지 파일과 같이 자주 액세스하는 파일을 찾을 수 있습니다.
  • 사용자 데이터도 매우 자주 액세스하고 헤드 재배치가 특정 워크로드 외부의 성능에 훨씬 큰 영향을 미치므로 실제 사용의 향상은 거의 미미합니다.
• 여러 물리 디스크. 현대 HDD는 종종 자체 크기가 충분하고 랩톱에는 두 번째 HDD를위한 공간이 없기 때문에 워크 스테이션에 일반적이지 않은 설정입니다. 이 설정에서 보았던 모든 스테이션이 대부분은 아니지만 여전히 작동하는 구형 HDD를 사용하고 필요한 크기까지 추가하는 데스크탑입니다. 그렇지 않으면 RAID를 사용하거나 드라이브 중 하나를 고정해야합니다 정기적으로 사용하지 마십시오.
  • 이것은 아마도 시스템과 데이터를 별도의 볼륨으로 분리하여 실질적인 이익을 얻는 유일한 사례 일 것입니다. 물리적으로 서로 다른 하드웨어에 있기 때문에 병렬로 액세스 할 수 있습니다 (동일한 케이블에 두 개의 PATA 드라이브가 아닌 경우). 전환 할 때 헤드 위치 변경시
    • Windows 디렉토리 구조를 재사용하기 위해 일반적 으로 C:\Users데이터 드라이브 로 이동 합니다. 단지 하나의 프로파일을 이동 또는 단지 Documents, Downloads및 Desktop프로파일의 다른 부분 사촌 '열등 입증하고 Public또한 (아래의 "개별 구성 및 데이터"설정 참조) 미친 듯이 성장할 수있다.
  • 디스크를 스팬 볼륨 으로 통합 할 수는 있지만, Dynamic Volumes는 타사 도구를 사용하는 데 문제가있는 독점 기술이며 드라이브 중 하나에 장애가 발생하면 전체 볼륨이 손실되므로이를 사용하거나 권장하지 않습니다.
• M.2 SSD + HDD.
  • 이 경우 SSD를 캐시로만 사용하는 것이 좋습니다.이 방법을 사용하면 임의의 일부가 아닌 전체 데이터 배열에 SSD의 이점을 얻을 수 있으며 실제로 가속되는 내용은 실제 내용에 따라 자동으로 결정됩니다 실제로 접근하십시오.
  • 어쨌든 랩톱 의이 설정은 단일 SSD 'cuz HDD보다 열등합니다. 랩톱의 경우 실제로 발생하는 외부 충격 및 진동에도 견딜 수 없습니다.
• 이중 부팅 시나리오. 일반적으로 두 개의 OS는 단일 파티션에 공존 할 수 없습니다. 이것이 내가 아는 유일한 시나리오는 워크 스테이션의 여러 파티션을 보증합니다. 모든 워크 스테이션은 이제 VM을 실행할 수있을만큼 강력하기 때문에 어쨌든 그 사용 사례는 거의 사라졌습니다.
• 서버에는 다른 여러 가지 유효한 시나리오가 있지만 그 중 어느 것도 슈퍼 유저의 도메인에 적용되지 않습니다.
  • 예를 들어, 런 어웨이 앱이 전체 시스템을 손상시키지 않도록 영구 데이터 (프로그램 및 구성)를 데이터 변경 (앱 데이터 및 로그)에서 분리 할 수 ​​있습니다. 또한 다양한 특수 요구 사항이 있습니다 (예 : 임베디드 시스템의 경우 영구 데이터는 종종 EEPROM에 상주하는 반면 RAM 데이터는 데이터를 작업합니다). 리눅스의 파일 시스템 계층 표준 은 이런 종류의 조정에 아주 적합하다.

거의 20 년 전에 워크 스테이션 / 서버 측의 NT4 및 2000을 포함하여 Windows 98에서 XP까지의 범위가 지배적이었습니다.

SSD는 컴퓨터보다 비싸고 SATA는 없었기 때문에 모든 하드 드라이브는 PATA 또는 SCSI 케이블 마그네틱 스토리지입니다.

WooShell의 답변에서 알 수 있듯이 드라이브의 낮은 논리 섹터 (플래터 외부)는 가장 빠른 경향이 있습니다. 내 1TB WDC Velociraptor 드라이브는 215MB / s에서 시작하지만 외부 섹터에서 125MB / s로 40 % 감소합니다. 이 드라이브는 2.5 "드라이브 플래터 드라이브이므로 대부분의 3.5"드라이브는 일반적으로 성능 이 50 % 이상 크게 저하됩니다 . 이것이 주 파티션을 작게 유지하는 주요 이유이지만 드라이브 크기에 비해 파티션이 작은 경우에만 적용됩니다.

파티션을 작게 유지하는 또 다른 주요 이유는 FAT32를 파일 시스템으로 사용하고 있었는데 32GB보다 큰 파티션을 지원하지 않았기 때문입니다. NTFS를 사용하는 경우 Windows 2000 이전에는 최대 2TB의 파티션이 지원되었고 최대 256TB의 파티션이 지원되었습니다.

파티션이 기록 될 데이터 양에 비해 너무 작 으면 조각화가 더 쉽고 조각 모음이 더 어렵습니다. 당신의 상황과 같이 공간이 부족할 수도 있습니다. 파티션 및 클러스터 크기에 비해 파일이 너무 많으면 파일 테이블을 관리하는 데 문제가 있고 성능에 영향을 줄 수 있습니다. 중복성을 위해 동적 볼륨 을 사용 하는 경우 중복 볼륨을 필요한만큼 작게 유지하면 다른 디스크의 공간이 절약됩니다.

오늘날에는 상황이 다릅니다. 클라이언트 스토리지는 플래시 SSD 또는 플래시 가속 자기 드라이브에 의해 지배됩니다. 스토리지는 일반적으로 풍부하고 워크 스테이션에 더 쉽게 추가 할 수 있지만 PATA 시대에는 추가 스토리지 장치에 대해 하나의 미사용 드라이브 연결 만있을 수 있습니다.

이것이 여전히 좋은 아이디어입니까, 아니면 어떤 이점이 있습니까? 이는 보관하는 데이터와 관리 방법에 따라 다릅니다. 내 워크 스테이션 C :는 80GB에 불과하지만 컴퓨터 자체에는 12TB 이상의 저장 공간이 있으며 여러 드라이브에 분산되어 있습니다. 각 파티션에는 특정 유형의 데이터 만 포함되며 클러스터 크기는 데이터 유형 및 파티션 크기와 일치하여 조각화를 0에 가깝게 유지하고 MFT가 부당하게 커지는 것을 방지합니다.

축소 된 크기는 사용되지 않는 공간이 있지만 성능이 보상보다 증가한다는 것입니다. 더 많은 스토리지를 원하면 더 많은 드라이브를 추가합니다. C : 운영 체제 및 자주 사용하는 응용 프로그램이 포함되어 있습니다. P : 일반적으로 덜 사용되는 응용 프로그램을 포함하며 C :보다 쓰기 내구성 등급이 낮은 128GB SSD입니다. T :는 더 작은 SLC SSD에 있으며 브라우저 캐시를 포함하여 사용자 및 운영 체제 임시 파일을 포함합니다. 비디오 및 오디오 파일은 가상 머신 이미지, 백업 및 아카이브 된 데이터와 마찬가지로 자기 스토리지에 저장되며 일반적으로 16KB 이상의 클러스터 크기를 가지며 읽기 / 쓰기는 순차적 액세스에 의해 좌우됩니다. 쓰기 볼륨이 높은 파티션에서는 1 년에 한 번만 조각 모음을 실행하며 전체 시스템을 수행하는 데 약 10 분이 걸립니다.

내 노트북에는 단일 128GB SSD와 다른 사용 사례가 있으므로 동일한 작업을 수행 할 수 없지만 C : (80GB OS 및 프로그램), T : (8GB temp) 및 F :( 공간을 낭비하지 않고 조각화를 제어하는 ​​데 도움이되는 24GB 사용자 파일), 공간이 부족하기 전에 랩톱이 교체됩니다. 또한 F :에는 정기적으로 변경되는 중요한 데이터 만 포함되므로 백업하기가 훨씬 쉽습니다.

나는 몇 가지 IT 작업을 수행했으며 여기에 내가 알고 기억하는 것이 있습니다.

과거에는 다른 사람들이 말했듯이 디스크 시작 부분에 작은 C 파티션이 있으면 실제로 이점이 있다고합니다. 오늘날에도 일부 저가형 랩톱에서는 이것이 사실 일 수 있습니다. 기본적으로 더 작은 파티션을 사용하면 조각화가 적고 디스크 시작 부분에 유지함으로써 더 나은 검색 및 읽기 시간을 얻을 수 있습니다. 이것은 오늘날에도 랩톱 (일반적으로)과 느린 "녹색"하드 드라이브에서 유효합니다.

지금도 여전히 사용하는 또 다른 큰 이점은 별도의 드라이브에 "데이터"와 "os"가 있거나 별도의 파티션을 관리 할 수없는 경우입니다. SSD 또는 더 빠른 마그네틱 드라이브를 사용하는 경우 실제 속도는 증가하지 않지만 OS가 결국 작동 할 때 "쉬운 수정"옵션이 있습니다. 드라이브를 바꾸거나 해당 파티션을 다시 고스트하십시오. 사용자의 데이터가 손상되지 않았습니다. 제대로 설정되면 D : 드라이브와 "로밍 프로필"사이에 창을 다시 설치하면 5 분 동안 문제가 발생하지 않습니다. 레벨 1 기술에게는 좋은 단계입니다.

여기에 한 가지 이유가 있지만 이것이 오늘날의 현대 컴퓨터에 유효한 이유라고 생각하지 않습니다.

이것은 Windows 95/98 및 XT로 돌아갑니다. 아마도 Vista 이상에는 적용되지 않지만 하드웨어 제한이므로 오래된 하드웨어에서 최신 OS를 실행하면 여전히 제한을 처리해야합니다.

제한이 2GB라고 생각하지만 이전에는 1GB 제한 (또는 다른 것)이있을 수 있습니다.

BOOT 파티션은 드라이브의 물리적 공간의 첫 2GB (아마도 1gb 이전) 내에 있어야했습니다. 1) BOOT 파티션의 시작이 한계 범위 내에 있어야했거나 2) ENTIRE 부트 파티션이 한계 범위 내에 있어야했을 수도 있습니다. 여러 번에 해당 사례가 각각 적용될 수 있지만 # 2가 적용된 경우 수명이 짧았으므로 1 위라고 가정하겠습니다.

따라서 # 1에서는 BOOT 파티션의 시작이 첫 2GB의 물리적 공간 내에 있어야했습니다. 이것은 Boot / OS를위한 1 개의 큰 파티션을 만드는 것을 방해하지 않습니다. 그러나 문제는 듀얼 / 멀티 부팅이었습니다. 드라이브를 이중 / 멀티 부팅 할 수있는 것처럼 보이는 경우 드라이브에 다른 부팅 가능한 파티션을 만들려면 2GB 아래에 사용 가능한 공간이 있어야합니다. 드라이브에 Linix 또는 부팅 가능한 디버그 / 문제 해결 / 복구 파티션과 같은 다른 부팅 파티션이 필요할 경우 설치시 알 수 없으므로 "작은 이유"로 설치하는 것이 좋습니다. "OS 부팅 파티션.

수십 년 전의 IT 부서가 백업에 관심이 있는지 궁금합니다. C :는 부팅 / OS 파티션이므로 일부 유형의 이미지 백업을 사용하는 것이 일반적이지만 데이터 / 프로그램 파티션의 경우 증분 파일 + 폴더 백업을 사용할 수 있습니다. C : 파티션에 사용 된 공간을 줄이면 시스템 백업에 필요한 시간과 공간이 줄어 듭니다.

C : 파티션의 개인적 사용에 대한 의견. Win 7 및 Win 10을 포함한 다중 부팅 시스템이 있으며 C : 파티션에 부팅 파일이있는 OS가 없습니다. Windows 7 및 Win 10 모두에 Windows 시스템 이미지 백업을 사용하며 Windows 시스템 이미지 백업에는 Win 7 또는 Win 10 파티션 외에 항상 C :( 부팅) 파티션이 포함되어 있으므로 C : 파티션의 데이터 및 프로그램은 시스템 이미지 백업에 필요한 시간과 공간을 줄입니다 (또는 필요한 경우 복원).

아래 의견 때문에이 섹션을 내 대답에 남겨두고 있습니다.

시스템이 다중 부팅이기 때문에 다른 OS로 재부팅하면 데이터 / 프로그램 파티션 백업이 더 간단 해집니다. 백업하는 동안 파티션에 대한 작업이 없기 때문입니다. 보안 및 재분석 정보와 함께 폴더 + 파일 복사를 수행하는 간단한 백업 프로그램을 작성했지만 Win 7 또는 Win 10 OS 파티션에서는 작동하지 않으므로 C의 시스템 이미지 백업을 사용하고 있습니다., Win 7 그리고 Win 10 OS 파티션.

아니요. Windows 및 주요 소프트웨어 제품군은 프로그램에 설치하더라도 시스템과 관련이 있다고 주장하지 않습니다. (대부분의 OS가 구축되는 방식은 제도화 된 필요성입니다.) 데이터 : 볼륨은 의미가 있지만 데이터 (또는 NAS 또는 이러한 이동식 드라이브에 대한 선택적 또는 증분 백업)를위한 별도의 이동식 드라이브가 더 적합합니다.

다중 OS 시스템의 파티션도 의미가 있지만 각 파티션에서는 하드 상한 스토리지 제한을 선택해야합니다. 일반적으로이 경우에도 별도의 드라이브를 사용하는 것이 좋습니다.

그리고 오늘날 가상 머신 및 클라우드 드라이브는 이러한 많은 선택을 보완합니다.

볼륨 스냅 샷을 사용하는 특별한 이유가 하나 있습니다.

볼륨 스냅 샷은 전체 파티션의 백업입니다. 이러한 종류의 백업에서 복원하면 전체 파티션을 다시 작성하여 시스템을 이전 상태로 효과적으로 롤백합니다.

시스템 관리자는 모든 종류의 소프트웨어 오류에 대비하여 정기적으로 이러한 스냅 샷을 생성 할 수 있습니다. 심지어 동일한 드라이브의 다른 파티션에 저장할 수도 있습니다. 그렇기 때문에 시스템 파티션을 비교적 작게 만들고 싶습니다.

이 체계를 사용할 때 사용자는 데이터를 네트워크 드라이브에 저장하는 것이 좋습니다. 소프트웨어 문제가있는 경우 시스템 관리자는 시스템을 작동 상태로 롤백 할 수 있습니다. 문제의 원인을 수동으로 조사하고 수정하는 것과 비교할 때 매우 시간 효율적입니다.

나는 거의 반세기 동안 프로그래밍했습니다. 다른 응답은 기록 을 나타내고 다른 긴 응답은 다중 물리 디스크를 말합니다 .

여러 물리 디스크가 권장 사항을 시작한 것으로 생각됩니다. 반세기 전, 파티션과 같은 것이 없었을 때 시스템에 별도의 물리적 드라이브를 사용하는 것이 일반적이었습니다. 그 주된 이유는 헤드의 물리적 움직임과 드라이브의 회전입니다. 물리적 드라이브를 다른 용도로 자주 사용하는 경우 파티션 에는 이러한 이점이 없습니다 .

또한 유닉스는 시스템과 데이터를 별도의 파티션으로 분리합니다. 다른 많은 답변에서 설명했듯이 그렇게해야 할 많은 이유가 있지만 성능을 위해서는 별도의 물리적 드라이브가 기본 정당화입니다.

우리가 2 개의 파티션을 만들었던 이유는 바이러스 때문이었습니다. 부트 섹터와 디스크의 시작 부분을 덮어 쓰는 데 사용 된 바이러스도 있습니다.

사용자 컴퓨터의 백업은 전체 프로그램의 복사본을 플로피 디스크에 복사하는 데 사용됩니다. (실제로는 백업이 아님)

따라서 바이러스가 디스크의 시작 부분을 "먹으면"일반적으로 시스템 만 다시 설치해야했습니다.

백업이 없으면 두 번째 파티션이 손상되지 않은 경우 데이터 복구가 더 쉬워졌습니다.

따라서 백업이있는 경우이 이유는 유효하지 않습니다.