Gnome, nautilus sao chép tệp vào USB dừng ở mức 100% hoặc gần

Tôi đã có vấn đề tương tự trước đây nhưng tôi không nhớ tôi đã giải quyết nó như thế nào.

Khi tôi cố gắng sao chép một cái gì đó vào thanh USB, với FAT, nó dừng ở gần cuối, đôi khi ở mức 100%. Và tất nhiên, khi tôi chuyển thẻ nhớ sang một nơi khác, nó không chứa tệp hoàn chỉnh. (tập tin là một bộ phim!)

Tôi đã cố gắn thiết bị với mount -o flush, nhưng tôi gặp vấn đề tương tự.

Ngoài ra, tôi đã định dạng thanh USB với phân vùng FAT mới ...

Bất cứ ý tưởng những gì tôi làm lạnh?

ps Tôi tin rằng nó không liên quan đến HĐH, đó là Debian và tôi tin rằng việc đối phó từ ổ SSD không khiến nó bị kẹt.

Ở đâu đó tôi đã gặp những lời giải thích vấn đề sau đây. Trong trường hợp sao chép được thực hiện thông qua bộ nhớ hoạt động và idicator hiển thị quá trình đọc dữ liệu từ ổ đĩa. Tuy nhiên, quá trình wrighting dài hơn nhiều so với USB-stick (có thể chậm 100 lần: chẳng hạn như 2Mb / giây so với 200Mb / giây đọc) và hơn thế nữa nếu bạn sử dụng các hệ thống tệp không có nguồn gốc như FAT hoặc NTFS trong linux . Vì vậy, hãy cố gắng chờ giao dịch kết thúc ngay cả khi đã dừng 100% nhưng không đóng (điều này cho biết kết thúc).

— Costas

chỉ tự hỏi liệu có thể kiểm tra tiến độ trong tình huống đó không?

thử định dạng Pendrive với tùy chọn ghi đè dữ liệu thoát bằng số 0 Nó hoạt động trên

— ổ đĩa

Đối với bất kỳ ai gặp phải vấn đề này, chỉ cần định dạng ổ đĩa của bạn thành NTFS.

— Ricky Boyce

Câu trả lời:

Lý do nó xảy ra theo cách đó là vì chương trình nói "ghi dữ liệu này" và nhân linux sao chép nó vào một bộ nhớ đệm được xếp hàng để đi vào đĩa và sau đó nói "ok, xong". Vì vậy, chương trình nghĩ rằng nó đã sao chép tất cả mọi thứ. Sau đó, chương trình sẽ đóng tệp, nhưng đột nhiên kernel làm cho nó chờ trong khi bộ đệm đó được đẩy ra đĩa.

Vì vậy, thật không may, chương trình không thể cho bạn biết sẽ mất bao lâu để xóa bộ đệm vì nó không biết.

Nếu bạn muốn thử một số thủ thuật sử dụng năng lượng, bạn có thể giảm kích thước bộ đệm mà Linux sử dụng bằng cách đặt tham số kernel vm.dirty_bytesthành một cái gì đó như 15000000(15 MB). Điều này có nghĩa là ứng dụng không thể nhận được nhiều hơn 15 MB trước tiến độ thực tế của nó. (Bạn có thể thay đổi các tham số kernel khi đang di chuyển sudo sysctl vm.dirty_bytes=15000000nhưng để chúng ở lại trong quá trình khởi động lại yêu cầu thay đổi tệp cấu hình giống như /etc/sysctl.confcó thể dành riêng cho bản phân phối của bạn.)

Một tác dụng phụ là máy tính của bạn có thể có thông lượng ghi dữ liệu thấp hơn với cài đặt này, nhưng về tổng thể, tôi thấy hữu ích khi thấy rằng một chương trình đang chạy trong một thời gian dài trong khi nó ghi nhiều dữ liệu so với sự nhầm lẫn của việc có chương trình dường như được thực hiện với công việc của nó nhưng hệ thống bị chậm trễ do kernel thực hiện công việc thực tế. Đặt dirty_bytesthành một giá trị nhỏ hợp lý cũng có thể giúp ngăn hệ thống của bạn không phản hồi khi bạn thiếu bộ nhớ trống và chạy một chương trình đột nhiên ghi nhiều dữ liệu.

Nhưng, đừng đặt nó quá nhỏ! Tôi sử dụng 15MB như một ước tính sơ bộ rằng hạt nhân có thể xóa bộ đệm vào ổ cứng bình thường trong 1/4 giây hoặc ít hơn. Nó giữ cho hệ thống của tôi không cảm thấy "lag".

— dữ liệu
nguồn

Tôi đã tìm kiếm một bản sửa lỗi cho vấn đề này trong một năm hoặc hơn, tôi nghĩ rằng nó chỉ là một lỗi trong linux. Cảm ơn rất nhiều.

— Sidahmed

Linux noob ở đây, ai đó có thể đăng cách thay đổi các giá trị <Dirt_bytes> không?

— Brofigator

@Brofigator Ồ, xin lỗi, tôi nên mô tả nó bằng tên chính thức thay vì / Proc chi tiết. Câu trả lời được cập nhật.

— dataless

Điều này tương tự với unix.stackexchange.com/questions/107703/ Khăn --- nên đã được sửa, nhưng tin tôi đi, không phải vậy. Tôi đã phải thêm nó vào Ubuntu 18.04 để ngừng hành xử buồn cười ...

— Rmano

Hoạt động trên Fedora 30 cũng vậy. Tôi ngạc nhiên khi thấy hành vi ngu ngốc như vậy ngay cả trong các bản phân phối Linux hiện đại.

— sziraqui

Câu hỏi cũ, nhưng dường như vấn đề vẫn xuất hiện. Đặt bộ đệm thành 15MB như được đề xuất ở đây không hoạt động trên Ubuntu 19.04 và khiến hệ thống của tôi bị đình trệ.

Tôi đã cố gắng sao chép một tệp 1,5 GB vào ổ 1632 trống (mới được định dạng). Tôi để nó chạy trong khoảng 10 phút chỉ để xem nó có kết thúc hay không, không có may mắn.

Định dạng lại thành NTFS cho phép thao tác kết thúc sau chưa đầy 10 giây. Tôi không biết tại sao điều này lại quan trọng bởi vì FAT32 sẽ cho phép mọi thứ dưới 2 GB, nhưng nó dường như hoạt động tốt. Không phải là một sửa chữa lý tưởng cho các ổ đĩa bạn muốn sử dụng với MacOS, nhưng một cách giải quyết dễ dàng cho tất cả các trường hợp sử dụng khác. Tôi tưởng tượng exFAT sẽ hoạt động tương tự, nhưng tôi đã không kiểm tra nó.

— Jacob Jones
nguồn