Joe L.

That section of the page is labeled "Drive Partitions", yes, once pre-cleared, the disk has the first partition defined. (It is not yet formatted though) What you are seeing are the disk itself and the device for the first partition. It is not an error, nor a "dupe" You are seeing /dev/sdl (the raw disk) and /dev/sdl1 (the first partition)

This topic has been moved to Lounge. [iurl]http://lime-technology.com/forum/index.php?topic=27525.0[/iurl]

I think the issues is more related to power than the data cables. According to this line in the SMART report, the disk heads have been retracted in response to power loss 93 times. That suggests either a lose power connection, or a bad power splitter, or an overloaded power supply, or a bad drive tray. (although it could also be the disk itself I suppose) 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 93 Joe L.,

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=27521.0[/iurl]

It will... once I finish adding that to the existing logic. I think that can be arranged. The unMENU screen already does that, although with slight differences in its coloring/timing. If > 90 days, the number has a [glow=red,2,300]RED[/glow] background if > 60 days and <= 90 days, the number has a [glow=yellow,2,300]yellow[/glow] background if > 30 days and <= 60 days, the number is bold. If < 30 days, the number is in normal font. Joe L.

Neither did I. It should initiate a check on its own. Might make a suggestion for an enhancement for it to do just that. Ah, but a check is necessary. Otherwise the first time you might find an unreadable sector is when you are dealing with a disk failure and trying to read parity. Joe L.

There have been plenty of times where a disk cannot be read after it is written. It is only then (when being read) that un-readable sectors can be identified by the SMART firmware. (A sector is considered un-readable if the checksum at the end of a sector does not match the contents of the sector.) Yes, In my opinion, a parity check is very necessary after an initial parity calc. Joe L.

This topic has been moved to General Support. [iurl]http://lime-technology.com/forum/index.php?topic=27509.0[/iurl]

You are confusing parity "sync" with parity "check" You've NEVER performed a parity check. (not with that parity drive) You've only written parity to the parity drive. (parity sync) You've never verified it can be read back and validated it against the data disks. 0nce you do, the date will show correctly. The date of the last "check" is stored as the number of seconds since the UNIX epoch, Jan 1, 1970. The last-parity-check-value you have on your system is "0" (1/1/1970) Apparently, that is 43.41 years ago. You now need to perform a parity check. Otherwise you have no idea if the parity disk was written to properly. Joe L.

DISK_DSBL_NP = Disk Disabled - Not Present. Either the disk itself has failed, or a power/data cable to it is loose or disconnected, or the drive tray it is in is loose/poorly seated, or the disk controller port it is connected to has failed.

Depends on the size of your drives ... but basically a bit longer than a parity check, so typically several hours (e.g. my system uses 3TB drives, and a parity check takes ~ 8hrs ... the initial calculation took a bit longer than that -- I don't recall just how much longer; but probably ~ 10 hrs). Another issue... 199 UDMA_CRC_Error_Count 0x0032 200 181 000 Old_age Always - 2239 UDMA CRC errors are usually caused by noise pickup on the SATA cable to the disk. That is usually caused by either a poorly shielded SATA cable OR one that has been neatly bundled parallel and close to other SATA cables using tie-wraps, etc. This is even worse if it has been bundled with power cables. To fix, cut the tie-wraps on the SATA cables. Then, put some distance between the cables. (or replace them with shielded versions) Do not let them all run tightly parallel to each other. Being OCD neat is the WRONG way to cable a multi-disk-server. The sectrs pending re-allcation is a separate issue. Your disk may need replacement regardless. 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 440 As mentioned, un-assign the parity disk, START THE SERVER WITH IT UN_ASSIGNED, the stop the server and re-assign it. It will be completely re-written. After it is re-written, perform a parity check to see if it csn be read back properly. then get another SMART report. There should be NO sectors pending re-allocation.

If the on-screen prompts talk about clearing newly added drives DO NOT START THE ARRAY. You must set a new disk configuration instead. (Utils->New-Configuration) That will immediately invalidate parity, but will accept all the currently assigned, formatted and present drives as they are. I think if you are running the most recent 5.0rc12a you can even check a box that indicates parity is to be trusted, and the invalidation I mentioned above would not occur. Joe L.

Or, you booted up with the two disks not-responding, so unRAID has forgotten their respective model/serial numbers, and then re-seated the power connection, and now unRAID sees them (as new drives to it) and wants to treat them as new disks. Be very careful, as unRAID could want to clear them if you start it at this point. You might, as mentioned earlier in this thread, set a new disk configuration now that they are seen once more and re-calculate parity based on them being present. Joe L.

OOps... my example in that other post had "stopping_services" but the correct event name is "stopping_svcs" I'll bet that name would work properly. (I fixed the other post I had linked to, so hopefully it will be a better example for others) Glad it is working for you. Joe L.

unformatted simply indicates the drive could not be mounted. DO NOT format the disk. It would erase any files on it. You must fix the file system corruption... but first, verify memory is correctly configured. The segfault is NOT normal... it is one clue that memory might be an issue. Joe L.

Or, as reiserfsck suggested as a possibility, you might have a problem with your RAM. Have you performed a memory test? Is the clock speed, timing, and voltage set correctly for your specific memory strips ? (Some BIOS do it correctly, some do not, some just get it wrong) Unless memory is correct, you'll have all kinds of issues. Joe L.

What version of unRAID are you using? If the 5.0-rc series, then unRAID DOES have event hooks to start processes AFTER the array is online, and to kill them BEFORE the array is stopped. See here on how you might use them: http://lime-technology.com/forum/index.php?topic=26201.msg228957;topicseen#msg228957 In the 4.6/4.7 series you can use a unraid_addon_control.sh script similar to the one I described (and attached) in this post: http://lime-technology.com/forum/index.php?topic=5686.msg53271#msg53271 I've been using unraid_addon_control.sh for a number of years now and it works perfectly. (It would work on the 5.X series too, but the built in events are easier for plugin users to utilize.) I use it to start a number of add-ons after the array is started, and to properly stop them prior to the array when the array is being stopped. Here is an example of somebody using the unraid_addon_control.sh script: http://lime-technology.com/forum/index.php?topic=10978.msg199652#msg199652 Joe L.

And that is EXACTLY why he requested you check the file-systems for corruption as described in the wiki. The shared file-system should be able to handle any values returned from the underlying reiserfs file-system, but who knows what it returns if corrupted. If you check the file-systems, and they are sane, then the fault IS in the unRAID shared-file-system code.

Actually, if you just pre-cleared the drive and just assigned it, those lines are entirely expected and normal. You cannot "mount" a file-system that has not yet been created, and you've not yet formatted the disk to create the file-system.. Right now, I am guessing that the array can be started, but that the new drive will display as unformatted. There should also be a "Format" button present (with a checkbox under it to enable it) Check the box, press the "Format" button (assuming the new drive is the ONLY drive showing as unformatted) and a few minutes later, the new drive should be formatted, mounted, and be available for use for data. Joe L.

There is an exception to that though... It will benefit (just a little) IF multiple slower-rotating data drives are being written to at the same time. Otherwise, writing speed to the array is limited by the slowest rotating drive involved.

You should NEVER reformat the flash drive. You are thinking with a Microsoft mindset. unRAID re-loads itself every time you reboot. There is almost never a need to re-format. (I've had a unRAID server for about 8 years, have gone through (seemingly) hundreds of releases, and have never had to reformat the flash drive.) There are two different issues, one with networking and domain name resolution., the other with windows shared drives. The first is resolved by your router and/or hosts file. The second by the election of a "master browser" on your LAN by all the PCs and devices connected to it. It can usually be resolved by setting the "Local Master" = "yes" under the "Settings->SMB" settings. Joe L.

I've never seen Tom mention it in any way.

Actually, unRAID itself runs fine on 512 Meg of RAM. Joe L.

You don't need those last two lines in the "go" script. In fact, they conflict with the static IP address you were trying to use.

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=27471.0[/iurl]