Disk (dalam penutup usb) tetap bangun meskipun tidak dipasang

Mempersiapkan

Saya memiliki penutup USB (Buffalo DriveStation Quad) yang berisi empat drive yang terhubung ke server nas saya (server ubuntu 14.04). Enklosur dikonfigurasikan ke mode JBOD, jadi saya akan melihat semua disk di Linux.

Dua disk (sdb dan sdc) dikonfigurasi dengan perangkat lunak raid as /dev/md0(raid1). Dan /dev/md0sudah terpasang sebagai partisi tunggal ( /mnt/part1) dengan sistem file ext4 tanpa journalling.

Dua disk lainnya (sdd dan sde) diatur dengan LVM sebagai satu grup volume, dari mana saya telah memasang dua partisi logis. Salah satunya adalah 90% dari kapasitas grup volume keseluruhan ( /mnt/part2), dan satu lagi adalah 10% ( /mnt/part3). Keduanya juga ext4 tanpa penjurnalan.

Masalah APM

Masalah saya mulai dengan mode APM default, karena saya perhatikan bahwa kepala hard drive terparkir cukup agresif setiap beberapa menit. Setelah meneliti topik tersebut sebentar, saya akhirnya menggunakan hdparm -B198 /dev/sd[bcde]. Ini tampaknya memungkinkan beberapa tingkat penghematan daya, tetapi tanpa benar-benar melakukan parkir kepala.

Apa tidur?

Saya agak senang dengan situasi saat ini, tetapi saya masih ingin drive tertidur jika tidak ada aktivitas. Terutama sdb dan sdc ( /mnt/part1) yang tidak benar-benar mendapatkan aktivitas apa pun selama 95% waktu. Apa pun yang saya coba, masalahnya tampaknya drive tidak tidur lebih dari satu atau dua menit.

Melepas semua partisi, dan mengeluarkan hdparm -y /dev/sd[bcde]akan menempatkan drive ke mode tidur, tetapi hanya selama beberapa menit. Setelah itu mereka semua akan bangun satu per satu. Saya sudah mencoba men-debug masalah dengan mengaktifkan block_dump ( echo 1 > /proc/sys/vm/block_dump), tetapi tidak melihat akses ke disk.

Saya juga mencoba menonaktifkan APM hdparm -B255 /dev/sd[bcde], dan memerintahkan mereka untuk tidur setelah itu, tetapi hal yang sama. Tetap drive bangun setelah beberapa menit.

Saya tidak harus mdadmberjalan dalam mode daemon (hanya sekali cek sekali sehari), juga tidak ada hal lain yang menyelidiki drive. Jadi ada ide tentang apa yang harus dicoba selanjutnya? Apakah kandang USB Buffalo hanya jelek (dan apakah ini sendiri)?

Perbarui # 1

Saya membutuhkan waktu berapa lama untuk disk untuk bangun setelah mengeluarkan hdparm -y /dev/sd[bc]. Stempel waktu berikut menggambarkan pola:

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

Yaitu tampaknya ada sesuatu yang memeriksa / membangunkan disk setiap 3 menit. Perintah pertama untuk masuk ke mode siaga hanya 40 detik dari pos pemeriksaan.

Perbarui # 2

Reboot mesin dengan acpi=off apm=off. Juga tidak membantu. Btw, mesinnya adalah laptop Lenovo L520. Untuk berjaga-jaga jika seseorang menemukan itu relevan.

— Toni
sumber

$ 0,02 saya: coba hentikan semua yang ada di mesin Anda (daemon yang terlalu bersemangat mungkin mencari-cari perangkat), gunakan opsi mount noatime.

— Laszlo Valko

@LaszloValko, berhasil mengurangi proses menjadi upstart-{socket,file}-bridge, dhclient, getty and sshd- tidak berhasil :(. Tentu saja ada banyak proses kernel yang berjalan (yang tercantum dalam tanda kurung). Belum melihat apakah saya dapat menguranginya dengan beberapa parameter kernel ... dan mana yang akan menjadi kandidat yang bagus

— Toni

Cara mudah untuk mengetahui apakah itu enklosur atau OS Anda adalah untuk menurunkan drive kemudian lepaskan USB.

— Circus Cat

@ qasdfdsaq, sayangnya Buffalo Drivestation ini hadir dengan beberapa fitur powerdown yang mewah. Enklosur mati sendiri segera ketika ada kabel usb dicabut. Bahkan saklar daya hanya memiliki opsi "mati" dan "otomatis".

— Toni

Hanya bidikan dalam kegelapan: periksa lintasan yang dipangkas & bind mount yang diupdateb.conf, sehingga lintasan ini dilewati secara eksplisit (layanan 'temukan'); itu bisa dengan mudah menjadi layanan serupa lainnya.

— michael

Mungkin sedikit berlebihan, tetapi SystemTapdapat membantu Anda mengidentifikasi proses apa yang saya lakukan pada disk itu.

Siapkan SystemTap

[root@localhost ~]# stap-prep
snip

Instal skrip jejak

[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)
}

Mencari tahu id perangkat yang ingin Anda monitor, dalam hal ini saya akan memantau / dev / sda5

[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 ~]#

Monitor, menggunakan nomor utama + minor (8,5) dalam hex. Temukan pelakunya. Bersuka cita

[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 ~]#

— steve
sumber