DSM-G600, DNS-3xx and NSA-220 Hack Forum

"Smart not supported by Firmware" was also my impression.

However, if the SATA drives do not go through a SATA-USB brdige, there is a chance to compile smartmontools for the DNS-323 and to read the SMART values.
Leaving a NAS without the possibility of reading the SMART values is a bit "un-clever" if I may say so...

Has any body tried to compile the smartmontools for the DNS-323? Unfortunatley I have never done any cross-compiling, i.e. it would be my first try...

marinalink

Thanks, this sounds good. I have never used ipkg or optware, do you have a tutorial on that?

Do you build the packages your own on the target it self or on a normal PC or are these packages already precompiled?

Thanks!
marinalink

OK, thanks for the info! Now waiting for the delivery of the DNS-323.

marinalink

fonz - hope you won't mind assisting here.

I'm guessing that ffp0.5 refers to fonz fun_plug 0.5

I've running my own very minimal fun_plug and really don't need the other stuff that I see people going after secure ftp, better web servers and so on, but I would like to have smartmontools - so - is this something that can be easily added, for example, like the usb storage support, just download a few modules and edit my fun_plug script or should I just bite the bullet and go with it all?

fordem wrote:

I've running my own very minimal fun_plug and really don't need the other stuff that I see people going after secure ftp, better web servers and so on, but I would like to have smartmontools - so - is this something that can be easily added, for example, like the usb storage support, just download a few modules and edit my fun_plug script or should I just bite the bullet and go with it all?

smartmontools is a little more expensive than the usb modules. The two programs in the package (smartctl and smartd) require the C++ library libstdc++ that, afaik, is not present in the firmware.

Exploding ipks and picking the files you need is definitely an option if you want to keep your addons minimal wrt nr of files and disk space. Using ipks has the advantage that they are compiled using the same (or close enough) compiler version and linked against /lib/, while my packages need their own set of libraries.

A minimal version of my 0.5 package would amount to 720k for (a full-featured) busybox, 532k for the C library, 936k for libstdc++ , 44k for libgcc_s, 412k for smartmon programs - less than 3MB total for a self-contained funplug.

Out of curiosity, what functions did you add?

fonz

All I'm running at this point is telnet, so that I can do scripted shutdowns, although I'm considering "re-adding" the usb storage modules to allow back up to an external USB device (I had those in last year, just to see if I could do it) - my concern is not so much the number of files and disk space (for me that's a matter of throwing a larger disk in there) but more the limited RAM and CPU

My original reason for buying the DNS-323 more than a year ago, was to introduce it to a number of small business clients who needed reliable redundant storage, but weren't up to administering a true server - at that time the unit wasn't mature enough - but with the development that's gone on here, I think I could take it forward.

Firmware 1.04 has improved disk error/failure detecton, smartmontools is of course a step in the right direction, and the ability to add an external USB device for backup - I don't think I need much more for a SOHO NAS - some folks might look for more in terms of security, but I would not hesitate to run these wide open, at least where I need to run them.

sjmac wrote:

unzips to 5.8MB on disk, so I suppose running an ffp 0.5 environment on top of the DLink firmware could take around 5.8 MB of extra space vs running the same apps linked against the DLink libs.

Fonz - Is this a bad guess?

Yes, a really bad guess that includes headers file, static objects, utility programs, etc. It's more like 0.5MB.

sjmac wrote:

the ffp/lib folder contains 2.8 MB of shared and static libs.

The ffp libc is 1MB all by itself, and is only available as a static lib (.a), but in the firmware it's shared (.so).

How do you work out a 0.5 MB overhead?

The static lib is not relevant, it's only used for static binaries and then, only required parts of it are linked into the executable (remember, the 0.5 funplug includes a complete toolchain).

Of course, it contains a shared libc, just like the firmware: libuClibc-0.9.29.so

0.5MB is the sum of _all_ shared objects in uclibc:

ffp/lib$ du -cks $(find -type f -name \*.so)
16      ./libcrypt-0.9.29.so
12      ./libdl-0.9.29.so
76      ./libm-0.9.29.so
8       ./libnsl-0.9.29.so
68      ./libpthread-0.9.29.so
8       ./libresolv-0.9.29.so
8       ./librt-0.9.29.so
300     ./libuClibc-0.9.29.so
8       ./libutil-0.9.29.so
24      ./ld-uClibc-0.9.29.so
4       ./libc.so
532     total

Also remember, that these are shared objects, i.e. loaded once, even if used by a dozen programs.