Nếu bạn chỉ chạy một HĐH, Phân vùng có đáng không? [đóng cửa]


8

Theo truyền thống, tôi luôn thiết lập phân vùng hệ thống và phân vùng Dữ liệu. Tôi sắp thiết lập một máy chủ mới (Windows Server 2012 R2) và trong khi tự hỏi tôi nên tạo phân vùng hệ thống lớn đến mức nào, tôi bắt đầu tự hỏi: "Tôi có thực sự cần phân vùng không?"

Nếu bạn làm cho phân vùng quá lớn, thì đó là không gian bạn sẽ không bao giờ sử dụng. Nếu bạn làm cho nó quá nhỏ, nó sẽ là một nỗi đau lớn ở mông.

Một thư mục dữ liệu đơn giản cung cấp sự tách biệt bạn cần. Tiện ích sao lưu đủ thông minh để đối phó với cấu trúc này.

Vì vậy, lợi thế trong việc phân vùng ổ cứng của tôi là gì?




Cảm ơn, tôi đã tìm kiếm, nhưng hầu hết những gì tôi tìm thấy là về kích thước của phân vùng.
Chris McGrath

Có nhiều lợi thế cho nhiều phân vùng trong một vài tình huống, nhưng nói chung (nếu bạn không có một trong những tình huống đặc biệt đó) thì chúng sẽ rắc rối hơn giá trị của chúng.
Daniel R Hicks

1
Phân mảnh-khôn ngoan chắc chắn sẽ không hại khi sử dụng 1 phân vùng cho HĐH của bạn và một phân vùng khác cho các tệp cá nhân của bạn. Nó cũng làm cho việc cài đặt lại hệ điều hành của bạn hoặc cài đặt một hệ điều hành mới dễ dàng hơn rất nhiều. Hầu hết các hệ điều hành Windows Server sẽ tự động yêu cầu ít nhất 2 phân vùng, ví dụ: nếu bạn muốn chạy máy chủ WSUS
BlueCacti

Câu trả lời:


2

Trước hết, mục wikipedia khá đầy đủ về vấn đề này.

Tôi sẽ cố gắng giải thích sự hợp lý đằng sau phân vùng bên cạnh các đối số dự phòng / tổ chức đã được cung cấp trong các câu trả lời khác, để lập luận rằng từ quan điểm hiệu suất, lợi thế duy nhất trong phân vùng là giảm thiểu phân mảnh.

Các hệ điều hành phải đưa ra các giả định về cách người dùng sử dụng và lưu trữ dữ liệu của mình. Vấn đề có thể được giải quyết như sau:

Giả sử bạn có một đoạn bộ nhớ, giả sử 256B, mà bạn có thể tưởng tượng là 256 hộp theo trình tự.

|_|_|_|_|...|_|

Bây giờ, bạn muốn lưu trữ 3 tệp, một với 64, một với 64, khác với 128 hộp: bạn có nên phân bổ chúng không?

1: | 64 | 64 | 128 | or
2: | 64 | 128 | 64 | ?

Nó phụ thuộc ... vào việc khối nào sẽ được lưu trữ trong một thời gian dài hay không, và khối nào có thể xảy ra nhất sẽ được lưu sau khi một trong các khối được loại bỏ.

Hãy tưởng tượng 2 khối 64 được xóa khỏi đĩa trong thao tác tiếp theo, một đoạn 128 mới được lưu lại. Trong ví dụ 1, bạn có thể lưu trữ 128 ngay lập tức, nhưng trong ví dụ thứ hai, đầu tiên bạn phải di chuyển đoạn 128 được lưu trữ sang đường viền và chỉ sau đó bạn mới có thể thêm đoạn mới.

Bây giờ, hãy tưởng tượng điều này nhưng với tất cả các loại kích thước khác nhau, được lưu theo cách không tầm thường (nghĩa là không phải tất cả 4B trước, sau đó là tất cả 8B, v.v.) trên một đĩa khổng lồ (kích thước GB). Đây được biết là một vấn đề rất khó khăn.

HĐH giải quyết vấn đề này bằng cách sử dụng phương pháp phỏng đoán. Nó không tạo ra chiến lược tối ưu, nhưng sử dụng một số phương pháp phỏng đoán để đặt các khối ở vị trí chính xác. Một thông tin quan trọng là mức độ thường xuyên mà các khối người dùng / HĐH tiết kiệm được, bởi vì nó cung cấp một số thông tin tiên nghiệm về các đoạn tiếp theo mà hệ điều hành có thể cố gắng đoán.


Phân vùng đĩa hiệu quả cho HĐH biết rằng một vùng cụ thể của đĩa thuộc về phân vùng đó. Điều này có nghĩa là sẽ không còn một chuỗi gồm 256 hộp, mà là hai chuỗi gồm 128 hộp (phân vùng A và B). HĐH sẽ không còn đưa ra giả định về nơi đặt nó: bạn là người quyết định xem bạn chọn thư mục gốc nào trong thư mục của bạn (nói vẫy tay).

Tại sao nó có thể cải thiện hiệu suất?

Một ví dụ điển hình là khi bạn có hai hành vi khác biệt trong khi sử dụng HĐH. Chẳng hạn, sự khác biệt giữa:

  1. sử dụng HĐH hàng ngày, có rất nhiều ghi và xóa trong bộ nhớ, và
  2. khi bạn lưu trữ các tệp nặng như video hoặc album mà bạn không thay đổi nhiều.

Phân vùng có thể cải thiện hiệu suất khi bạn sử dụng HĐH hàng ngày theo một cách và bạn sử dụng phân vùng khác để chỉ lưu trữ các tệp nặng mà bạn chỉ thay đổi rất hiếm khi trong suốt vòng đời của HĐH.

Vì hành vi của bạn nhất quán trong từng phân vùng, nên HĐH có thể sẽ cải thiện việc phân bổ, do đó giảm thiểu sự phân mảnh.

Bây giờ, cho dù điều này có liên quan hay không đối với các trường hợp người dùng thông thường, tôi sẽ nói không bởi vì những người phát triển chiến lược phân bổ là thông minh và các heuristic được nghĩ cho những trường hợp đó.

Đối với các máy chủ và các hệ thống khác, điều này có thể tạo ra sự khác biệt, nhưng hãy tìm kiếm nó sau khi định hình .

EDIT bao gồm SSD

Tôi hiểu rằng vấn đề này độc lập với việc chúng ta nói về SSD hay đĩa cứng. Vấn đề rất cơ bản theo nghĩa là nó chỉ yêu cầu bạn muốn lấp đầy một không gian hữu hạn bằng các vật phẩm có kích thước không đổi liên tục được thêm vào và loại bỏ.


Cả câu trả lời của bạn và bài viết wiki đều là một bài đọc thú vị. Bạn có biết làm thế nào SSD phù hợp với điều này? Có vẻ như phần lớn các vấn đề đề cập đến các vấn đề về phân mảnh / đĩa đĩa / đầu đọc, không có vấn đề nào áp dụng cho SSD. (Các khối dữ liệu của bạn có vấn đề tương tự đối với SSD mặc dù điều đó có thể đáng được đề cập - Trim en.wikipedia.org/wiki/Trim_%28computing%29 )
RJFalconer

@RJFalconer Tôi rất vui vì bạn thấy nó thú vị. Tôi cập nhật câu hỏi để giải quyết quan điểm của bạn.
Jorge Leitao

6

Ưu điểm là khả năng cài đặt lại HĐH mà không phải sao chép các tệp cá nhân của bạn sang nơi khác và sau đó phân bổ lại cài đặt HĐH hoàn toàn mới, vì nó sẽ nằm trong một phân vùng khác.

Ngoài ra, nếu bạn đang chạy một máy chủ, thông thường nên thực hiện các khối lượng liên quan đến dịch vụ nhất định trên một phân vùng riêng. Theo cách đó, nếu dịch vụ đó bị xâm phạm và kẻ tấn công có thể lấp đầy phân vùng đó thì HĐH của bạn vẫn sẽ hoạt động. Hãy xem xét một dịch vụ FTP hoặc cơ sở dữ liệu - nếu các thư mục đang được truy cập có thể được lấp đầy với dung lượng của đĩa thì bạn sẽ gặp phải một số vấn đề nghiêm trọng về vận hành nhưng ai đó chỉ đổ đống dữ liệu vào đó, do đó gây ra một DOS cho hệ thống đó. Cách tiếp cận này sẽ còn hấp dẫn hơn đối với kẻ tấn công nếu có các dịch vụ có giá trị khác chạy trên đó mà chúng muốn phá vỡ như máy chủ web hoặc bộ điều khiển miền. Được cho là, tất cả điều này có thể được giảm nhẹ với cấu hình phù hợp của các dịch vụ này nhưng việc khai thác mới xuất hiện hàng ngày để không bao giờ bị tổn thương khi thêm nhiều lớp bảo mật khi có thể. (được thêm bởiBradley Forney )

Nhưng, theo quan điểm của người dùng cuối (người dùng Windows 7, Windows 8, v.v.) (tôi biết rằng câu hỏi là dành cho máy chủ nhưng với những người đang nhìn thấy điều này mặc dù Google), không có điểm nào trong việc phân vùng nếu bạn không cài đặt lại hệ điều hành của bạn với tần suất.


1
Không. Bạn nên tạo bản sao lưu.
Marcks Thomas

Chà, một tuyên bố phù hợp hơn có thể là "không cần phải khôi phục bản sao lưu" - giúp tăng tốc đáng kể. Phân vùng của hệ điều hành không có chỗ cho dữ liệu người dùng, có thể là máy chủ hoặc máy trạm.
Daniel B

1
@MarcksThomas Phân vùng có thực sự là "bản sao lưu"? Nếu ổ cứng gặp trục trặc thì sao?
athosbr99

2
-1 "không có điểm". Có nhiều lý do để phân vùng. Nhóm hợp lý, quyền, dễ sao lưu, khả năng mở rộng (ví dụ: thêm ổ đĩa "trò chơi" / "phương tiện" lớn hơn vào hệ thống của bạn), ...
RJFalconer

1
Tôi không cài đặt lại hệ điều hành của mình thường xuyên, nhưng tôi chắc chắn rằng tôi đã có công cụ của mình trên một phân vùng riêng khi hệ điều hành của tôi đột nhiên bị sập hoàn toàn và buộc tôi phải cài đặt lại. Vì vậy, ... chắc chắn sẽ không nói "không có điểm nào" ...
Svish

0

Nhiều năm trước (Win Server 2008), có nhiều lợi thế trong nhiều phân vùng:

  1. dễ dàng hơn để chống phân mảnh để làm việc hiệu quả
  2. dễ dàng hơn để có được bản sao lưu theo phân vùng
  3. Khi máy chủ trao đổi lấp đầy phân vùng của nó, máy chủ sẽ KHÔNG gặp sự cố (nếu không thì đã xảy ra).

Tôi không biết điều này có còn đúng trong Win Server 2012 không.


-1

Tôi đã tạo thói quen tạo một hệ thống và phân vùng dữ liệu. Bằng cách này, tôi có thể cài đặt lại, nâng cấp hoặc hạ cấp HĐH của mình (tôi thực hiện việc này mọi lúc) mà không làm mất dữ liệu của mình. Ngoài ra, tôi có thể chọn dualboot hai HĐH.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.