Diskler (usb muhafazasında) takılı değilken bile uyanmaya devam eder

Kurmak

Nas sunucuma (ubuntu sunucusu 14.04) bağlı dört sürücü içeren USB muhafazasına (Buffalo DriveStation Quad) sahibim. Kasa JBOD moduna ayarlandığından, Linux'taki tüm diskleri göreceğim.

Disklerden ikisi (sdb ve sdc) yazılım baskını /dev/md0(raid1) olarak yapılandırılmıştır . Ve dergi olmadan ext4 dosya sistemi ile /dev/md0tek bölüm ( /mnt/part1) olarak monte edilir .

Diğer iki disk (sdd ve sde), bir mantıksal bölüm monte ettiğim bir birim grubu olarak LVM ile kurulur. Bunlardan biri tüm hacim grubu kapasitesinin% 90'ı ( /mnt/part2), diğeri ise% 10'udur ( /mnt/part3). Her ikisi de günlük kaydı olmadan ext4'tür.

APM Sorunları

Sorunlarım varsayılan APM modlarıyla başladı, çünkü sabit sürücülerin kafasının her birkaç dakikada oldukça agresif bir şekilde park ettiğini fark ettim. Konuyu biraz araştırdıktan sonra, sonunda kullandım hdparm -B198 /dev/sd[bcde]. Bu, bir miktar güç tasarrufu sağlıyor gibi görünüyor, ancak gerçekten herhangi bir kafa parkı yapmadan.

Uyku var mı?

Şu anki durumdan biraz memnunum, ancak etkinlik yoksa sürücülerin uykuya dalmasını istiyorum. Özellikle sdb ve sdc ( /mnt/part1) gerçekten% 95 oranında herhangi bir etkinlik almıyor. Ne denediysem sorun, sürücülerin bir iki dakikadan daha uzun süre uyumaması gibi görünüyor.

Tüm bölümlerin bağlantısını kesmek ve vermek hdparm -y /dev/sd[bcde], sürücüleri uyku moduna geçirir , ancak sadece birkaç dakika için. Bundan sonra hepsi birer birer uyanacak. Block_dump ( echo 1 > /proc/sys/vm/block_dump) etkinleştirerek sorunu hata ayıklamaya çalıştım , ancak disklere erişim görmüyorum.

Ayrıca APM'yi devre dışı bırakmaya hdparm -B255 /dev/sd[bcde]ve onlardan sonra uyumalarını emretmeye çalıştım , ama aynı şey. Sürücüler birkaç dakika sonra uyanıyor.

Ben yok mdadmDaemon modu (günde bir kez sadece tek çek) çalışan, ya da motora sondalama başka bir şey var olmalıdır. Peki, daha sonra ne yapacağınıza dair herhangi bir fikir var mı? Buffalo USB muhafazası sadece berbat mı (ve kendi başına mı?)

Güncelleme # 1

Verdikten sonra disklerin uyanması ne kadar zaman aldım hdparm -y /dev/sd[bc]. Aşağıdaki zaman damgaları deseni gösterir:

00:00 hdparm -y /dev/sd[bc]
00:40 disks start to wake up
00:59 disks fully awake
01:00 hdparm -y /dev/sd[bc]
03:40 disks start to wake up
03:59 disks fully awake
04:00 hdparm -y /dev/sd[bc]
06:40 disks start to wake up
06:59 disks fully awake

Yani bir şey her 3 dakikada bir diskleri kontrol ediyor / uyandırıyor. Bekleme moduna geçen ilk komut, kontrol noktasından 40 saniye sonra gerçekleşti.

Güncelleme # 2

Makineyi ile yeniden başlattı acpi=off apm=off. Ya da yardım etmedi. Btw, makine Lenovo L520 dizüstü bilgisayar. Birisinin bunu alakalı bulması durumunda.

Biraz aşırıya kaçabilir, ancak SystemTapbu diskte hangi işlemin g / Ç yaptığını belirlemenize yardımcı olabilir.

Sistem Dokümanı Hazırla

[root@localhost ~]# stap-prep
snip

İzleme komut dosyasını yükle

[root@localhost ~]# cat >/tmp/traceio2.stp
#! /usr/bin/env stap
global device_of_interest

probe begin {
  /* The following is not the most efficient way to do this.
      One could directly put the result of usrdev2kerndev()
      into device_of_interest.  However, want to test out
      the other device functions */
  dev = usrdev2kerndev($1)
  device_of_interest = MKDEV(MAJOR(dev), MINOR(dev))
}

probe vfs.write, vfs.read
{
  if (dev == device_of_interest)
        printf ("%s(%d) %s 0x%x\n",
            execname(), pid(), ppfunc(), dev)
}

İzlemek istediğiniz cihaz kimliğini bulun, bu durumda / dev / sda5'i izleyeceğim

[root@localhost ~]#  df -k /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda5       18141508 16293424    903496  95% /
[root@localhost ~]# ls -l /dev/sda5
brw-rw----. 1 root disk 8, 5 Jul  1 01:21 /dev/sda5
[root@localhost ~]# 

Onaltılık büyük + küçük sayı (8,5) kullanarak izleyin. Suçlu bulun. Rejoice

[root@localhost ~]# /tmp/traceio2.stp 0x805
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
lightdm(503) vfs_write 0x800005
bash(3036) vfs_read 0x800005
bash(3036) vfs_read 0x800005
^C
[root@localhost ~]#