Bir pendrive'a dosya kopyalarken bilgisayarım neden donuyor?

Burada gerçekten garip bir durum var. Bilgisayarım en azından çoğu durumda iyi çalışıyor ancak başa çıkamayacağım bir şey var. Benim pendrive bir dosyayı kopyalamaya çalıştığımda, her şey yolunda - 16-19M / s var, oldukça iyi çalışıyor. Ancak aynı yayına bir şeyi kopyalamaya çalıştığımda, bilgisayarım donuyor. Fare işaretçisi bir veya iki saniye boyunca hareket etmeyi durdurur, sonra biraz hareket eder ve tekrar durur. Bir şey çalınırken, örneğin Amarok'ta ses makineli tüfek gibi davranır. Hız 500K / s'den 15M / s'ye, ortalama 8M / s'ye atlar. Bu yalnızca bir pendrive'a bir şey kopyaladığımda oluşur. Kopyalama işlemi tamamlandığında, her şey normale döner.

Her şeyi denedim - diğer pendrive, ön paneldeki farklı bir USB portu veya arkadaki portlar, anakarttaki USB pinlerini bile değiştirdim (ön panel), ancak USB çubuğumu nereye koyduğum önemli değil, her zaman aynı. Farklı dosya sistemini denedik - fat32, ext4. Dizüstü bilgisayarımda Windows'taki aygıtta sorunum yok. Benim bilgisayarım veya sistemimdeki bir şey olmalı. Ne arayacağımı bilemiyorum. Bağımsız Openbox ile Debian testlerini kullanıyorum. Bilgisayarım biraz eski - Pentium D 3GHz, 1 GB RAM, 1,5 TB WD Green disk. Bu sorunu çözmeme yardım edecek bir şeyin varsa, bunu duyduğuma sevinirim.

Başka ne bilgi vermeliyim bilmiyorum, ama bir şeye ihtiyacın olursa, sadece sor, en kısa zamanda bu yazıyı güncelleyeceğim.

Bu sorunu ubuntu 13.04 live cd'sinde yeniden oluşturmaya çalıştım. Şifreli bölme + şifreli takas taktım ve pendrive'ımı bir usb bağlantı noktasına bağladım. Daha sonra bazı uygulamaları başlatmaya çalıştım ve şimdi RAM'de ~ 820MiB ve SWAP'ta yaklaşık 400MiB'im var. Kopyalama ile ilgili bir sorun yok, hiç donma yok, her şey olması gerektiği gibi. Öyleyse, sistemin bir hatası gibi görünüyor, ama tam olarak nerede? Böyle garip bir davranışa ne sebep olur?

Çok fazla belleğe sahip 64 bit bir Linux sürümü kullanıyor musunuz? Bu durumda problem, Linux'un SD kartlar veya USB bellekler gibi yavaş cihazlardaki büyük yazılardaki dakikalarca kilitlenmesi olabilir. Yeni çekirdeklerde düzeltilmesi gereken bilinen bir hata.

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

Geçici çözüm: kök sorunu olarak:

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

/etc/rc.local64bit makinelerimde dosyama ekledim .

TANSTAAFL ; Bu değişiklik, bu cihazlara veriminizi düşürebilir (ve muhtemelen de artırabilir) --- bu gecikme ve hız arasında bir uzlaşmadır. Önceki davranışa geri dönmek için

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

... Writeback davranış parametreleri tarafından kontrol edilecektir anlamına varsayılan değerler, hangi dirty_ratiove dirty_background_ratio.

Linux konusunda uzman olmayan kişiler için not: içindeki dosyalar /proc sözde dosyalardır - sadece çekirdek ve kullanıcı alanı arasındaki iletişim kanalları. Asla değiştirmek veya bakmak için bir editör kullanmayın; bunun yerine bir kabuk istemi alın --- örneğin, sudo -i(Ubuntu flavours) veya su rootkullanın echove cat).

2016/04/18 Güncellemesi , sonuçta sorunun hala burada olduğu görülüyor. Sen de bakabilirsin LWN.net içinde, geri yazma kuyruklar hakkında bu makalede .

Bunun nedeni, sistemi silme bloğundan (okuma / mod / yazma) + blok yanlış hizalamadan daha küçük boyutlarda yazmaya çalıştığından, yazma büyütmesi olabilir.

Mevcut ayarlarınızı kontrol etmek için:

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

Bu cihazlar için salon kurallarını ayarlayabilirsiniz:

Tüm cihaz ailesi için USB "max_sectors" değerini değiştirin

Bu durumda, varsayılan 240'ı (USB depolama birimi) 32K sektöre veya 2K sektöre kullanan tüm cihazlar için max_sectors değiştirdim.

Sistemimde (Mageia 4, 3.14.24 core i7) Kingston DT101 G2 16GB’de oldukça yavaş yazma hızları (2MB / sn) nedeniyle bunu yapmak zorunda kaldım:

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

ve Ekle:

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

Ve ddyazma hızı 3 kat arttı. mc cpmuhtemelen 10-20x yukarı (8192’nci sektördeki ilk bölüme başladıktan ve 64k hizalı kümelerle yeniden biçimlendirdikten sonra):

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

hizalamayı kontrol etmek için ([veri başlangıç ​​sektörü] 128'in katları olmalıdır (küme boyutu)). Gerekirse, ayrılmış sektörlerin sayısını (-R) ayarlayın.

Varsayılan max_sectors (240), ucuz yeni sürücülerden bazılarında yüksek yazma kuvvetlendirmesine neden gibi görünüyor. Ancak bu kadar yüksek ayarlarda çok dikkatli olun, benzer etki 2048 sektörde (muhtemelen 1M silme blokları:

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

Tüm eski USB aygıtlarınızı hala iyi çalıştıklarını test edin. Daha belirgin olmak için kural dosyalarında satıcı / model özelliklerini kullanın.

donanım ve yazılım

USB parmak uçlarında buna benzer garip bir sorunla karşılaştım ve araştırmamda neredeyse her zaman bir sürücü sorunu ya da PC / Anakart içindeki belirli bir donanım var.

Bunu biliyorum çünkü aynı donanımda olan birkaç sistemim var ve bir tanesinde problem olmadan bu işlemi sorunsuzca yapabiliyorum.

Ne yapalım?

Seçenekleriniz burada gerçekten sınırlı. Yapabileceğiniz şeyler hakkında, sisteminizde en son BIOS / ürün yazılımının kurulu olduğundan ve disto paketlerinin en son sürümlerine sahip olduğunuzdan emin olun.

Bunun ötesinde önerebileceğim tek şey, başka bir kopya devam ederken dosyaları kopyalamaya çalışarak bu durumdan kaçınmanızı sağlamak.

Bunun gibi şeylerin sizi rahatsız ettiği kişilik tipine sahipseniz, başka bir Linux dağıtımını deneyebilir ve probleminize yol açan adımları tekrarlayabilirsiniz. Bu, yalnızca yukarıda açıkladığım gibi dağıtıma özgü bir sorun mu yoksa donanım sorunu mu olduğunu ortadan kaldıracaktır. Küçük bir teselli olur, ama her zaman kafamı kuma gömmek yerine her şeyi bilmek isterim, değil.

Başka herhangi bir şey?

Eğer gerçekten takıntılıysanız, kopyayı yaptığınız uygulamayı, stracesistem çağrısının donması durumunda sistemde yakalamak ümidiyle çalıştırmayı deneyebilirsiniz . Bunu komut satırından da yapabilmelisiniz.

Örnek

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

O zaman bu koşarken başkasını başlat.

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

Sistem bu işlem sırasında umarız donacak ve belki de şanslı olacak ve bu günlük dosyalarının her ikisinde de biraz duman bulacaksınız.