Snap OS 3.4.805, anyone?

[Phoenix32]

ADMIN

A great deal of the content of this message thread recently has drifted a long ways from the topic of the thread (it has become a SNAP 4000 problem, test, and measurement topic). This may cause problems for those using the thread for what it was initiated for as well as cause others to miss the new 4000 topic. I would suggest/request that the later portions of this message thread concerning the SNAP 4000 stuff be split out to a seperate topic thread with an appropriate title. My appologies for my participation in the hijacking of the topic.

[DC4]

Originally Posted by radio

I'm posting this here because it seems it's where everyone is looking.

I have successfully built a raid 5 with 4 320Gb disks, but it will not rebuild after an error (power outage) detailed description here: http://forums.procooling.com/vbb/showthread.php?t=13488

My best guess is that I need more that 64Gb because of the large disk size. Can anyone offer more than a hunch? Is there any data/evidence available on this? Does anyone have any experience with this error message:

File System Check : FSCK fatal error = 8 Disk 60000 RAID 5 9/17/2006 2:00:45 AM
File System Check : Failed to allocate 10930276 bytes for update bitmap!!! Disk 60000

I seem to recall reading on this forum that running a 4.x OS would require more RAM (256mb preferred, might get by with 128mb). It looks like this is evidence that this is in fact the case, since allocating memory would require space in RAM (snap servers don't have virtual memory allocation, etc.).

I am curious if it is failsafe enough to stick in a 128MB SDRAM and see if it corrects it up still. I have like ten 128mb SIMMs in older machines (but not one 256mb!).

[radio]

Originally Posted by Phoenix32

LOL, I am glad to see someone challenged it. Shows someone is thinking...

It's base 2. You use base 2 round numbers every time. (2 4 8 16 32, etc.) There is no reason to roundoff to the nearest base 10 number until the final number (for human convienence)

[radio]

Originally Posted by Phoenix32

To be honest, I am not sure... What you are seeing is the $10,000.00 question it seems and why I have asked DC4 to do that testing. Here is about all I can add, and it is guesses, speculations, and shots in the dark (so take it that way please).

Thanks Phoenix2^5. I'll be looking for more memory to test this out. I'm going in tonight to open it up and see what's in there. I'll take along what I have in the hopes that there are two memory slots - maybe I have 64m around here somewhere. there were conflicting reports of memory types, so I'll just have to look. I'll report as usual.

This was all done on the latest 4 OS, so that's not it.

I just think people running large RAID5s should be aware of this.

I would certainly hope that the it would rebuild after a power outage. There is no use having a RAID if it's that sensitive.

[radio]

Originally Posted by DC4

I seem to recall reading on this forum that running a 4.x OS would require more RAM (256mb preferred, might get by with 128mb). It looks like this is evidence that this is in fact the case, since allocating memory would require space in RAM (snap servers don't have virtual memory allocation, etc.).

I am curious if it is failsafe enough to stick in a 128MB SDRAM and see if it corrects it up still. I have like ten 128mb SIMMs in older machines (but not one 256mb!).

If OS4 is a larger memory hog, and later versions of everything tend to be, then it would suppory the cramped memory theory. - I'll report back.

iodar

[Phoenix32]

Originally Posted by radio

I'll take along what I have in the hopes that there are two memory slots - maybe I have 64m around here somewhere. there were conflicting reports of memory types, so I'll just have to look.

The 4000 uses a single slot (sorry) of standard SDRAM, up to 256MB. It is the 1000/1100/2000/2200 that can get confusing as to which ones use what among the models and revisions. To the best of my knowlege, ALL 4100 and 4000 units have a single slot for standard SDRAM. While it may be possible with the right stick of memory, I do not know anyone who has made a 512MB stick work. The limit seems to be a single 256MB stick...

Oh yeah, and OS v4.x.x does use a significantly larger amount of memory over the previous versions.

[radio]

#1 I agree with Phonex00100000 about splitting off this thread. I only referenced my other post here because it seems like this is where people are hanging out. It really needs to be broken up (perhaps locked too for a time)
--------

ok

Within 2 minutes, I hopped on ebay and grabbed this for about $15
I think this will do, but I'll let you know.

CRUCIAL PC133 256MB 16 Chips CL3 Low Density SDRAM

Model CT32M64S4D75
Module Details:
Part Number: CT32M64S4D75
Module Size: 256MB
Package: 168-pin DIMM
Feature: SDRAM, PC133
Configuration: 32Meg x 64
DIMM Type:
Error Checking: Non-parity
Speed: 133MHz
Voltage: 3.3V
Memory Timings: CL=3
Specs: SDRAM, PC133 • CL=3 • Unbuffered • Non-parity • 133MHz • 3.3V • 32Meg x 64

iodar

[Phoenix32]

Should work by the looks of it...

[radio]

Well, I just couldn't wait, so I canabalized another computer and foud a 256M DIMM.

Funny thing was, the high profile, single sided stick that was in the snap was a 128! (only saw 64 though). Someone must have tried to upgrade it and failed... but I digress

FSCK went ok, and it fixed a few things. It took a little over an hour. It's rebuilding the backup disk now (3%).

So add this to the knowledge base:

4000 series
OS: 4.0.860
HW 2.0.1
BIOS 2.0.282

Needs more than 64M to rebuild. 256M works. The error was:

File System Check : FSCK fatal error = 8
File System Check : Failed to allocate 10930276 bytes for update bitmap!!!

I don't know if I should be doing this, but while it's rebuilding, I started copying the rest of the 200Gb to it.

oidar

[Phoenix32]

Give us an idea of how much data is on there and how long it takes to rebuild the array...

[Phoenix32]

Did we lose radio and DC4 here?

[radio]

Originally Posted by Phoenix32

Give us an idea of how much data is on there and how long it takes to rebuild the array...

It took about 2 days to rebuild, but that's an unfair assesment because I was copying 300GB to is at the same time. I may break it again and test the rebuilding, but not until after I copy another 250GB. Then again, I might not bother. This is a production machine, and not really a playground.

oidar

[Phoenix32]

Originally Posted by radio

It took about 2 days to rebuild, but that's an unfair assesment because I was copying 300GB to is at the same time. I may break it again and test the rebuilding, but not until after I copy another 250GB. Then again, I might not bother. This is a production machine, and not really a playground.

oidar

But even then, 2 days? Holy crap!

I understand your point "production machine, and not really a playground", but think on this a second. As a production machine, does this not lend even more importance to verifying that it will do what it is supposed to do after a failure, especialy in the light that there is doubts about it? Do you want to find out after something fails and there may be important data on the unit? Just a thought.

For the record, there is some serios doubt from blue68f100 and myself that the 300 or 320 GB drives work properly in a 4000 in RAID 5. They may format, they may build the array, but there is some serious speculation that the 4000 has some OS limit for the array and may not be capable of properly restoring the array. Part of that serious doubt is coming from the amount of time to build or rebuild the arrays. A 20% to 25% increase in HD size with a 300% to 500% increase in build or rebuild time does not add up. That is part of what we are trying to determine here.

[radio]

I was copying files for 2 days. I don't think its a big deal that it took twice as long to rebuild under usage like that. I know exactly what will be on the RAID, so I know exactly what I have at stake.

Certainly I would want it to rebuild, but I could use your arguement for every extra GB I put on it. What you really want me to do is max the thing out and then unplug one drive. - I could do that I suppose, but I have other constraints to work under. I have seen the thing rebuild after a real, not simulated problem. It performed well.

there is some serios doubt from blue68f100 and myself that the 300 or 320 GB drives work properly in a 4000 in RAID 5.

I don't want to pick a fight or come across wrong, and that's easy to do in text even with these, but how serious is it really? Is there any reason to believe that it might not rebuild? Has it happened before? I can't take seriously the claim that it takes a long time therefore something (undefined) is wrong. If there is a real reason to believe this, then lets hear it.

there is some serious speculation that the 4000 has some OS limit for the array and may not be capable of properly restoring the array.

Ok, lets hear it, what is the limit and how was that number determined? Since my data could depend on this I am very interested.

[blue68f100]

The 300gig 7200.9 drives would fail every time when tring to build a RAID 5. The 7200.9 have 1 more plattere than the 7200.10 do (3 vs 2). Difference has to be in the LBA table sector/heads/platters. Every time someone attempts to install drives with the total cap > 1T, all sorts of strange problems pop up. You being the 1st with the DOT 10's, extended time to build the array originally, and resync time....

It's should not take 48hr to format a raid 5 when a 4x250 only takes 5-6 hrs. I under stand the resyn time taking longer while the unit is still in use. The extra ram should help that part.

[Phoenix32]

Okay, but you asked...


For starters, we are back to the time to build or rebuild a RAID 5 array. With 250 GB drives, it takes 5 or so hours. With the 320 GB drives, it takes 24 hours (without doing any copying or use). This is an indicator something "strange" is going on. It just doesn't add up. Does this mean the the SNAP is having a difficult time with the build/rebuild? If so, what kind of difficulty? Is it actually working, or does it just "look like" it is working properly? Nothing for sure here, just an indicator.

Next, We KNOW FOR SURE there is an OS limit of somewhere between 1TB and 1.2TB. How? Because people who have used drives of this size and larger have gotten weird errors and error messages like "proposterous sector count" or something like that. We also know that the OS the SNAP OS is based on has these limits. Where exacly is the limit? Don't know for sure, but it is right in that ballpark. Now let's see, 320 x 4 = 1280. Hmmmm, interesting. Now with the 7200.10 drives there may be a slight difference in the sector counts and be just under the wire, or maybe it just "seems" to be under the wire. However, there was at least one guy using Seagate 320 GB drives who could not get it to work at all (I think they were 7200.9 drives if I remember right).

Next, several people have tried 320 and larger drives before and it either did not work, or it seemed to work until they tried to do a rebuild and it went to crap. Was the problem somethign else? Maybe. But still...

Does the OS from 3.4.805 to 3.4.807 or to 4.0.860 make a difference? Does the revision of the board in the 4000 make a difference? How much memory is required? Does the Seagate 7200.10 make a difference? Were these other people having other issues with their SNAPs? These are all unknowns, but as you see, there is enough to at least say there "might be" an issue and to be suspicious.

In my opinion, I suspect with Seagate 7200.10 drives, enough memory (at least 128 MB), OS 3.4.805 or above, and the drives formated initially with the same OS, then the 320 GB drives will work fine in a 4000. But this is just an opinion. That's what we are trying to find out. You and DC4 both have 4000s, one of you using 3.4.807 and the other using 4.0.860 (I think that was what you said you were using), both have at least 128 MB of RAM, and both using the Seagate 320 GB 7200.10 drives. If you both can build the arrays with plenty of data and FOR SURE be able to break it and have it rebuild, then that will tell us something. If one of you can and the other can't, then we have a place to start to see what the difference might be.

Hey, you asked...

[radio]

Ok, I have to admit I don't know much about LBA 'tables' - sector/heads/platters,
but with enough memory, I don't see why the OS should treat the drives any differently than any other OS with LBA support. Granted there is a lot we don't know about how the RAID5 works in the SnapOS, but again, it worked before and I don't think it would take any extra time to rebuild a full disk. I would have thought differently, but since it took almost 24 hours to rebuild an empty disk, I don't think it is data dependent. make sense?

[Hallis]

Originally Posted by radio

Ok, I have to admit I don't know much about LBA 'tables' - sector/heads/platters,
but with enough memory, I don't see why the OS should treat the drives any differently than any other OS with LBA support. Granted there is a lot we don't know about how the RAID5 works in the SnapOS, but again, it worked before and I don't think it would take any extra time to rebuild a full disk. I would have thought differently, but since it took almost 24 hours to rebuild an empty disk, I don't think it is data dependent. make sense?

What you're saying is it should take no longer to rebuild the raid then it would take to transfer a similar ammount of data to an empty hard drive under normal circumstances? Logically that's the way i see it too lol but tha magic RAID5 gnomes have to do many many more things apparently.

Shane

[blue68f100]

First, Unix does not use/require the bios table to read the drive parameters. Most all unix system read the drives directly. The FreeBSD kernel in 1998 the max cap was 8 gig, or some where around there. Now this is a Software raid. Meaning that parity bit and augth.. is all done by the cpu controlled by software variable or registers. V4 may make a difference over v3.4.807 but I dought it. It may be more to do with the motherboard revisions, Hardware changes.

If I had 4 300gig I could test with FreeBSD v6.1 and FreeNAS. But I only have 2 120's for spares.

That my 2 cents .........

ps. The user that had all the problem with (Seagate 7200.9) 4 x 300gig ended up configuring his unit as a 3 disk array with 1 hot spare.

[Phoenix32]

The operative word here was "should". But what should work and was does work, at least with the SNAPs and RAID 5, can often be different.

NVM, I surrender, but it would have been nice to KNOW instead of speculate.

[cianwill]

That is what my configuration is - 4 Seagate 400GB's in 3 disk array with 1 spare. I never could get it to build with 4 disks.

[radio]

Originally Posted by cianwill

That is what my configuration is - 4 Seagate 400GB's in 3 disk array with 1 spare. I never could get it to build with 4 disks.

Ok, well that's for 400gb drives. What else is different? What OS/BIOS/Hardware versions are you running?
You couldn't get yours to build, which is a different problem altogether.

Perhaps it's the older BIOS that has has the Tb limit? Or maybe they are the same. Maybe we should just call an engineer from the old SNAP before the company soldout.



Here is what I have:

4000 series
OS: 4.0.860
HW 2.0.1
BIOS 2.0.282

[blue68f100]

Looking at the wiki sections where upgrades are posted, It has the latest BIOS. Some had a hw 2.0.2 and 2.0.3, so yours may be one of the earlier 4000 but out. I am aware of 4 different Hardware versions. Users is a v2.

[radio]

An interesting update on the 4000 and four 320GB in a RAID5 here: http://forums.procooling.com/vbb/showthread.php?t=13488

[cianwill]

4000 series
OS:4.0.860 (US)
HW: 2.0.1
BIOS 2.0.252

However, mine now has 256MB of RAM (pc100) which I did not have when I tried to build my array.