Rắc rối tìm ra sự liên kết tối ưu của nhiều phân vùng trên ổ cứng định dạng nâng cao bên ngoài 931,5 GiB khi ở trong Linux


1

TÓM LƯỢC

Tôi có một máy tính xách tay Dell Inspiron 17-5767 với ổ đĩa trong 1TB Tôi đã cho phép Windows 10 được vận chuyển ban đầu tiếp tục có và chi phối tất cả cho chính nó (đó là hệ điều hành chơi game của tôi). Ngoài ra, tôi có hai ổ đĩa ngoài mà tôi làm và sẽ khởi động HĐH Linux hiện tại và tương lai của tôi. Thiết lập hiện tại của tôi là như sau:

  1. Cổng USB 3.0 # 0: Mở rộng Seagate + 931,5 GiB (1000204885504 byte) Ổ cứng ngoài được nhận dạng là / dev / sdb
    • hiện đang chứa một phân vùng ext4 trống, kích thước đầy đủ, nhưng đã phải vật lộn để thay thế điều này bằng sơ đồ phân vùng được căn chỉnh tối ưu gồm 12 phân vùng (điểm đấu tranh với sự liên kết)
  2. Cổng USB 3.0 # 1: 238,5 GiB (256060514304 byte) Samsung SSD 840 Pro được công nhận là / dev / sdc
    • đã được phân vùng bằng trình cài đặt của Fedora LiveCD (với tùy chọn "tùy chỉnh") và chứa cả các bản phân phối linux Fedora LXDE và Lubfox của tôi trong một LVM duy nhất chứa không gian trao đổi chung, không gian người dùng chung, gốc riêng biệt và phân vùng khởi động bên ngoài riêng biệt (bởi bên ngoài ở đây, tôi chỉ có nghĩa là không phải trong LVM mà trong các phân vùng chính riêng biệt của họ ở nơi khác trên cùng một đĩa)
    • Ổ đĩa này có cả kích thước khối vật lý và logic là 512 và được căn chỉnh tối ưu, theo tiện ích 'align-check opt x' của parted và fdisk cũng hài lòng với việc căn chỉnh (không có khiếu nại căn chỉnh từ bất kỳ tiện ích nào)
  3. BIOS UEFI cố gắng khởi động từ USB trước khi bên trong để tôi nhận được grub bật lên với tất cả các tùy chọn có sẵn của mình

MỤC TIÊU

Tôi đang cố gắng sao chép một cái gì đó giống như những gì tôi đang diễn ra với ổ đĩa / dev / sdc trên / dev / sdb, nhưng với 5 bản phân phối linux. Đó là khía cạnh của dự án của tôi mà tôi đã đề cập, vì tôi là một người chơi nhiều kinh nghiệm. Nhưng phần khác trong mục tiêu của tôi là phân vùng trên / dev / sdb của tôi được phân bổ tối ưu giống như trường hợp với / dev / sdc và đây là lúc tôi gặp rắc rối.

XUNG QUANH

Tôi hiện đang làm việc từ bản cài đặt Fedora LXDE tương đối mới và được nâng cấp của mình và kết quả tôi nhận được hoàn toàn có thể lặp lại trong bản cài đặt LubFi tương đối mới và cũng được nâng cấp.

BÁO CÁO PHỤ TÙNG DISK

[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size 
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size 
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size 
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset 
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C

Device     Start        End    Sectors   Size Type
/dev/sdb1  65535 1953467279 1953401745 931.5G Linux filesystem

Partition 1 does not start on physical sector boundary.
[root@frank ~]#

VẤN ĐỀ

Vì vậy, nó xuất hiện, dựa trên báo cáo về kích thước khối vật lý, rằng đĩa là 4k (định dạng nâng cao) thay vì 512b như ổ đĩa khác, mặc dù cho mục đích tương thích ngược, nó đang sử dụng kích thước cung cấp logic là 512b. Tôi có thể nói rằng tiện ích phân chia GNU đang giả sử kích thước khối là 512, bởi vì khi nó tính toán khoảng IO tối ưu

(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval

nó nhận được giá trị 65535, đó là nơi nó sẽ tự động khởi động phân vùng đầu tiên và cách duy nhất tiện ích phụ kiểm tra căn chỉnh sẽ vượt qua căn chỉnh phân vùng là tối ưu nếu nó bắt đầu trên bội số của 65535. Cách duy nhất là chia tay kết quả có ý nghĩa là nếu bạn cho rằng nó đang xử lý vật lý_io_size là 512 thay vì 4096

(33553920 + 0) / 512 = 65535.

Tuy nhiên, chia tay một cách dễ hiểu không thể sử dụng kích thước khối 4096, vì khi đó phương trình sẽ hoạt động để

(33553920 + 0) / 4096 = 8191.875.

Câu trả lời đó sẽ làm hài lòng một giáo viên đại số trung học, nhưng rõ ràng không có ý nghĩa như một khoảng thời gian mà người ta mong đợi một giá trị rời rạc (tức là một số nguyên!). Trong mọi trường hợp, vì tôi muốn tạo 12 phân vùng, một số phân vùng có kích thước nhỏ bằng 256MiB, điều đó không thể thực hiện được trong GNU Parted bằng cách sử dụng tỷ lệ phần trăm và câu chuyện dài tôi chỉ có thể đáp ứng kiểm tra căn chỉnh để căn chỉnh tối ưu gắn bó với 'đơn vị' và tự mình thực hiện số học mô-đun để đảm bảo các phân vùng của tôi bắt đầu trong khoảng thời gian 65535, cách mà tôi muốn chia tay. Dựa trên nghiên cứu của tôi, tôi đã không nghĩ rằng việc đảm bảo các phân vùng của mình cũng kết thúc vào những khoảng thời gian đó là rất quan trọng và do đó tôi bị bỏ lại những khoảng trống (rõ ràng không lớn hơn 65535) giữa hầu hết các phân vùng của tôi.

Một lần nữa, chia tay nghĩ rằng kết quả của tôi được căn chỉnh tối ưu, coi kích thước khối vật lý là 512 thay vì 4096. Nhưng sau đó, sau khi thoát khỏi chia tay và chạy 'fdisk -l / dev / sdb', tôi đã chứa trong đầu ra như sau:

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.

Vì vậy, những gì chia tay thích, fdisk không. Vì vậy, sau đó tôi đã thử sử dụng gParted để làm lại sơ đồ phân vùng của mình, cho phép nó sử dụng 1 MiB làm kích thước đơn vị và nó bắt đầu phân vùng đầu tiên vào năm 2048, giống như bạn thấy trên đĩa khác của tôi (/ dev / sdc). fdisk sau đó rất vui và ngừng phàn nàn về căn chỉnh ngành, nhưng sau đó GNU chia tay đã thất bại trong các bài kiểm tra kiểm tra căn chỉnh cho chế độ tối ưu, mặc dù nó sẽ vượt qua cho chế độ tối thiểu.

Tuy nhiên, tôi đã tìm thấy rằng trong cả hai trường hợp, mkswap (mà tôi đã sử dụng để tạo một khối lượng trao đổi trong LVM mà tôi đã đặt trên / dev / sdb11) đã đưa ra cảnh báo sau:

[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned

Vì vậy, mkswap nhận thấy khối lượng trao đổi của tôi bị điều chỉnh sai cho dù phần được cho là đĩa được căn chỉnh tối ưu hay căn chỉnh tối thiểu và mkswap cũng thấy khối lượng trao đổi của tôi bị căn chỉnh cho dù fdisk có hài lòng về việc căn chỉnh hay không.

LÝ THUYẾT

Tất cả điều này để lại cho tôi ấn tượng rằng tôi có thể phải bỏ qua các cảnh báo từ ít nhất một tiện ích phân vùng hoặc báo cáo đĩa, nhưng tôi không tự tin là cái nào. Cũng có thể là tất cả các báo cáo không đáng tin cậy để bắt đầu vì bao vây tương thích với USB có chứa ổ cứng có thể đang báo cáo sai ít nhất một trong các tham số của ngành. Chẳng hạn, có lẽ nó không thực sự là ổ AF? Hoặc có thể kích thước IO tối ưu của nó đang bị báo cáo sai. Hoặc có thể cả hai? Và, tin tôi đi, tôi cũng đã xem xét khả năng đây là trường hợp PEBKAC, vì tôi có thể đang hiểu nhầm điều gì đó về cách căn chỉnh các phân vùng trên ổ đĩa 4k. Tôi không chắc.

Dù có chuyện gì xảy ra, tôi sẽ rất vui khi tiếp tục cài đặt Linux thực tế của mình một khi tôi tin rằng các phân vùng của tôi được căn chỉnh tối ưu và mkswap, hoặc ít nhất là các tiện ích tôi thực sự nên tin tưởng nhất, ngừng phàn nàn về căn chỉnh.

CỨU GIÚP

Vui lòng giúp tôi hiểu lý do tại sao tôi dường như không thể chia tay và các tiện ích đĩa khác đồng ý với bất kỳ điều gì ngoài việc căn chỉnh tối thiểu (chỉ đạt được khi phân vùng bằng gParted hoặc gdisk), và vui lòng tư vấn cho tôi liệu tôi có thực sự nên lo lắng quá không về những lợi thế của việc căn chỉnh tối ưu so với căn chỉnh tối thiểu trong trường hợp của tôi, vì tôi sẽ không lãng phí thêm thời gian nếu có sự khác biệt quá lớn về hiệu suất hoặc sức khỏe của đĩa. Mặt khác, tôi muốn có thể tận dụng tối đa lợi ích định dạng nâng cao của đĩa.


Trên đĩa AF có kích thước cung cấp vật lý 4096 byte, các phân vùng sẽ bắt đầu được căn chỉnh theo kích thước này. Tức là số khu vực 512 byte bắt đầu phải là bội số của tám. Nó đơn giản như vậy.
Johan Myréen

Đúng, và như tôi đã chỉ ra khi bội số 8 được sử dụng, như điểm bắt đầu của năm 2048 (như những gì tôi nhận được với gParted), thì tiện ích chia tay thấy đĩa không được căn chỉnh tối ưu, nhưng chỉ được căn chỉnh tối thiểu và mkswap phàn nàn rằng khối lượng hoán đổi của tôi trong LVM bị điều chỉnh sai cho dù tôi gắn bó với những năm 2048 hay phù hợp với nhu cầu kỳ lạ của một phần cho khoảng thời gian 65535 giây để căn chỉnh tối ưu. Chỉ cần nhìn vào các tham số ngành mà hệ thống đã vẽ. Làm thế nào tôi thậm chí có thể tin tưởng rằng các tham số đó đang được báo cáo chính xác ở nơi đầu tiên?
gluonman

Ổ đĩa trong của tôi là ổ AF có kích thước giống hệt nhau. Sự khác biệt duy nhất là nó không có kích thước IO tối ưu kỳ lạ đảm bảo khoảng cách giữa các khu vực bên ngoài không gian riêng biệt. Kích thước IO tối ưu của nó giống như kích thước IO tối thiểu của nó là 4096, và nó bắt đầu từ năm 2048 và chia tay nghĩ rằng các phân vùng của nó được căn chỉnh tối ưu. Do đó, tôi tự hỏi liệu lý do duy nhất khiến các tiện ích của tôi phàn nàn về việc sắp xếp sai, và việc chia tay đó muốn tôi sử dụng 65535, là vì kích thước IO tối ưu là một con số sai. Tôi nghĩ đó là giả thuyết tốt nhất của tôi atm. Nhưng tôi chỉ muốn chắc chắn rằng tôi thực sự được tối ưu hóa.
gluonman

1
"Kích thước IO tối ưu" chỉ là một gợi ý của một số loại và 65535 chắc chắn không tối ưu để sử dụng như số lượng các cung 512 byte để bắt đầu phân vùng. Hướng dẫn GParted nói: "Sử dụng căn chỉnh MiB cho các hệ điều hành hiện đại."
Johan Myréen

Được chứ. Nó trở nên rõ ràng trong đầu tôi khi chia tay chỉ đơn giản là sai ở những gì nó cho là tối ưu (trên cả Fedora và LubFi của tôi), bởi vì "gợi ý" kích thước IO tối ưu đến từ ổ đĩa cụ thể này đang loại bỏ nó. Bạn có đồng ý không Ý tôi là, tôi biết những con số thật kỳ lạ, nhưng tôi đã tin tưởng chia tay trong nhiều năm và đây thực sự là lần đầu tiên tôi thấy nó ném các vấn đề liên kết với tôi. Vì vậy, tôi có lẽ chỉ nên tiếp tục và tiếp tục với các khoảng thời gian 2048 và bỏ qua các khiếu nại của một phần (và mkswap, cho vấn đề đó), phải không?
gluonman

Câu trả lời:


0

Trong trường hợp bạn vẫn còn bối rối bởi số 65535s kỳ quái. Tôi cũng bối rối bởi câu hỏi này gần đây. Tôi đã tìm kiếm một câu trả lời và tìm thấy câu trả lời này: http://gparted-forum.surf4.info/viewtopic.php?id=17839

Tóm lại, tối ưu hóa_io_size có thể không hợp lệ khi HD được gắn vào PC với bộ chuyển đổi usb-sata.

Giải pháp là chỉ cần bỏ qua con số này và bám vào đề xuất ranh giới 1MiB.

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.