Làm cách nào để tìm khối phần cứng đọc kích thước cho ổ cứng của tôi?


47

Tôi đang cố gắng tìm ra kích thước tối ưu cho một bản sao lớn từ ổ cứng của mình bằng dd. Tôi đang cố gắng tìm ra thứ gì tốt nhất để sử dụng nó, mà tôi cho là kích thước khối phần cứng cho ổ đĩa đó.



1
@Sepero cung cấp câu trả lời thực sự duy nhất.
sjas

Câu trả lời:


44

Lệnh lsblk rất tốt cho việc này:

lsblk -o NAME,PHY-SeC

Kết quả:

NAME   PHY-SEC 
sda        512 
├─sda1     512 
├─sda2     512 
└─sda5     512 

3
Liệu nó có phân biệt giữa kích thước hợp lý và kích thước vật lý?
CMCDragonkai

2
Sẽ không cung cấp kích thước vật lý thực tế.
sjas

7
Hoạt động với tôi, PHY-SEC hiển thị vật lý chính xác và LOG-SEC hiển thị kích thước logic.
soger

31

Linux hiển thị kích thước khu vực vật lý trong các tập tin /sys/block/sdX/queue/physical_block_size. Mặc dù, để có được hiệu suất tốt nhất, có lẽ bạn nên làm một thử nghiệm nhỏ với các kích cỡ và bệnh sởi khác nhau. Tôi có thể không tìm thấy một rõ ràng câu trả lời trong đó sử dụng chính xác kích thước khối vật lý sẽ nhận được kết quả tối ưu (mặc dù tôi cho rằng nó không thể là một lựa chọn không tồi).


2
Tôi đã có một hệ thống Debian Lenny (kernel 2.6,26 ) chỉ hiển thị một hw_sector_size ở vị trí đó và một hệ thống Ubuntu Karmic mới hơn (kernel 2.6.31) cung cấp cả hai. vì vậy điều này hơi phụ thuộc vào kernel đang sử dụng.
quack quixote

Sẽ không cung cấp kích thước vật lý thực tế.
sjas

@sjas Bạn có thể mở rộng? Làm thế nào bạn biết điều này?
Hashim

1
@Hashim tôi đã kiểm tra nó một số ổ cứng cũ tôi đã có một số nơi có một số 512b và kích thước khu vực 4k. superuser.com/a/426015/145072 là giải pháp thực sự hiệu quả. tất cả mọi thứ bên cạnh hdparmsẽ có khả năng nói dối bạn.
sjas

28
$ sudo hdparm -I /dev/sda | grep -i physical
Physical Sector size:                  4096 bytes

http://wayback.archive.org/web/20150921015456/https://nxadm.wordpress.com/2010/04/30/4096-physical-block-size-drive/


3
Đây phải là câu trả lời được chấp nhận, vì nó là người duy nhất cung cấp giá trị vật lý thực sự.
sjas

4
hdparm -I /dev/sda | grep Sectorlà đẹp hơn, vì nó sẽ hiển thị cả kích thước vật lý và logic cùng một lúc, để dễ so sánh.
sjas

7

Của tôi không có ý định là một câu trả lời hoàn chỉnh, nhưng tôi hy vọng nó cũng có ích.

Đây là một chút gì đó từ http://mark.koli.ch/2009/05/howto-whole-disk-backups-with-dd-gzip-and-p7zip.html


3 - Xác định kích thước khối phù hợp

Để sao lưu nhanh hơn, nó có thể giúp giảm kích thước khối tối ưu của thiết bị đĩa bạn sẽ sao lưu. Giả sử bạn sẽ sao lưu / dev / sda, đây là cách bạn có thể sử dụng lệnh fdisk để xác định kích thước khối tốt nhất:

rescuecd#/> /sbin/fdisk -l /dev/sda | grep Units

Units = cylinders of 16065 * 512 = 8225280 bytes

Lưu ý đầu ra fdisk cho biết "hình trụ 16065 * 512". Điều này có nghĩa là có 512 byte cho mỗi khối trên đĩa. Bạn có thể cải thiện đáng kể tốc độ sao lưu bằng cách tăng kích thước khối lên gấp 2 đến 4. Trong trường hợp này, kích thước khối tối ưu có thể là 1k (512 * 2) hoặc 2k (512 * 4). BTW, trở nên tham lam và sử dụng kích thước khối 5k (512 * 10) hoặc một cái gì đó quá mức sẽ không giúp ích; cuối cùng, hệ thống sẽ tự tắc nghẽn thiết bị và bạn sẽ không thể thực hiện bất kỳ hiệu suất bổ sung nào từ quá trình sao lưu. (nhấn mạnh thêm)


Tôi nghi ngờ sự khác biệt về hiệu suất giữa kích thước khối gần tối ưu và tối ưu cho một cấu hình nhất định là không đáng kể trừ khi bộ dữ liệu là rất lớn. Thật vậy, một người dùng tại FixUnix (bài đăng từ năm 2007) khẳng định thời gian tối ưu của anh ta chỉ nhanh hơn 5% so với thời gian tối ưu phụ. Có lẽ bạn có thể đạt được hiệu quả cao hơn một chút bằng cách sử dụng nhiều kích thước "cụm" hoặc kích thước khối hệ thống tệp.

Tất nhiên, nếu bạn di chuyển quá xa sang một trong hai bên của kích thước khối tối ưu, bạn sẽ gặp rắc rối.

Điểm mấu chốt là bạn có thể sẽ chỉ đạt được khoảng 5% hiệu suất (tức là 3 phút mỗi giờ) với kích thước khối tối ưu tuyệt đối, vì vậy hãy xem xét liệu nó có xứng đáng với thời gian và nỗ lực của bạn để nghiên cứu thêm hay không. Miễn là bạn tránh xa các giá trị cực đoan, bạn không nên chịu đựng.


1
một số lý do để sử dụng echo "p" | /sbin/fdisk /dev/sda...thay vì /sbin/fdisk -l /dev/sda...? thứ hai sẽ sạch hơn và sẽ không cố gắng thực hiện bất kỳ thay đổi nào.
quack quixote

Bạn nên hỏi Mark Kolich (liên kết). Anh ấy đang tạo một bản sao lưu, và tôi chỉ trích dẫn một phần bài viết của anh ấy.
Đánh dấu C

1
@MarkC Bài viết được liên kết sử dụng /sbin/fdisk -l /dev/sda | grep Units. Nó có thể đã được thay đổi trong hai năm qua. Trong mọi trường hợp, tôi đã cập nhật câu trả lời của bạn.
Bob

2
IMO đây là câu trả lời hữu ích nhất chủ yếu là do đoạn in đậm cuối cùng. Linux làm việc rất chăm chỉ để tối ưu hóa truy cập đĩa, miễn là bạn sử dụng bộ lập lịch io thích hợp và cài đặt bộ đệm bẩn cho đĩa của bạn, kích thước khối 8192 byte sẽ ổn cho mọi tình huống.
soger

4

Mỗi lần chuyển đĩa tạo ra một ngắt mà bộ xử lý phải xử lý. Đĩa 50Mb / giây thông thường sẽ muốn tạo 100000 trong số chúng mỗi giây ở kích thước khối 512b Bộ xử lý thông thường sẽ xử lý 10 nghìn trong số đó, do đó, kích thước khối lớn hơn (2 ^ x) sẽ tiện dụng hơn (4k làm kích thước khối FS mặc định trong hầu hết các hệ thống có kích thước lên tới 64k ISA DMA) sẽ thực tế hơn ...


Bạn có thể làm rõ?
sjas

1
@Sjas Những gì anh ấy hoặc cô ấy nói là, rõ ràng, mỗi khu vực được chuyển riêng với một "ngắt" liên quan mà bộ xử lý phải xử lý. Kích thước khối lớn hơn có nghĩa là ít ngắt hơn (và do đó sử dụng ít chu kỳ CPU hơn) cho cùng một lượng dữ liệu.
Đánh dấu C

1

Ngoài ra, bạn có thể xem qua đầu ra lshwđể xác minh các kết quả khác, (và cũng bởi vì tôi dường như không có hdparmsẵn trên bản phân phối của mình.) Điều này có thể giúp thu hẹp nó:

sudo lshw | awk 'BEGIN {IGNORECASE=1;} /SCSI/,!//{print}'
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.