[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Disk Spin-down problems: nmbd to blame



Hi running Debian etch on an NSLU2. USB2 Disk will spin-down by itself after 10 minutes idle. /dev and /var/log are on RAMFS.

Slug2:~# mount
/dev/sda1 on / type ext3 (rw,noatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda2 on /public type ext3 (rw,noatime,errors=remount-ro)
ramfs on /mnt/tmpdev type ramfs (rw,maxsize=128)
/dev on /dev.state type none (rw,bind)
/mnt/tmpdev on /dev type none (rw,bind)
ramfs on /mnt/tmpvar type ramfs (rw,maxsize=256)
/var/log on /var.log.state type none (rw,bind)
/mnt/tmpvar on /var/log type none (rw,bind)

/dev/sda1 is also mounted with "noatime".

As long as nmbd is not started spin-down works perfectly.
I used strace to look at the nmbd process, there I can see that it is the access to /var/cache/samba/browse.dat that is causing the disk to be continually re-read.

# strace -t -p1924 -etrace=open,close,read,write
Process 1924 attached - interrupt to quit
17:26:54 --- SIGCHLD (Child exited) @ 0 (0) ---
17:27:15 --- SIGCHLD (Child exited) @ 0 (0) ---
17:27:35 --- SIGCHLD (Child exited) @ 0 (0) ---
17:27:55 --- SIGCHLD (Child exited) @ 0 (0) ---
17:27:55 close(16)                      = 0
17:28:16 --- SIGCHLD (Child exited) @ 0 (0) ---
17:28:36 --- SIGCHLD (Child exited) @ 0 (0) ---
17:28:56 --- SIGCHLD (Child exited) @ 0 (0) ---
17:29:16 --- SIGCHLD (Child exited) @ 0 (0) ---
17:29:37 --- SIGCHLD (Child exited) @ 0 (0) ---
17:29:57 --- SIGCHLD (Child exited) @ 0 (0) ---
17:30:07 close(16)                      = 0
17:30:17 --- SIGCHLD (Child exited) @ 0 (0) ---
17:30:38 --- SIGCHLD (Child exited) @ 0 (0) ---
17:30:58 --- SIGCHLD (Child exited) @ 0 (0) ---
17:31:02 open("/var/cache/samba/browse.dat.", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0644) = 16
17:31:02 write(16, "\"HOME\"                    c00010"..., 216) = 216
17:31:02 close(16)                      = 0
17:31:22 --- SIGCHLD (Child exited) @ 0 (0) ---
17:31:33 --- SIGCHLD (Child exited) @ 0 (0) ---
17:32:04 --- SIGCHLD (Child exited) @ 0 (0) ---
17:32:04 close(16)                      = 0
17:32:24 --- SIGCHLD (Child exited) @ 0 (0) ---
17:32:41 --- SIGCHLD (Child exited) @ 0 (0) ---
17:33:12 --- SIGCHLD (Child exited) @ 0 (0) ---
17:33:32 --- SIGCHLD (Child exited) @ 0 (0) ---
17:33:52 --- SIGCHLD (Child exited) @ 0 (0) ---
17:34:13 --- SIGCHLD (Child exited) @ 0 (0) ---
17:34:13 close(16)                      = 0

So I added a symlink as follows:

/var/cache
# ls -l
insgesamt 28
drwxr-xr-x  3 root     root 4096 2007-11-14 09:33 apt
drwxr-xr-x  2 root     root 4096 2007-07-02 20:52 apt-show-versions
drwxr-xr-x  2 root     root 4096 2007-10-02 21:10 debconf
drwxr-xr-x  2 root     root 4096 2007-06-27 19:19 dictionaries-common
drwxr-xr-x  2 root     root 4096 2006-08-06 10:51 locate
drwxr-sr-x 16 man      root 4096 2007-06-27 18:30 man
drwxrwxr-x  2 mt-daapd root 4096 2007-11-29 16:40 mt-daapd
lrwxrwxrwx  1 root     root   14 2007-08-26 17:30 samba -> /var/log/samba

/var/cache/samba now is symlinked to /var/log/samba, which is on the ramfs.

I can cat /var/cache/samba/browse.dat OK and it shows the correct contents. Seems like I maybe haven't done this correctly. /var/log/samba has its own contents:

/var/log/samba
# ls -l
insgesamt 12
-rw-r--r-- 1 root root  216 2007-11-29 17:20 browse.dat
drwx------ 4 root root    0 2007-08-20 21:36 cores
-rw-r--r-- 1 root root 3321 2007-11-29 16:40 log.nmbd
-rw-r--r-- 1 root root 1396 2007-11-29 16:40 log.smbd
drwxr-xr-x 2 root root    0 2007-08-23 07:45 printing

So I am wonderering what else may be wrong. Seems like nmbd is really only accessing this file (According to strace at least).

Could anyone give me  some ideas on debugging this?

Cheers Brian




Reply to: