I still have very little time to work on the NAS200 firmware. Lately I've worked on Jungle Disk Server Edition and it seems to work okay but sometimes my NAS200 just completely stops responding, or the OOM killer kicks JD Server Edition out. Apparently after 5 days of continuously backing up almost 100GB of data without a hitch, it now has to perform some task that takes up so much memory that 32MB plus swap space simply isn't enough. It occurred to me that an important reason for JD Server Edition to bomb is that it has to load all these libraries because it's not compatible with what's in the ROM. Basically because it's the only app that uses the different libraries, it might as well be linked statically. If only it would be possible to put these libraries in /lib so that they could be shared between all apps. Besides replacing the ancient libraries in the source tree by newer ones (which is so much work I don't even want to think about it), there's another solution: I could make it possible to do union mounts: overlaying part of the hard disk on top of the ROM file system. It's actually very easy to patch the kernel with the diff files available here, and configure UnionFS support, but UnionFS is clearly not the only solution and it appears to have a few weak points that has prevented it from being integrated in the mainline kernel. The advantages of adding UnionFS are: It will be easy to overlay a directory tree on the hard disk on top of the ROM tree. Installing updated applications such as Twonky and Busybox will be trivial: just copy them to the directory. Many of my changes will become unnecessary; for example instead of my added code that looks for scripts in rc.d in the root directory of each hard disk, you can modify the existing scripts in /etc/rc.d yourself. If you can install updated libraries in /lib, they will be used by all programs. This can potentially save a bunch of memory space because the library only has to be in memory once. It would be possible to overlap directories that are normally in RAM (/etc, /var...) with disk-based directories so they don't use up memory space either. The disadvantages are: UnionFS is not very efficient: for each operation, it has to walk a tree of file systems; I expect that this would make the NAS200 even slower than it already is. I think this even happens if UnionFS is compiled as a module and is not loaded. Depending on the number of allowed overlays (which is determined at compile time), the amount of RAM that's used by the kernel is increased. I intend to reduce the number of allowed overlays from 128 to e.g. 4. It will be very easy to make your NAS200 stop working by overlaying the wrong files, "deleting" important system files etc. It will take some effort to implement this in a robust way so that it will be easy to "back out" of any overlaying mishaps without the need for e.g. the serial terminal. I need some ideas on how to do this. While UnionFS seems to be the most mature solution to do this, I'm not sure if it's the best way. What do you guys think? Answer the poll and put some comments in the thread.