Mengapa PC saya membeku saat saya menyalin file ke flashdisk?


61

Saya memiliki situasi yang sangat aneh di sini. PC saya berfungsi dengan baik, setidaknya dalam banyak kasus, tetapi ada satu hal yang tidak bisa saya tangani. Ketika saya mencoba menyalin file dari flashdisk saya, semuanya baik-baik saja - Saya mendapat 16-19M / s, itu berfungsi dengan cukup baik. Tetapi ketika saya mencoba menyalin sesuatu ke flashdisk yang sama, PC saya membeku. Pointer mouse berhenti bergerak selama satu atau dua detik, kemudian bergerak sedikit dan berhenti lagi. Ketika ada sesuatu yang diputar, misalnya, di Amarok, suara itu bertindak seperti senapan mesin. Kecepatan melonjak dari 500K / dtk ke 15M / dtk, rata-rata 8M / dtk. Ini terjadi hanya ketika saya menyalin sesuatu ke flashdisk. Ketika proses penyalinan selesai, semuanya kembali normal.

Saya mencoba semuanya - flashdisk lain, port USB yang berbeda di panel depan atau port-port itu dari belakang, saya bahkan mengganti pin USB di motherboard (panel depan), tetapi di mana pun saya meletakkan stik USB saya, selalu sama. Saya mencoba filesystem yang berbeda - fat32, ext4. Saya tidak punya masalah dengan perangkat di Windows, di laptop saya. Itu harus PC saya atau sesuatu di sistem saya. Saya tidak tahu apa yang harus dicari. Saya menggunakan pengujian Debian dengan Openbox mandiri. PC saya agak tua - Pentium D 3GHz, RAM 1GiB, disk WD Green 1,5TB. Jika Anda memiliki sesuatu yang akan membantu saya untuk menyelesaikan masalah ini, saya akan senang mendengarnya.

Saya tidak tahu info apa lagi yang harus saya berikan, tetapi jika Anda memerlukan sesuatu, tanyakan saja, saya akan memperbarui posting ini sesegera mungkin.

Saya mencoba mereproduksi masalah ini di live cd ubuntu 13.04. Saya memasang partisi terenkripsi saya + swap terenkripsi dan menghubungkan flashdisk saya ke port usb. Selanjutnya saya mencoba untuk memulai beberapa aplikasi, dan sekarang saya punya ~ 820MiB di RAM dan sekitar 400MiB di SWAP. Tidak ada masalah dengan penyalinan, tidak ada pembekuan sama sekali, semuanya sebagaimana mestinya. Jadi, sepertinya itu kesalahan sistem, tapi di mana tepatnya? Apa yang akan menyebabkan perilaku aneh seperti itu?


Ketika saya menemukan sesuatu yang mirip dengan ini, itu karena saya memiliki masalah hard drive di laptop saya. Disk memiliki beberapa area yang buruk dan setiap kali saya mencoba membaca sesuatu dari area itu akan membeku sampai selesai. Hanya ide untuk melihat. Mungkin Anda memiliki bad sector di mana Anda mencoba membaca.
slybloty

HDD saya ok, setidaknya pintar mengatakannya (setelah pemindaian penuh).
Mikhail Morfikov

Coba kurangi prioritas IO dari proses penyalinan, mis ionice -c3 cp something.tgz /media/pendrive. Ini akan menempatkan proses yang baru saja muncul cpdalam "idle" kelas prioritas ketiga (= terendah).
n.

Saya mencoba ini, tetapi tidak berpengaruh.
Mikhail Morfikov

@MikhailMorfikov FYI, masalah ini telah diatasi di linux 4.9. Masih belum menguji perbaikannya sendiri. YMMV.
Seamus Connor

Jawaban:


85

Apakah Anda menggunakan Linux versi 64-bit dengan banyak memori? Dalam hal ini masalahnya bisa jadi Linux dapat mengunci selama beberapa menit pada penulisan besar pada perangkat lambat seperti misalnya kartu SD atau stik USB. Ini adalah bug yang diketahui yang harus diperbaiki di kernel yang lebih baru.

Lihat http://lwn.net/Articles/572911/

Penanganan masalah: sebagai masalah root:

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Saya telah menambahkannya ke /etc/rc.localfile saya di mesin 64bit saya.

TANSTAAFL ; perubahan ini dapat (dan mungkin akan) mengurangi throughput Anda ke perangkat ini --- ini adalah kompromi antara latensi dan kecepatan. Untuk kembali ke perilaku sebelumnya Anda bisa

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... yang merupakan nilai default, yang berarti bahwa perilaku writeback akan dikontrol oleh parameter dirty_ratiodan dirty_background_ratio.

Catatan untuk orang yang tidak terlalu ahli dengan linux: file-file di /proc pseudofiles --- hanya saluran komunikasi antara kernel dan ruang pengguna. Jangan pernah menggunakan editor untuk mengubah atau melihatnya; dapatkan sebaliknya prompt shell --- misalnya, dengan sudo -i(rasa Ubuntu) atau su rootdan gunakan echodan cat).

Pembaruan 2016/04/18 tampaknya, bagaimanapun, masalahnya masih ada di sini. Anda dapat melihatnya di LWN.net , dalam artikel ini tentang antrian writeback .


3
Saya memiliki 64bit tetapi hanya 1GiB RAM, dan saya harus memberi tahu Anda solusi ini berfungsi! Saya baru saja mengujinya, dan setelah mengatur dua parameter, tidak ada lagi pembekuan. :)
Mikhail Morfikov

1
Dalam instalasi 14,04 saya, uname -akembali 3.13.0-32-generic, jadi ya. Tetapi saya belum memeriksa apakah tambalan untuk masalah ini akhirnya terintegrasi dalam kernel atau tidak. Saya memiliki mesin 16GB dan tampaknya berfungsi dengan baik tanpa solusi, meskipun saya harus mengatakan bahwa saya tidak mencoba dengan perangkat yang sangat lambat.
Rmano

1
@ IonicăBizău --- yang merupakan pseudo-berkas, tidak mengeditnya dengan vim yang pernah . Dapatkan shell root (with sudo -i) dan gunakan perintah yang disebutkan di atas.
Rmano

1
@Rmano Berhasil! Namun, saya mengeditnya dengan VIM. Terima kasih!
Ionică Bizău

2
Saya menggunakan ubuntu 16.04 pada laptop baru (dengan 16 GB RAM). Saya benar-benar marah dengan masalah ini. Solusi Anda bekerja seperti pesona! Mungkin Anda dapat menambahkan bahwa ini masih bisa dibutuhkan dengan kernel 4.8.0-45.
LGenzelis

3

Alasannya bisa menulis amplifikasi, karena sistem mencoba menulis dalam potongan yang lebih kecil, daripada menghapus blok (melakukan baca / mod / tulis) + blok misalignment.

Untuk memeriksa pengaturan Anda saat ini, lakukan:

cat /sys/block/sd**X**/device/max_sectors

Anda dapat menyempurnakan aturan aula untuk perangkat tersebut:

Ubah nilai USB "max_sectors" untuk seluruh keluarga perangkat

Dalam hal ini saya telah mengganti max_sectors untuk semua perangkat, yang menggunakan standar 240 (penyimpanan USB) ke sektor 32K atau sektor 2K.

Pada sistem saya (Mageia 4, 3.14.24 core i7) saya harus melakukan ini karena kecepatan tulis yang sangat lambat (2MB / detik) di Kingston DT101 G2 16GB:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

dan tambahkan:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

Dan ddkecepatan tulisnya naik 3x kali. mc cpmungkin 10-20x ke atas (setelah saya mulai partisi pertama @ sektor 8192 dan diformat ulang dengan 64k klaster yang disejajarkan):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

untuk memeriksa perataan (centang [sektor mulai data] harus kelipatan 128 (ukuran kluster)). Sesuaikan jumlah sektor yang dicadangkan (-R) jika perlu.

Max_sectors default (240) tampaknya menyebabkan amplifikasi tulis tinggi pada beberapa drive baru yang murah. Tapi hati-hati dengan pengaturan tinggi seperti itu, efek yang sama dicapai pada 2048 sektor (mungkin 1M menghapus blok:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

Uji semua perangkat USB lama Anda, apakah masih berfungsi dengan baik. Gunakan atribut vendor / model dalam file aturan untuk lebih spesifik.


1

perangkat keras vs. perangkat lunak

Saya mengalami masalah aneh yang mirip dengan ini dengan USB thumbdrives, dan dalam penelitian saya hampir selalu merupakan masalah driver atau perangkat keras khusus di dalam PC / Motherboard.

Saya tahu ini karena saya punya beberapa sistem perangkat keras yang identik, dan pada satu, saya bisa melakukan operasi ini tanpa masalah, sementara yang lain masalah muncul.

Apa yang harus dilakukan?

Opsi Anda sangat terbatas di sini. Satu-satunya hal yang dapat Anda lakukan adalah memastikan Anda memiliki BIOS / firmware terbaru yang diinstal pada sistem Anda, dan pastikan Anda memiliki versi terbaru dari paket disto Anda.

Di luar itu semua yang bisa saya sarankan adalah memastikan bahwa Anda menghindari situasi ini dengan tidak mencoba menyalin file ketika salinan lain sedang berlangsung.

Jika Anda memiliki tipe kepribadian di mana hal-hal seperti ini menjengkelkan Anda, Anda bisa mencoba distro langsung Linux lain dan ulangi langkah-langkah yang mengarah ke masalah Anda. Ini hanya akan menghilangkan apakah itu masalah khusus distro atau masalah perangkat keras seperti yang saya jelaskan di atas. Itu akan menjadi penghiburan kecil, tapi aku selalu suka mengetahui hal-hal daripada mengubur kepalaku di pasir, dan tidak.

Ada yang lain?

Jika Anda benar-benar terobsesi, Anda dapat mencoba menjalankan aplikasi yang sedang Anda salin dengan straceharapan dapat menangkap sistem dengan cara apa pun yang dibekukan oleh panggilan sistem. Anda harus dapat melakukan ini dari baris perintah juga.

Contoh

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Kemudian saat itu berjalan mulai yang lain.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Sistem ini diharapkan akan membeku selama operasi ini dan mungkin Anda akan beruntung dan menemukan beberapa asap di salah satu file log tersebut.


Saya selalu menggunakan satu-satunya contoh menyalin file. Saya memiliki BIOS yang diperbarui (2008), dan tidak ada versi yang lebih baru sejak itu. Saya pikir itu bukan BIOS. Distro debian saya juga diperbarui ke cabang pengujian. Saya mencoba menggunakan stracedan membintangi pembekuan hampir secara instan, jadi saya menunggu beberapa detik dan mematikan proses. Saya mendapat 1Mb log, tetapi saya tidak bisa membacanya, saya tidak tahu harus mencari apa. Anda dapat memeriksanya di sini pastebin.com/u29RvqgC - ini bukan log lengkap (terbatas pada 500Kb), tetapi hanya ada baris yang serupa dengan yang ada di akhir. Saya akan mencoba mereproduksi masalah ini dengan live cd ubuntu.
Mikhail Morfikov

Saya memperbarui pertanyaan tentang live cd testing.
Mikhail Morfikov

@MikhailMorfikov - Saya pikir Anda cukup banyak pada akhir apa yang dapat Anda lakukan. Perangkat keras Anda sudah cukup tua (2008) dan benar-benar tidak banyak yang dapat Anda lakukan di luar apa yang telah saya uraikan di atas.
slm

Tetapi bahkan pcs yang lebih tua dapat menyalin file tanpa masalah.
Mikhail Morfikov

@MikhailMorfikov - Umur bukan satu-satunya faktor, tetapi kap kemungkinan mendapatkan pembaruan untuk firmware atau pembaruan untuk perangkat lunak untuk perangkat keras lama rendah, itulah yang saya maksud.
slm
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.