Làm cách nào để căn chỉnh bảng phân vùng của tôi đúng cách?


19

Tôi đang trong quá trình xây dựng mảng RAID5 đầu tiên của mình. Tôi đã sử dụng mdadm để tạo các thiết lập sau:

root@bondigas:~# mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90
  Creation Time : Wed Oct 20 20:00:41 2010
     Raid Level : raid5
     Array Size : 5860543488 (5589.05 GiB 6001.20 GB)
  Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Wed Oct 20 20:13:48 2010
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 1% complete

           UUID : f6dc829e:aa29b476:edd1ef19:85032322 (local to host bondigas)
         Events : 0.12

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       4       8       64        3      spare rebuilding   /dev/sde

Trong khi đó, tôi quyết định định dạng con thú bằng lệnh sau:

root@bondigas:~# mkfs.ext4 /dev/md1p1 
mke2fs 1.41.11 (14-Mar-2010)
/dev/md1p1 alignment is offset by 63488 bytes.
This may result in very poor performance, (re)-partitioning suggested.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=16 blocks, Stripe width=48 blocks
97853440 inodes, 391394047 blocks
19569702 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
11945 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848

Writing inode tables: ^C 27/11945
root@bondigas:~# ^C

Tôi không chắc chắn phải làm gì về việc căn chỉnh "/ dev / md1p1 được bù bởi 63488 byte." và làm thế nào để phân vùng đúng các đĩa cho phù hợp để tôi có thể định dạng đúng.

Câu trả lời:


17

Vì sự liên kết bật lên ở rất nhiều nơi -

  • Ổ cứng "Định dạng nâng cao" với khối 4k
  • SSD
  • RAID
  • LVM

- Tôi sẽ mở rộng một chút về câu hỏi.

Căn chỉnh phân vùng

"Linux trên các đĩa 4kB-sector" (IBM DB2) thực hiện các bước với fdisk, parted và GPT fdisk.

Với fdisk:

sudo fdisk /dev/XXX 
c # turn off DOS compatibility
u # switch to sector units
p # print current partitions, check that start sectors are multiples of 8

# for a new partition:
n # new partition
<select primary/secondary and partition #>
first sector: 2048 
  # 2048 is default in recent fdisk, 
  # and is compatible with Vista and Win 7, 
  # 4k-sector disks and all common RAID stripe sizes

Căn chỉnh hệ thống tập tin

Điều này chủ yếu liên quan đến RAID (cấp 0, 5 và 6; không phải cấp 1); hệ thống tập tin hoạt động tốt hơn nếu nó được tạo ra với kiến ​​thức về kích thước sọc.

Nó cũng có thể được sử dụng cho SSD nếu bạn muốn căn chỉnh hệ thống tệp với kích thước khối xóa SSD (Theodore Tso, nhà phát triển nhân Linux).

Trong bài đăng OP mkfsdường như tự động phát hiện các cài đặt tối ưu, do đó không cần thực hiện thêm hành động nào.

Nếu bạn muốn xác minh, đối với RAID , các tham số có liên quan là:

  • kích thước khối ( kích thước khối hệ thống tệp, ví dụ 4096)
  • kích thước sọc (giống như kích thước chunk mdadm, ví dụ 64k)
  • sải chân: stripe size / block size (ví dụ: 64k / 4k = 16)
  • chiều rộng sọc: stride * #-of-data-disks (ví dụ: 4 đĩa RAID 5 là 3 đĩa dữ liệu; 16 * 3 = 48)

Từ Linux Raid Wiki . Xem thêm máy tính đơn giản này để biết các cấp độ RAID và số lượng đĩa khác nhau.

Đối với căn chỉnh khối xóa SSD, các tham số là:

  • kích thước khối fs (ví dụ: 4096)
  • Kích thước khối xóa SSD (ví dụ: 128k)
  • sọc-width: erase-block-size / fs-block-size (ví dụ: 128k / 4k = 32)

Từ bài viết SSD của Theodore .

Căn chỉnh phạm vi LVM

Vấn đề tiềm năng là LVM tạo ra một tiêu đề 192k. Đây là bội số của 4k (vì vậy không có vấn đề gì với các đĩa khối 4k) nhưng có thể không phải là bội số của kích thước dải RAID (nếu LVM chạy trên RAID) hoặc kích thước khối xóa SSD (nếu LVM chạy trên SSD).

Xem bài viết của Theodore cho cách giải quyết.


@Marco Làm sao vậy? Cái đầu tiên, đối với IBM Developer Works, thậm chí có một biểu đồ điểm chuẩn của hình phạt hiệu năng ghi khi sử dụng các phân vùng không được phân bổ và một thanh bên trên RAID. Blogpost của Tso trên căn chỉnh SSD đã di chuyển ít nhất hai lần kể từ khi tôi viết bài này. Đã cập nhật lại liên kết, nhưng không có gì đảm bảo nó sẽ tiếp tục hoạt động.
jg-faustus

Liên kết thay thế trên SSD: Căn chỉnh các phân vùng SSD
jg-faustus 16/07/13

8

Một người bạn của tôi đã chỉ ra rằng tôi chỉ có thể mkfs.ex4 ngay /dev/md1mà không cần phân vùng bất cứ điều gì, vì vậy tôi đã xóa phân vùng và làm điều đó và nó dường như được định dạng ngay bây giờ.


6

Tôi thấy cách này là dễ nhất

parted -a opt /dev/md0
(parted) u MiB
(parted) rm 1
(parted) mkpart primary 1 100%

hoặc một phương pháp bẩn thay thế sẽ đơn giản như thế này

(parted) mkpart primary ext4 1 -1

Tài liệu chia tay đề nghị sử dụng MB và GB, không phải MiB hoặc GiB, nếu muốn cho phép chia tay để tự động tối ưu hóa các phân vùng.
Felipe Alvarez

1

Có vẻ như mkfs.ext4 muốn các hệ thống tập tin trên RAID của bạn bắt đầu trên ranh giới 64 KiB. Nếu bạn sử dụng toàn bộ đĩa, nó bắt đầu từ 0, tất nhiên cũng là bội số của 64 KiB ...

Hầu hết các công cụ phân vùng hiện nay sẽ sử dụng ranh giới 1 MiB theo mặc định (fdisk có thể không).

Lý do cho điều này là hầu hết các đĩa cứng & SSD sử dụng các khu vực vật lý trên thiết bị lớn hơn nhiều so với các khu vực logic. Kết quả của điều đó là nếu bạn đọc một khu vực logic 512 byte từ đĩa, phần cứng thực sự phải đọc một lượng dữ liệu lớn hơn nhiều.

Trong trường hợp thiết bị RAID phần mềm của bạn, một cái gì đó tương tự xảy ra: dữ liệu trên nó được lưu trữ trong "khối" 64 KiB với cài đặt mdadm mặc định.

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.