NASLite Network Attached Storage

The dump that you see on your screen is caused by a buffer overflow. That condition, as I mentioned earlier is rare, and can be caused by many things starting from bad or insufficient ram to driver incompatibility. That includes bad or buggy firmware versions (BIOS, controllers, etc.) as well as bus or IRQs. I’d equate that to a GPF in Windows, however the cause is not another app stepping on our toes, but rather the hardware changing it’s mind on how to apply the rules and not tell us. There is not one thing that can cause that to happen, so there is no “AHA!” that I can offer you.

NASLite can only do its job when the hardware it is operating on allows it to do so. That obviously is not the case, hence the problem you are seeing. If you have moved and replaced everything and anything that you can on that installation, then there is only one common denominator left to consider and that is the board. I understand that it does fine with Windows and Knoppix, but that is irrelevant since your goal is to run NASLite. Drivers, kernel, and everything else NASlite is Linux 2.4.33. That is not the case with Windows or Knoppix.

All that aside, try the other board and see if the crashing persists. Even if you can’t disable the Mbit NIC on it, it should give you an indication if the problem continues to occur. Version 2.04, due out in a week or so will resolve your onboard NIC issue and you’ll be able to use your Gbit NIC.

It is virtually impossible for us to support all possible hardware scenarios equally well. Regardless, considering the compact footprint of NASlite, the range of hardware it supports is substantial by any measure.

I understand your frustration and will try and help with what I can. There are some hardware scenarios that are simply incompatible, so moving away from those also removes the cause and resolves the problem.

Lastly, if anyone else is experiencing this behavior, can you please speak up.

Thank you.



I'll have to think about that.....




I beg to differ.



I disagree. The relevance is that the hardware is running satisfactorily with several rather large suites of software!




Yes, of course.

Are you seriously telling me you exclude the possibility of a malfunction in one of NasLite's modules?

Extraordinary.

So Naslite is mathematically verified for correctness?



But it probably won't, will it? If the result of the problem is buffer overflow, the time required to process the buffers, along with the quantity, will be (possibly considerably) more than the time available at gigabit speeds, so it would simply mask the problem, leading to a false sense of security.




We'll see.



Of course. But it's amazing that you don't even hint at the possibility of a software error!



Do you?

You & your colleague don't have to gather 3 long strings from disparate sources every time you change a small part of your NAS. We do, a lot.

You probably don't have to repair several hd's on a regular basis using alternative software to NL2.

It's like walking on eggs.



& adds to the expense & huge amounts of wasted time.



Now that is a good suggestion.
Please bear in mind that a fellow Customer has similar problems.
It would help if we knew if many others were actually using NFS, & *at gigabit speeds*. I suspect far more use SMB.

Perhaps a thread initiated by yourself would get more attention?

I'm currently doing more tests, but not altering the hardware, & so far there are no *apparent* errors.
Instead I've changed the file service......

However, I need to use NFS, or it's all pointless.

Even though some transfers have gone ahead, they are "sticking" part way through for several seconds.

I'll put in the sata again, & I've a 43 gigabyte file to copy as a test to run overnight.

I guess it's mathematically impossible for you to have bad hardware, but we'll never know since you won't try anything else.

FYI I have alot of boards that are CRAP with windows and work fine with linux,freebsd, do some googling and see for your self, or is that mathematically impossible too?

I've removed the PATA hd, as it's too low in capacity, reinstalled the sata card, plus hd.

I copied a 36 Gig file from the G3 to NL, then tried to copy several hundred smaller files from the mini, but Finder refused because SMB doesn't like their names (hence my need to use NFS).

So, there's a ~ 6 Gig windows partition on the mini, & being windows, no complaints copying all the files from there, about 26000.

As far as Finder's concerned they all copied ok. I'll do some integrity checks tomorrow.

I'm really not sure what "mathematically verified for correctness" means, but, I think that you obviously have an opinion about the situation you are in. I also think that at this point regardless of what I say, odds are you'll take my suggestions as crap. I don't know what your proficiency level is, I don't know what state your hardware is in, nor do I know the environment you are working in. All I'm trying to do is help you narrow down the possible causes.

I know that I can't make everyone happy, but it sure is not going to be from lack of trying.

I have a pretty good idea of how many copies of NASLite-2 are currently in service, so at this point I'll step back and allow the laws of probability to take over and provide some clues as to the mathematical correctness of NASLite.

I can confirm the NFS status doesn't work, this probably happened in one of the last versions, but this would have no impact on nfs performance or functionality since it simply looks at the connection status messages.


As far as NFS, I use it pretty much exclusively here with my Macintosh G4 and Powerbook to mount all our linux servers and my naslite raid, and the linux servers mount the naslite raid for backups etc.

*Sticky* transfers sound like bad cabling or hub/switches, GigE is pretty sensitive to cabling and most people don't upgrade thier wiring when they put in Gig networking.

99% of the support problems with NASLite are due to hardware, which is why we have this forum, it's be impossible to have a KB for trouble shooting the end users hardware setup.

tvjohn, sorry for not replying sooner. My NasLite is currently up for 3 days, but as I said in my first post, this is a pretty random problem.

Tony, any ideas as to why the built-in repair util does not work but the one I am using with a liveCD does?

I am not sure the output of the Naslite when I get the mount disconnect, but next time it will happen I will hook up a monitor and check and will post it here.

Are you referring to the automatic check at boot time or filesystem check via the admin menu?

Both

I can't replicate that on my end. I've practically thrashed the drive in the test machine. Can you describe step by step what you are doing when you try to repair the filesystem using the built-in NASLite facilities only. Aslo, keep an eye for any errors that you may see when the filesystem check is in progress.

When the machine disconnects the NFS mounts, can you still view the status screens via HTTP? If so, are there any errors that you see towards the end of the syslog screen?

Also try to ping NASlite after a disconnect occurs. Does it respond?

I normally try to run the repair from a telnet session. I will try to do all you suggested next time this will occur and I will keep track on any output I get and I will post it here.

Thanks for the help.

OK, just an update. Yesterday my power went out. When the NAS booted up it marked Disk-0 as failed. This time I hooked up a monitor to the NAS and ran the repair util locally. This time around the repair was finished successfully. Only problem was, it took about 24 hours. I think next time I will just stick to the liveCD method, which takes about 10 minutes max to repair the disk.

NASlite-2 performs a complete filesystem scan including physical media (bad sectors). That is why it takes so long. In cases of power-failure especially, that is a necessary practice since the hardware is often unable to properly recover and park the heads. Granted, many dives use disk inertia to do that, there are still many that don’t. Simply doing filesystem verification, although sufficient in most cases, does not ensure the complete integrity of the storage volume.

NASLite-2 will attempt to do all that’s necessary to verify the integrity of your data, regardless of the time necessary to complete the task. If immediate access to your data is important and if you have frequent power outages, then perhaps a battery-backup is in order.

I'm not sure that this is 100% relevant to this thread but it may shed some light on the interoperability of OSX with Naslite2-cdd.

I have bought nas lite 2 and run it on a P4 machine with a raid 5 array (h/w LSI raid card). Now, it works great!

BUT

Performance is variable! At best, with a gigbit network, illogical.

Hardware, netgear 100 and 1000mb(GS608) switches.
Mac - built in gigabit ethernet
Nas - gigabit pci ethernet card(GA311).

Scenario 1
When I connect the mac to the nas via an old netgear 100mb switch, i get the following data transfer results

smb approx 10mb/s upload to nas
nfs approx 5mbs upload to nas (why is this 1/2 the speed???)

Now for me, i need to use nfs as it supports my aperture file names (the length of them). But obviously the performance stinks.

Scenario 2
I swap out the 100mb switch and replace it with the netgear gigabit switch(GS608).

Upload speeds for both nfs and smb to the nas are VERY low ! Read <1mb/s. At times this is only 200-400k/s. This is ALOT SLOWER than the 100mb switch.
(I have the exact figures at home which I'll post later)
BUT

downloading from the nas to the mac.
50mb/s using smb
12mb/s using nfs
24mb/s using ftp.

So my logical conclusion is this.
1) the gigabit network is quick enough to support 50mb/s transfer rates.
2) at 100mb speeds there is some kind of nfs vs smb problem which needs resolving?
3) at 1000mb speeds there is a SERIOUS problem! u/l vs d/l speeds.....
4) I should be getting 10mb/s for smb AND nfs using the 100mb switch
5) On the gigabit switch I should be getting nearer 50mb/s for nfs and smb downloading, BUT there is a serious issue uploading.
6) If the Nas can download at 50mb/s, why can't it upload anywhere near the same rate? The disk array in the Nas is far quicker than the disk in the mac, which points me to a software/interface problem?

Now, what can be done??? Is this a NASlite issue, a Mac issue, or both.

Does anyone have any suggestions/solutions or is this something for the Nas admins to look into?

rsvr_mille, how did you measure the transfer performance?
I was also under the impression that NFS should perform better than SMB.