2

I brought a 2TB WD black drive. Installed it on an external USB/eSATA enclosure, and connected to the pi (via USB obviously). Partitioned it with gdisk with GPT (with protective MBR) and created one big partition of 1.8 TB, formatted in ext4. Rebooted to automount. Automount OK. The disk is empty, and the enclosure LED keeps blinking on each second. I tried writing via SAMBA from my laptop and worked OK, played the file on XBMC and everything was OK. But I am still worried about the disk activity since it will be powered 24x7 and because I had a 640GB drive (NTFS formatted) until now and the disk activity light wasn't blinking each second as it does now. I tried to use iotop to confirm wich process is writing/reading to/from the disk, but it says it cannot run on the raspbmc kernel.

UPDATE:

I have done some testing since my first posting:

  • I hooked the disk to a desktop computer via USB, running slax (usb-bootable slackware-based distro). Has the same behavior, activity LED blinks each second.

  • I also booted up a fresh install of raspbian, hooked the drive to the pi, and is the same as raspbmc.

  • Finally installed iotop on raspbian and could pin point the issue: the process jbd2/sda1-8 is the cause. Apparently is related to journaling.

Found some posts about the issue:

https://bbs.archlinux.org/viewtopic.php?id=148954

but no clear fix.

I think that this may be related to the fact that all distros I have tested until now are booted from USB/removable storage. May be there is some journaling config on the raspbian/slax to write more often, given that are prepared to run on removable devices. But it sounds crazy because removing the boot devices while the system is running will probably turn the system too unstable to work (if it even manages to keep running).

NEW UPDATE: Disabled ext4 journaling on the filesystem (whooping 200 gb!) using

tune2fs -O ^has_journal /dev/sda1

Activity led still blinks each second! iotop shows ext4lazyinit but not as frequent as the LED blinks. jbd2 still runs but for the SD card only. The last stop is USB sniffing, I will try it as soon as I have some spare time.

Improve this question
5
  • Does the drive do that when hooked up to a normal computer? Does the enclosure have its own power source or is it getting juice directly from the pi's usb port?
    – goldilocks ♦
    Mar 20, 2013 at 6:16
  • The enclosure has its own power (it has also two LEDs, green: powered, red: activity). When the USB port isn't connected activity LED does not blink. I had a similar setup with a NTFS formatted drive in the same enclosure and this didn't happened. I will try hooking it up by usb to another PC, because I used eSATA on another computer in the past but the activity LED doesn't work when you use eSATA on the enclosure.
    – Diego
    Mar 20, 2013 at 11:20
  • Does it blink if you leave it connected but unmount the filesystem?
    – Craig
    Mar 20, 2013 at 20:49
  • Hooked up the enclosure to a desktop computer running slax (a usb-bootable version of slackware). Same behavior as the pi, the activity led blinks each second. Unmounting the fs (on the desktop) stops the activity led. dmesg has some errors but apparently not related (are listed before plugging the usb enclosure). FS detection and mounting seems OK, "EXT4-fs with ordered data mode. Opts: (null)". Going back to the pi with raspbian instead of raspbmc...
    – Diego
    Mar 22, 2013 at 23:38
  • 2
    Does this answer your question? The usb-storage driver seems to be constantly accessing external USB drive on a Pi B+
    – Dmitry Grigoryev
    Oct 4, 2020 at 12:09

2 Answers 2

Reset to default
1

I thought I had a similar issue with my enclosure. I have a 4-bay enclosure with 3 disks in it currently (each one is ext4 formatted). The drives are automounted with noatime. The activity light on the enclosure regularly flashes and I started down the same path of investigating I/O activity, but found nothing.

I eventually decided it was innocuous because each hard drive spins down correctly when idle and then spins up when I access data (with my drives I can clearly hear them doing this and there's an obvious lag time on first access after idle). Even though all the drives spin down the LED keeps flashing. I decided to just not worry about it. But I'm interested to hear if anyone finds out why it's happening and if there's a way to stop it.

Is your drive actually spinning constantly or does it spin down when idle? (There are lots of sites that discuss setting a drive to do so.)

Improve this answer
1
  • Is hard to tell about the spinning down because the enclosure has a fan that is constantly powered. And besides I am still testing the setup, I din't give the drive enough time to spin down. I but I think that this is not related (or at least not related from the hard drive side) with the head parking policy. I'm doing some extra tests, I will post back.
    – Diego
    Mar 22, 2013 at 23:56
0

I don't know what is causing io on your Raspberry Pi

iotop runs on my kernel

uname -a
Linux raspberrypi 3.6.11+ #393 PREEMPT Fri Mar 8 16:36:28 GMT 2013 armv6l GNU/Linux

iotop --version
iotop 0.4.4

I updated the firmware and kernel with the "hexxeh rpi-update" - perhaps that's needed for iotop to work. https://github.com/Hexxeh/rpi-update

try mounting with "noatime" - that's what i do with my root filesystem on ext4

here's my "grep root /etc/fstab"

/dev/root  /               ext4    defaults,noatime  0       1

USB port sniffing http://biot.com/blog/usb-sniffing-on-linux

mount -t debugfs none_debugs /sys/kernel/debug
modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/1u

systemtap (sudo apt-get install systemtap) seems like a good tool to watch what's going on with disk IO's

http://sourceware.org/systemtap/wiki

edit: According to this thread, ext4 does what it's supposed to do - there's a few tips to change the update interval. https://bbs.archlinux.org/viewtopic.php?id=113516&p=1

Also, this bugreport for an older kernel has useful info: https://bugzilla.kernel.org/show_bug.cgi?id=39072

There must be some userspace program doint the disk access periodically - perhaps shutting down daemons one at a time will let you find out who's doing the disk access. (samba/bittorrent etc.)

Improve this answer
6
  • This is the iotop's error message: pi@raspbmc:~$ sudo iotop Could not run iotop as some of the requirements are not met: - Linux >= 2.6.20 with - I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING) - VM event counters (CONFIG_VM_EVENT_COUNTERS)
    – Diego
    Mar 20, 2013 at 11:21
  • uname output: Linux raspbmc 3.6.11 #2 PREEMPT Wed Mar 13 17:12:47 UTC 2013 armv6l GNU/Linux
    – Diego
    Mar 20, 2013 at 11:31
  • to get iotop running, you need a kernel with I/O accounting, the raspbmc kernel seems to be compiled without it. I don't know if rpi-update will work on that - I use it on Raspbian
    – Jens Peter Nielsen
    Mar 20, 2013 at 15:08
  • Ok. I will try with noatime first on fstab (it has something to do with ext4 journaling?), then if it doesn't work I have a spare SD card to try with a clean raspbian install.
    – Diego
    Mar 20, 2013 at 15:12
  • If the RPi does nothing on the disk, noatime probably will not change anything - it minimizes disk writes, when the access time doesn't have to be written for every read. I have no clue what is wrong if no programs are reading or writing to the disk - other than it may be a kernel issue with ext4, journaling should not touch the disk after a while, when the writes to the disk have been committed. Perhaps some hardware monitoring daemon is running? (hope someone can come up with a better answer, I should have posted as a comment)
    – Jens Peter Nielsen
    Mar 20, 2013 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.