AFAIKS loadSnapshots() adds all snapshots in $snap_container (which indirectly points to sda9/snaps/ in alphabetically order, which is also numerical order, to the unionfs, and the last added is the only RW layer. So when you had a /snaps/04, it should not have been possible that a logfile in /snaps/02 was growing, unless the directory was added after the last boot.
I suppose you don't have timestamps of the /snaps/XX directories anymore?
Alas, no. And now that the panic caused by my initially unresponsive drive is over, I'm kicking myself that I didn't make better use of the opportunity.
The timestamp of the log file is Wed 09 Jun 2010 10:09:04 PM CEST (see screenshot in my earlier post). The first entry in that log file is from Sun, 06 Jun 2010 12:38:28 GMT; the last date in that file is Mon, 07 Jun 2010 06:43:19 GMT. So i don't think it was still growing yesterday.
As I understand the problem, it's rather that by 9 June, the then active log file had grown so large it was keeping my NetworkSpace from functioning properly. What I should have done is go into the TwonkyMedia config pages and clear the log. What I did instead is perhaps the stupidest thing I could have done, and that is trying to fix the issue by reinstalling the firmware, thereby locking away the monster log file in the snaps/02/ folder, beyond my control.
After that, clearing the new active log file in Twonky temporarily resolved 'disk full' errors, but only made a small difference.
Since June 9th, my NetworkSpace has gone through all sorts of weird and wonderful stages (with varying degrees of FTP access) as I tried rebooting, factory resets, firmware upgrades, you name it. So I suppose the snaps 03 and 04 were created between June 10 and 20th.