Đĩa (trong hộp đựng USB) tiếp tục thức dậy ngay cả khi không được gắn

Thiết lập

Tôi có vỏ USB (Buffalo DriveStation Quad) chứa bốn ổ đĩa được kết nối với máy chủ của tôi (máy chủ Ubuntu 14.04). Bao vây được cấu hình ở chế độ JBOD, vì vậy tôi sẽ thấy tất cả các đĩa trong Linux.

Hai trong số các đĩa (sdb và sdc) được cấu hình với phần mềm đột kích là /dev/md0(raid1). Và /dev/md0được gắn dưới dạng phân vùng đơn ( /mnt/part1) với hệ thống tập tin ext4 mà không cần ghi nhật ký.

Hai đĩa khác (sdd và sde) được thiết lập với LVM là một nhóm âm lượng, từ đó tôi đã gắn hai phân vùng logic. Một trong số đó là 90% toàn bộ dung lượng nhóm ( /mnt/part2) và một là 10% ( /mnt/part3). Cả hai cũng là ext4 mà không cần nhật ký.

Vấn đề APM

Các vấn đề của tôi bắt đầu với các chế độ APM mặc định, vì tôi nhận thấy rằng các ổ đĩa cứng đỗ khá tích cực cứ sau vài phút. Sau khi nghiên cứu chủ đề một chút, cuối cùng tôi đã sử dụng hdparm -B198 /dev/sd[bcde]. Điều này dường như cho phép một số mức tiết kiệm năng lượng, nhưng không thực sự làm bất kỳ bãi đậu xe đầu.

Có ngủ không?

Tôi rất hài lòng với tình hình hiện tại, nhưng tôi vẫn muốn các ổ đĩa đi ngủ nếu không có hoạt động. Đặc biệt là sdb và sdc ( /mnt/part1) không thực sự có bất kỳ hoạt động nào trong 95% thời gian. Dù tôi đã thử, vấn đề dường như là các ổ đĩa không ngủ lâu hơn một hoặc hai phút.

Việc ngắt kết nối tất cả các phân vùng và phát hành hdparm -y /dev/sd[bcde]sẽ đưa các ổ đĩa vào chế độ ngủ, nhưng chỉ trong vài phút. Sau đó tất cả sẽ thức dậy từng người một. Tôi đã cố gắng gỡ lỗi sự cố bằng cách bật block_dump ( echo 1 > /proc/sys/vm/block_dump), nhưng không thấy bất kỳ quyền truy cập nào vào các đĩa.

Tôi cũng đã cố gắng vô hiệu hóa APM hdparm -B255 /dev/sd[bcde]và yêu cầu họ ngủ sau đó, nhưng điều tương tự. Vẫn là những ổ đĩa thức dậy sau vài phút.

Tôi không mdadmchạy trong chế độ daemon (chỉ một lần kiểm tra một lần một ngày), cũng không nên có bất cứ điều gì khác khi thăm dò các ổ đĩa. Vì vậy, bất kỳ ý tưởng về những gì để thử tiếp theo? Có phải vỏ USB Buffalo chỉ là crappy (và nó tự làm)?

Cập nhật số 1

Tôi mất thời gian để mất bao lâu để các đĩa thức dậy sau khi phát hành hdparm -y /dev/sd[bc]. Các dấu thời gian sau minh họa mô hình:

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

Tức là có vẻ như một cái gì đó kiểm tra / đánh thức các đĩa cứ sau 3 phút. Lệnh đầu tiên để chuyển sang chế độ chờ chỉ là 40 giây từ trạm kiểm soát.

Cập nhật số 2

Khởi động lại máy với acpi=off apm=off. Cũng không giúp được gì. Btw, máy là laptop Lenovo L520. Chỉ trong trường hợp ai đó thấy có liên quan.

Có thể hơi quá mức, nhưng SystemTapcó thể giúp bạn xác định quá trình đang thực hiện i / o trên đĩa đó.

Chuẩn bị SystemTap

[root@localhost ~]# stap-prep
snip

Cài đặt tập lệnh theo dõi

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

Tìm ra id thiết bị bạn muốn theo dõi, trong trường hợp này tôi sẽ theo dõi / 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 ~]# 

Giám sát, sử dụng số chính + số phụ (8,5) trong hex. Tìm thủ phạm. Hân hoan

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