USB hdd wake up

7 posts / 0 new
Last post
igloome
igloome's picture
USB hdd wake up

Hi,

First of all, I've been testing Kong K3 mod (last build: 23040) with R6300 and globally it works greats. Thanks Kong for this great job.

I've got an issue with my samba and dlna shares that disapear after a while when, I think, my USB WD drives goe to sleep... The shares never go back when I try to access the HDDs through the network.

I read different threads on forums, and I've tried the following trick:
   echo 1 > /sys/block/sda/sevices/scsi_disk*/allow_restart
found on:
  http://www.nslu2-linux.org/wiki/FAQ/DealWithAutoSpinDownOnSeagateFreeAgent
but allow_restart was already set to 1 and the trick had no impact.

I found the follwing topic as well about sd-idle:
  http://infodepot.wikia.com/wiki/DD-WRT_-_Kong_-_sd-idle managemet_script
but I did not found sd-idle on K3 firmware.

With the OEM firmware, my drives were also going to sleep but they were correctly waking up on a access from the network.
Thus, I don't think my issue comes from an embedded sleep feature of the HDD.

Is the HDD idle management performed on another way ?

Any idea about a way to solve the issue ?

Thanks!

igloome
igloome's picture
Hi,

Hi,

My mistake! No link with the hdd spindown.

In fact, inavailability of the shares is due to minidlna process that takes the whole CPU during the scan. The GUI becomes unreachable, Wifi interface goes down and shares become unavailable.
The problem is that minidlan scan takes the whole CPU during hours and even crash when indexing my large drives.

Kong
Kong's picture
igloome said: Hi, My mistake

igloome said: Hi, My mistake! No link with the hdd spindown. In fact, inavailability of the shares is due to minidlna process that takes the whole CPU during the scan. The GUI becomes unreachable, Wifi interface goes down and shares become unavailable. The problem is that minidlan scan takes the whole CPU during hours and even crash when indexing my large drives.

Minidlna currently stores the db either in ram or if jffs is enabled in flash. If you have a large db, then you need to enable jffs otherwise the db will suck up your ram and the router stalls.

When I partition usb drives for usage with the router I always create a swap partition on it, thus even if ram is used the router can swap out.

igloome
igloome's picture
Kong said:  Minidlna

Kong said:  Minidlna currently stores the db either in ram or if jffs is enabled in flash. If you have a large db, then you need to enable jffs otherwise the db will suck up your ram and the router stalls. When I partition usb drives for usage with the router I always create a swap partition on it, thus even if ram is used the router can swap out.

Thanks for the answer, Kong.
And, again, thanks for your great job. I now applied your last build (23270).

For info, I also tried in the last days to manually configure and start minidlna by startup script, storing the db on the USB drive (db_dir), but I got the same issues. I killed the process after 3hours of scan, when the size my db file suddenly decreased...
I can not easily create a swap partition on my drives as they are already in use, but I will try to enable jffs in order to store db in flash.
Hope this will help me, but I'm afraid I will have to wait for a improvement of the scan process as it really takes a long time to re-scan the drives each time the router restarts.

Kong
Kong's picture
Did you check how big your db

Did you check how big your db gets?

In my older builds I had an extra field in order to specify a path for the db on the usb disk, but as we developed this in parallel I did not merge this into dd-wrt but can be done if it makes sense. I haven't done much with minidlna lately so I don't know the current state in dd-wrt. In my older builds I also enabled debugging for the scan process so any stalls e.g. when hitting corrupte files could be detected.

igloome
igloome's picture
During my tests, the db_dir

During my tests, the db_dir parameter to store the db on disk was correctly taken into consideration. Parameter worked fine. But even if db was stored on USB drive, the router was stalling due to the CPU consumption I suppose.

igloome
igloome's picture
I've just went over some new

I've just went over some new tests with last build (23320), activating jffs. DB is effectively stored into jffs.
My first volume was correctly indexed: files.db is around 700kb at the end of that one. But, while indexing my second volume, the router stalled and, after a 5min of unavailability, indexation restarts from the beginning.
It sounds like minidlna does not like such much indexing large volumes.
I'll try to active debug, to check if it can come from some corrupted files.