Problem with FF on diskstation

[cstern]

I recently upgraded the firmware on my Diskstation DS107e. Then, frequently (actually almost always) the FF server quits with a Disk I/O error.

I would like to ask you Linux experts how to check the disks for errors. I tried e2fsck but it complaints that the file system is in use and that e2fsck should only be used on an unmounted fs. My knowledge of the finer workings of Linux is limited. So, suggestions are welcome.

Here is the mt-daapd.log:

2008-03-03 19:24:45 (00004000): Firefly Version svn-1696: Starting with debuglevel 5
2008-03-03 19:24:45 (00004000): Loaded plugin /opt/share/mt-daapd/plugins/out-daap.so (daap/svn-1696)
2008-03-03 19:24:45 (00004000): Loaded plugin /opt/share/mt-daapd/plugins/rsp.so (rsp/svn-1696)
2008-03-03 19:24:45 (00004000): Loaded plugin /opt/share/mt-daapd/plugins/ssc-script.so (ssc-script/svn-1696)
2008-03-03 19:24:45 (00004000): Plugin loaded: ssc-script/svn-1696
2008-03-03 19:24:45 (00004000): Plugin loaded: rsp/svn-1696
2008-03-03 19:24:45 (00004000): Plugin loaded: daap/svn-1696
2008-03-03 19:24:45 (00004000): Starting rendezvous daemon
2008-03-03 19:24:45 (00004000): Starting signal handler
2008-03-03 19:24:46 (00004000): Initializing database
2008-03-03 19:25:32 (00004000): Query: vacuum
2008-03-03 19:25:32 (00004000): Error: disk I/O error
2008-03-03 19:25:32: Aborting
2008-03-03 19:25:33 (00004000): Rendezvous socket closed (daap server crashed?)
Aborting.
2008-03-03 19:25:33: Aborting
DiskStation>

[cstern]

supplementary data:

/tmp is world read/writable

I have deleted /opt/var/mt-daapd/songs3.db and rebooted. db file is recreated.

65MB free on /dev/hda3 (home of the database (/opt) + all music files (/volume1))
15MB free on /tmp
20MB free on /dev/hda1 (system)

database file is 16MB, sqlite3
music data is roughly 170GB and roughly 40000 songs

Have I reached some limit? db size is roughly 1024 * 1024 * 16 (16352256 bytes)

Or is it the /tmp size that is limiting here? if so, how can I expand this (if possible)?

[cstern]

@cstern wrote:

supplementary data:

Or is it the /tmp size that is limiting here? if so, how can I expand this (if possible)?

All right, just did a quick test: started mt-daapd manually and followed the free diskspace – /tmp is actually filled and then the whole thing breaks down.

[cstern]

A friend has fixed the problem for me. I will post a write-up if someone is interested.

[sonichouse]

@cstern wrote:

A friend has fixed the problem for me. I will post a write-up if someone is interested.

Yes please, always willing to learn more 😉

[Author]

Posts