1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How about this...

Discussion in 'Cisco/Linksys Network Storage Devices' started by jac_goudsmit, Nov 24, 2009.

?

What would you think of adding UnionFS to JacX?

  1. Yes, that would be awesome!

    1 vote(s)
    33.3%
  2. Yes, but use something else than UnionFS. (Let me know what and why!)

    0 vote(s)
    0.0%
  3. Yes, how can I help?

    0 vote(s)
    0.0%
  4. No, you should be working on OpenWRT instead!

    1 vote(s)
    33.3%
  5. No, I like it the way it is!

    1 vote(s)
    33.3%
  1. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    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.
     
  2. Treah

    Treah Addicted to LI Member

    Will the system not share files even if you add them to the library search path?
     
  3. mstombs

    mstombs Network Guru Member

  4. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    If the library search path has the right paths, the Dynamic Loader will search them. However, at this time, the LD_LIBRARY_PATH variable is not set anywhere. That means the default search path is used. That means all applications that are started from the Linksys startup script already cause the old libraries to be loaded. Any apps that want to use newer libraries will load those, resulting in two different versions of the same library taking up memory space.

    The main problem that I had with JD Server Edition was that the Dynamic Loader (ld-linux.so.2) that's on-board doesn't support Thread-Local Storage which (as far as I can tell) makes it impossible to start many programs without using the same method as I used with JD Server: instead of running the app from the command line, run ld-linux.so.2 from the command line with the executable file as parameter. In this case: ./ld-linux.so.2 --library-path . ./junglediskserver .

    I see your point though, and it's a good idea: I could export LD_LIBRARY_PATH at an early point in the startup and set it to include a directory that is mounted on the hard disk... Interesting...

    ===Jac
     
  5. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

  6. Treah

    Treah Addicted to LI Member

    Checkout the /etc/ld.so.conf file this should tell the dynamic loader where the library files are to link. You could just either modify it when you build the system so that it searches a disk directory first or prepend it at each boot. I think the latter would be more difficult tho and I am unsure how you change that very early in the boot process.
     

Share This Page