Tốc độ ghi cực chậm vào ổ đĩa ngoài được mã hóa trên Mavericks


10

Ghi vào ổ flash USB được mã hóa hoàn toàn trên Mavericks là cực kỳ chậm.

Mẫu ổ đĩa tôi sử dụng để thử nghiệm là Kingston DataTraveler Ultimate 3.0 G3 (64 GB). Tôi đã kiểm tra tốc độ truyền bằng cách đọc / ghi một tệp lớn từ / đến cả ổ đĩa được mã hóa và không được mã hóa. Tôi đã thử nghiệm trên Macbook hiện tại với Mavericks và trên một máy cũ hơn với Mountain Lion. Tôi đã sử dụng Disk Utility để định dạng ổ đĩa là Mac OS Extended (Nhật ký) và Mac OS Extended (Nhật ký, Mã hóa).

MacBook Pro (2013) với USB 3.0 chạy OS X 10.9.2 (13C64)

Viết: 86,16 MB / giây (được mã hóa: 0,62 MB / giây)
Đọc: 181,66 MB / giây (được mã hóa: 151,15 MB / giây)

MacBook Pro (2007) với USB 2.0 chạy OS X 10.8.5 (12F45)

Viết: 23,57 MB / giây (được mã hóa: 5,04 MB / giây)
Đọc: 36,23 MB / giây (được mã hóa: 37,87 MB / giây)

Như bạn có thể thấy trên máy cũ, tốc độ ghi giảm rõ rệt khi ghi vào ổ đĩa được mã hóa nhưng vẫn nhanh hơn khoảng mười lần so với máy mới hơn chạy Mavericks. Đây có thể là một số vấn đề được giới thiệu gần đây trong FileVault hoặc CoreStorage?

Cập nhật (2014-06-28)

Ổ USB dường như đã bị lỗi phần cứng ngay từ đầu. Tôi đã có một ổ đĩa thay thế (cùng model) mà vẫn không mang lại kết quả như mong đợi nhưng ít nhất tốc độ ghi được mã hóa của MBP 2013 hiện ngang bằng với MBP 2007.

MacBook Pro (2013) với USB 3.0 chạy OS X 10.9.3 (13D65)

Viết: 135,41 MB / giây (được mã hóa: 9,29 MB / giây)
Đọc: 196,22 MB / giây (được mã hóa: 187,04 MB / giây)

MacBook Pro (2007) với USB 2.0 chạy OS X 10.8.5 (12F45)

Viết: - MB / giây (được mã hóa: 9,39 MB / giây)
Đọc: - MB / giây (được mã hóa: 37,79 MB / giây)

Điều này vẫn để lại câu hỏi mặc dù tại sao tốc độ ghi được mã hóa vào ổ USB trên MBP 2013 thấp hơn mười phần trăm tốc độ ghi thông thường. Tôi cũng đã so sánh tốc độ đọc / ghi trước và sau khi kích hoạt FileVault trên ổ SSD nội bộ của MBP 2013 và ở đó tôi không thể phát hiện bất kỳ sự chậm trễ nào cả.


1
Wow - việc đọc / ghi và viết mã hóa bình thường trông rất tốt. Nhưng viết mã hóa đó là rất chậm. Công cụ nào đang đo MB / s? Bạn có thể sao chép các kết quả này bằng Blackmagic (miễn phí trên MAS)
bmike

Tôi đã sử dụng một Bash-liner đơn giản sử dụng time, ddawk. Blackmagic cho tôi kết quả tương tự: goo.gl/bn32fC (không được mã hóa) so với goo.gl/yghyqA (được mã hóa).
Stefan Schmidt

Tôi nghi ngờ tốc độ đọc cho âm lượng được mã hóa bị thiếu vì thời lượng đọc ngắn hơn khoảng thời gian lấy mẫu thông lượng của Blackmagic
Stefan Schmidt

Câu trả lời:


2

Tôi có cùng một vấn đề, điều mà tôi khá chắc chắn là do sự kết hợp giữa cách thức hoạt động ghi trên bộ nhớ flash và cách lưu trữ lõi (hoặc bất kỳ toàn bộ khối lượng) nào hoạt động.

Đầu tiên, ghi hành vi: không giống như bộ nhớ dễ bay hơi (thứ được sử dụng trong bộ nhớ của máy tính của bạn) hoặc đĩa cứng, trong đó bất kỳ bit nào có thể được ghi thành 0 hoặc 1 bất cứ lúc nào, bộ nhớ flash có hai trạng thái chính: bị ghi và bị xóa. Trong "văn bản" là 0 và 1. Khi bạn cần ghi vào bộ nhớ flash, bạn phải viết toàn bộ một khối hiện đang ở trạng thái bị xóa. Phần mềm hệ thống tệp trong HĐH có thể biết khối nào là miễn phí, nhưng bộ điều khiển và bộ lưu trữ trên thiết bị flash thì không. Một cách đặc biệt để HĐH nói với SSD để tạo ra các khối có sẵn đã được nghĩ ra cho SSD "kết nối xe buýt": nó được gọi là TRIM. Theo tôi biết, các giao thức USB không hỗ trợ TRIM. Vì vậy, về cơ bản, bộ nhớ flash tiếp tục lấp đầy cho đến khi không có khối bị xóa thực sự, tại thời điểm đó, hệ thống tệp phải xóa và viết lại các khối bằng cách đọc chúng, hợp nhất trong dữ liệu mới, xóa và viết chúng ra. Đó là lý do tại sao bạn thấy hiệu suất ghi tệp nhỏ giảm trên SSD theo thời gian.

Các trường hợp đặc biệt của khối lượng mã hóa rất thú vị: tùy thuộc vào cách mã hóa hoạt động, nó thực sự có thể mã hóa toàn bộ khối lượng, lấp đầy tất cả các khối với dữ liệu ngẫu nhiên ngay cả khi các khối thực sự không được sử dụng và sẽ chứa số không. Vì vậy, khi bạn bật FileVault (hoặc nói cách khác là kích hoạt mã hóa lưu trữ lõi), về cơ bản, nó sẽ tiêu thụ toàn bộ âm lượng, không còn chỗ trống cho các hoạt động ghi. Hệ thống tập tin phải liên tục đọc, xóa và viết lại các khối để nó có thể viết lại chúng với bất kỳ dữ liệu được mã hóa nào bạn muốn đưa vào nó.

Bây giờ tôi sẽ nói ngay rằng đây là suy đoán dựa trên sự hiểu biết hợp lý về cách mọi thứ hoạt động, nhưng có những người thực sự biết chi tiết, những người có thể sửa hoặc cải thiện lời giải thích của tôi và tôi hy vọng rằng họ sẽ làm như vậy.


Điều đó thực sự nghe rất hợp lý. Tôi đã thực hiện một số hoạt động đào và dường như đối với các ổ đĩa ngoài eSATA và Thunderbolt đều hỗ trợ TRIM. Điều này có thể thú vị liên quan đến ổ SSD ngoài nhưng có lẽ không phải là ổ USB vì máy Mac không có giao diện eSATA và có vẻ như ổ ngón tay Thunderbolt giá cả phải chăng sẽ sớm xuất hiện: goo.gl/sDM1au
Stefan Schmidt

1
Chỉ trong trường hợp ai đó đang tự hỏi: Trong khi đó, cách giải quyết của tôi là tạo ra một gói thưa thớt được mã hóa trên ổ đĩa có kích thước bằng dung lượng của ổ đĩa. Tôi đã không làm bất kỳ điểm chuẩn nào nhưng cảm giác gần như ngang bằng với việc ghi dữ liệu không được mã hóa vào ổ đĩa.
Stefan Schmidt

@StefanSchmidt một gói thưa thớt được mã hóa như được mô tả ở đây? blog.fosketts.net/2015/07/22/õ
Brad Cupit

@BradCupit Có nhưng tôi đồng bộ hóa nội dung của gói thưa thớt, không phải là gói thưa, vì vậy tôi gắn bó thưa thớt với hdiutil attach, sau đó sử dụng rsyncđể đồng bộ hóa với thư mục cục bộ của mình, sau đó ngắt kết nối với hdiutil detachổ đĩa thưa và đẩy ổ đĩa ra diskutil eject.
Stefan Schmidt
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.