NASLite Network Attached Storage

I've read many posts on this forum concerning the problem of not being able to save files to the NASlite+ server whose size is over 4GB. I've read that there is a problem in the version of SMB/CIFS loaded with NASlite+ that causes the 4GB limit.

I've also read posts from Tony that state all NASlite OS's are derived from the same binaries and that the new SMB daemons won't fit on the floppy version of NASlite. These statements might not be from the same posts and I did take the liberty to paraphrase.

My confusion is this: Shouldn't the NASlite+ version that people pay for contain code that works? I understand that you can't fit the new code on the FREE floppies. Oh well! If you want updated code, spring for it.

Am I missing something here about why the CD versions of both NASlite+ products can't be updated to provide the SMB fix. Is is a compatability issue with the FREE floppies? If that's true, it appears to be a case where the people who pay for the product are penalized in favor of the people that get it for free.

If it's not true, then can somebody from Server Elements clear this up for me in a concise statement that makes sense and explains why the version of NASlite+ that I paid for has a glaring discrepancy for which a fix exists? I would really appreciate that.

sanmaster,

The primary goal of NASLite is to operate at maximum efficiency on as much older hardware as possible. That means that it has to operate well on a P66 with 32M RAM just as it would on a 3GHz P4 with the works. The primary goal however was to take obsolete hardware and make it useful again - doing so in a way that will allow anyone to install, run and administer it without much prerequisite knowledge. As I’ve said before, I think we’ve done that.

In order to achieve the above, there are a number of things one has to take into consideration. NASLite v1.x runs with a 4M RAMDisk root. That is pretty tight, but necessary if you are trying to run in 32M ram. Every binary in that 4M root is selected for a reason. For example, smbd from the 3.0 branch of SAMBA is approximately 3M alone. Then there is nmbd, at another 1.5M, etc. (I assume that’s what you are referring to when you say “SMB fix”). All that is fine, except that the root just grew to 8 or 16M. In addition, NASLite can no longer boot from a 2.88M bin since the root is too big. In order to accommodate the large root, the kernel has to mount the CD after it boots. Well, that’s fine except a number of older systems use non-ATAPI drives that are bootable by the BIOS but require additional drivers for the kernel to access them. Same goes for booting from USB, Firewire and SCSI CD-ROM drives. The process continues, the kernel grows, the root grows, system requirements grow, NASLite is slowly becoming less and less light.

I hope the above makes sense. It really isn’t that simple, but I do understand your frustration.

As far as that “glaring discrepancy”, I’m not sure I agree with you. Selecting the tightest smbd/nmbd set capable of accommodating 95% of potential users is what made it possible to eliminate an entire array of hardware dependencies. It really is difficult to put everything in 2.88M bin and 4M live root. NASLite isn’t perfect, but it’s pretty good at what it does.

Tony,

I appreciate the prompt and verbose response to my question regarding the 4GB file size limit. I understand the original intent of NASlite and I agree that you have accomplished your goal. Having a piece of software accommodate 95% of the existing hardware base is an excellent feat and your right to be proud of that accomplishment.

I agree with your comment that NASlite appears to be getting less and less lite. Maybe it's time for another product that has all of the good things NASlite has plus things like the fix for the 4GB file size limitation as well as a print server.

I think your product is excellent. If I didn't, I would not have purchased it. I'm hoping that version 2.X has some of the features I mentioned above and I look forward to it's release.