Hi Gang/Tom:

 

Have never had a problem (well nearly never - good syntax ) but had to re-boot the Server earlier in the week (lost my Network Router ).  Regardless, I have a 500GB Parity Drive and a 'new' 500GB drive 6 (hdg) running PATA in my Server.  On re-boot, I have a Red Light on the 6th drive (1st drive on Promise card 1).  Previously no problem either seeing/formatting/using (minimal files at this point).  Same type Seagate but different series lot # (reports size identical).  When it first came up after re-boot, was showing some errors (1st I've ever seen) so rebooted again, no errors but still not "mounted" in Array.

 

Suggestions please.

 

Also Tom, I tried to download/update one of my Keys' to 4.0 (earlier attempt) w/o success, would not read new "flash".  Has this been rectified with later versions.  Since I have 2 keys (Pro) I just reverted until it seemed necessary to update, but with this problem, it might be opportune.

 

Thoughts

 

Thanks

 

Dave - Archivist 

Could you provide a little more detail, on both issues?  I was unable to fully understand either situation.  All I can offer for now, is that the drive type or series lot should not matter, and that I'm unaware of any reason that an unRAID version should matter in 'reading' a flash drive.

 

A few questions may help you understand my confusion.  I don't know what you mean by 'would not read new "flash"'.  Does 'read' mean: cannot see flash from another machine? cannot see flash from console?  can see within Linux, but cannot read or write?  cannot copy bzroot and bzimage to it?  can see flash but cannot boot from it?  has read errors (under what conditions and what error messages)?

 

Is 'drive 6' the same as '6th drive'?  Is the 'new' drive the one with errors?  What does the syslog say about the drive (what kind of errors)?  Is 'Red light' the 'In Use' LED on the drive, or the red status ball on the web Main page?

 

Errors that show up immediately, after reboot, are clearly serious, and probably faulty hardware I would think.  Need to see the relevant parts of the syslog.

 

Also, was the "new" 500G drive 6 ever part of your array?  Was it cleared and formatted? or was it just plugged in after being taken out of the shipping box it came in?

 

Was the drive with the "red" indicator ever part of your array?  (in other words, it was cleared, formatted, and either had files on it, or was ready for files to be added)

 

Does the drive with the "red" indicator say "unformatted" or "missing"?  (unformatted on the web-interface does not always mean what it says, it simply indicates the drive does not have a reiserfs filesystem on it, or failed when it attempted to mount the filesystem to a mount point in the array.  It could be a cable problem, or a disk failure, or a power supply issue, or a missing or damaged file-system on that disk)

 

To help more, you will need to give more clues.  Posting your syslog will help tremendously.

 

I would not attempt an upgrade of the unRaid from 3.0 to 4.xxx itself yet... not until you get back to a stable set of working drives.

 

Joe L.

Thanks Rob & Joe:

 

Let me try to be more specific, the 6th drive is essentially # 7 counting Parity.  Yes, I cleared and formatted the drive after installation with no errors and yes it was originally included in the Array.  I have accessed it previously to establish a "Movies" Share, but don't think that I put much into the drive (I had basically run out of room on my other 5 drives and knew that the next movie would require additional space).  My router apparently died over the Thanksgiving Holiday () and when I rebooted the server, I had a Red Light on drive number 6 (7 including parity) in the Main Tools admin control page.  Initially upon seeing this page, it indicated errors on that drive.  I again rebooted the Server and it displays no errors, but does display a Red Light/dot on drive 6 (7).

 

With regard to the disk/lot/size, somewhere I remember from maybe the original version (1.0....) that the Parity Drive needed to be the largest drive (still does) so the question is whether or not another drive of equal size (as reported by the system) is causing a problem, even though the drives were not made at the same time.

 

RE: Version 4.x of the software, I have two keys.  I attempted several months ago shortly after 4.0 final was released to upgrade one of my Keys to that Release.  Upon reboot with 4.0, nothing happened, the Server failed to boot and/or load UnRaid.  As I was occupied with other matters, I simply removed that Key inserted the other Version 3.0 and rebooted w/o problems.  My question (posed poorly) was whether or not attempting to upgrade to 4.2.1 would offer me more flexibility and perhaps better control.  It was also directed at my problem with drive 6 (7) such that I might better understand the problem with that particular drive.

 

Finally, if my new drive is causing a problem not related to size - ie errors etc.  Perhaps I should RMA it as it is only ~ 4 months old.  Don't particularly want to unless necessary, but no sense in storing data that will get lost in the future either.  Again, not sure how much if any data is stored on the drive at this point.

 

Thanks for the help, looking forward to your thoughts!

 

Dave

Archivist,

 

Thanks for the clarification.  It helps a lot.

 

1.  Parity has to be as large, or larger than any other drive.  If it was not you would see an error message and the array would not start. Since you did not get that error, and the disk size on the management page is the same as the parity drive, the disk size is not the issue (regardless of the brand/model)

 

The red light on the drive on the management screen indicates it has had errors when it was written to and was disabled by the unRaid software.  If you post your syslog contents we would see more details of the exact failure.

 

Odds are high you can still get to the contents of the defective disk and even write to it... however, it is just the unRaid parity software in action, helping you until you can resolve the failure... the drive with the red indicator (drive 6, not counting parity) on the control panel is not working properly.

 

It could be any one of a number of causes.

It could be a loose power cable to that drive.

It could be a loose data cable to that drive. (power down and unplug the server. With power off, re-seat both ends to be sure..)

It could be a poor quality data cable that causes the write errors. (use only flat, 80 conductor cables.)

It could be the promise controller card is not seated well in the motherboard. (especially if this is the only drive on it)

It could be the promise controller card is defective (try swapping it with the other card to be sure, again unplug server first.)

Lastly, it could be the drive itself is defective and you need to take advantage of the RMA/waranty.

 

Once you get this resolved you can again try to upgrade to the new release.  I would not until then. The new release does not have anything I can think of to fix your defective drive.

 

Joe L.

Thanks Joe:

 

Great response, I'll give that a try and see what happens.  My Server is "headless" so it makes looking at it while booting a problem, still should be able to check the connections etc and then see if it comes back online.  If not I'll try to get a syslog to post.  Is there any specific command that is most useful?  I've used the one posted on Lime Technology (cat /var/log/syslog), but it goes by so fast that I can't read and don't know how torecord it.  How do you send it to a file that I can attach it to this message?  Or is there a command that would be specific to 'hdg' (drive 6)?

 

Again thanks for the tips, will let you know!

 

Warmly,

 

Dave

 

Hello Joe/Rob:

 

Tried to reset the drive and cables w/same results (I mis-spoke, its the 2nd drive (primary) on my Promise card - direct connected to port 2 (ribbon cable) not 'slave' on port 1 (drive on 1st port works fine)).  Was able to access the drive thru network, but it only shows the Movie Sub-Directory that was created for the Movie Shares.  At this point there is apparently no data stored on the drive.  W/o removing it and putting it into another machine, I'm not sure how to test it further, perhaps the Syslog would give a better clue.  I think I have another equivalent drive that I purchased for additional storage, so could replace and allow it to rebuild overnight if necessary.

 

Dave 

It is easy to save a copy of the syslog to a file you can then post.

 

Log in via telnet and then type:

cp /var/log/syslog /boot/syslog.txt

 

Then, you can get to the file from windows file-manager (it will be located in the top directory on the flash drive).

If you rather copy it to one of your data drives, then

cp /var/log/syslog /mnt/disk1/syslog.txt

and the file will be on disk1.

 

Once a copy of the file is saved, to the flash drive or to the disk, you can get to it from windows.

 

Hi Joe:

 

Thanks, sorry I frankly don't read Linux very well so please bear/bare (sic) with me!  Anyway I've tried to attach the file to this post.  As noted its a bit too cryptic for me to decypher but would appreciate your input and expertise as to whether I should just pull the drive or re-format/re-cycle it.  If so, I don't remember exactly how to start the process after the initial effort save removing, installing in another computer and removing/deleting all partitions.  I'm sure that there is a Linux command, but don't want to risk losing my other data.

 

Thanks for the command, looking forward to your interpretation!

 

Warmly, Dave

 

:'( Drat, it doesn't want to attach - can you tell me what part might be most relevant so I can extract that for you and attach it to another post?  I could also PM you with it attached if that is more practical.

 

Dave

Looks like the attachment feature is still broken.

 

You can upload the file to this site http://www.savefile.com/

No need to register, just use the fields on the lower left of their home page to browse to your syslog.txt file and upload it. Then cut and paste the download link here.

 

If there are any files that were on the failing drive now is the time to copy them to a different drive. (unRaid might still let you get to the failed drive contents by re-creating it from the remaining working drives)

 

Then, you can remove the drive to a different PC and reformat it before putting it back in the unRaid server. (If it can even be accessed)  If you replace the drive with a new one unRaid will re-create the old contents for you (as long as you did not manually re-calculate parity or re-initialize the array while it was defective)

 

Joe L.

Hi Joe;

 

File uploaded to http://www.savefile.com/files/1231948, I suspect that you might need that number.  I can certainly pull the drive (though probably tomorrow at this point).  Should I just reformat and re-install to see if it's ok or should I simply replace if possible?

 

Dave

Interesting, I can't see any errors in that syslog...

 

What does your unRaid management page show?  The last thing I saw in the log was that a parity check was in progress.

 

Log in via telnet and type these commands to see the internal status of your array.  Post it, it should give a few more clues.

mount

smbstatus

echo "status" >/proc/mdcmd

cat /proc/mdcmd >/boot/mdresp.txt

cat /boot/mdresp.txt

 

The first two commands will output to the screen.  The next three lines will request unRaid to put its current status in a file on your flash drive named "mdresp.txt"

 

Joe L.

Well, thank you, that was one of the more interesting syslogs I have ever read, an unRAID 3.0 syslog using Linux kernel 2.4, with some very odd behavior.  At first glance, your unRAID system appears to boot fine, and be fully ready, with all drives green.  But as Lee Corso might say, "Not so fast my friend...".

 

Here's my analysis of what happens, and I would really like to hear from Joe and Tom or anyone with 3.0 syslog experience, as to whether this was normal or not, perhaps a 3.0 workaround.

 

After booting and Linux initialization, hardware identification and device assignment, 7 drives are found, identified as hda through hdg, ST3500841A through ST3500830A.  Then the unRAID driver is loaded, xor tests are run, and the superblock from the flash is read, but here things become bazaar.  The slot info appears to be *backwards*, Parity -> Disk 6, Disk 1 -> Disk 5, Disk 2 -> Disk 4, and Disk 3 matches itself.  It imports the 7 drives and tries to match them with their slots, but has to mark Parity, Disk 1, Disk 2, Disk 4, and Disk 5 as 'Wrong'; and Disk 6 is marked 'Replaced', probably because of a previous run, either from the disk errors you saw, or because it couldn't find a Reiser file system on this parity drive.  At this point, unRAID seems to know something is wrong, and restarts this process.  It unloads itself, reloads itself, checks the xor tests, then reads the superblock again, and this time finds a correctly ordered list.  The 7 drives are imported and matched with their slots without any problems, and mounting and checking the file systems proceeds without issue, although extremely slow with numerous long delays, especially of Disk 6.  What should only take a few seconds, takes over a minute.  Then an hour later, 7 sleep commands are issued, and that is the end of the syslog, with what *appears* to be a fully ready unRAID system.

 

Then I noticed that the first sleep command was issued to hdg (Disk 6) two minutes before the others.  Sleep commands are useful for indicating the last actual physical access of a drive, and in this case indicate that the mount command was the last physical access of Disk 6.  All of the subsequent minute or two of file checking and setup could not have involved the physical Disk 6, and therefore must have involved a virtual Disk 6, reconstructed from simultaneous accesses of the other 6 drives.  That of course explains the very slow file system mounting and checking.  But from the syslog, Disk 6 had been recognized and mounted like the others, so all I can conclude is that it still used the earlier status of Disk 6, and considered it Disabled.  It could well be a good drive, but the superblock needs to be thrown out, and rebuilt.

 

I'll offer some recommendations, but I suggest you await more veteran advice first.

 

If it were me, I would backup the flash, then upgrade to 4.2.1 (an optional step), to avoid any further problems with 3.0.  Then I would select the Restore option that marks all of the drives as New, stopping the array if necessary.  This should clear the superblock, which contains unRAID's table of the drives with their ID's, sizes, and status.  Do not Start the array yet, but at the console run reiserfsck on hdg, perhaps the other drives too.  See the Wiki or search the forum for more info on reiserfsck, and any subsequent fixes.  It's analogous to scandisk.  This should give you an early indication of the condition of drive 6, and you can then decide further operations on it.  When you are satisfied with it or its replacement, then Start the array, and Parity will be rebuilt.

 

One other note, the network connection may be 'flaky' (highly technical term).  It appears that 'Link beat' was not detected until 5 minutes after unRAID started, then when detected, the network connection was OK.  If your network was down, and you turned your router on 5 minutes after booting unRAID, then that would explain it.

 

Edit:  Oops, I took too long writing this, and Joe has already responded.  Joe, could you verify that parity check?  The drives are put to sleep at the end.  Otherwise, good advice from a Linux expert, which I'm not.

 

I actually like Rob J's idea of using your other flash drive and key to upgrade to 4.2.1 and leaving this flash drive the way it is.  If you have a second flash drive and key we could get that one up and running as easy as this.  That way, you know you can always re-group to the older release.  (Just don't add new hard-disks, or remove hard-disks, and keep the SAME parity drive till we get this figured out and stable)

 

If you don't wish to do that, and want to try to get 3.0 running... here are some thoughts.

It has been a while since I booted up on a version 3.0 unRaid but I don't remember the md driver being loaded and then unloaded and then loaded again.  I saw that in the syslog, but did not remember if it was normal.

 

I did not pick up on the fact that the drives read from the superblock were initially loaded in the wrong order. Good eyes Rob J..

 

I know that the superblock was originally on its own partition on the original version 1 and 2.xxx unRaid and that it was moved to a file /boot/super.dat in version 3.xx of unRaid.  That migration also asked that you use the default disk.cfg that was supplied with the 3.0 release unless you were using a mixed IDE/SATA array. It might also have something odd in it. perhaps you can paste the contents of disk.cfg in your next response to us.

 

Fixing your superblock it might be as easy as stopping the array, re-naming the super.dat file to super.old and letting unRaid create a new super.dat for you when you start it again.  (I think it will)

 

Before you do this you will need to make a note of where you have assigned your physical drives since you will need to re-assign them again to the SAME logical slots.  (or at least get the parity drive assigned correctly)  Then you can simply "re-assign" the devices and finally re-start the array (if it lets you) or Rebuild/Initialize the array to completely rebuild parity.

 

Stop the array, Log in via telnet and type:

mv /boot/super.dat /boot/super.old

Whatever you do, if it asks you to re-format a drive, DO NOT DO IT unless you do no want the data on that drive... if it is reformatted, you will erase the contents of that drive and parity will NOT replace it as you will be also changing parity to know your drive is empty.

 

If asked to format a drive, stop the array, copy super.old to super.dat and you should be back to where you were.

cp /boot/super.old /boot/super.dat

 

So... write down your current drive assignments.  Then stop the array, move the super.dat file to a new name, reboot (so it forgets about the old superblock data) go to the drive assignment page, re-assign the drives to their correct slots, and then Rebuild/Initialize the array which should then re-compute parity. 

 

While doing all this DO NOT introduce any new drives, or remove any existing drives.  We do not want to confuse unRaid more than it is now.

It is not a bad idea to do a file-system check on your drives, especially the one with the errors. search for reiserfsck as described in a prior post.

 

If you see any notice on the management page that a drive is unformatted STOP... go no further... send us a new syslog, etc.  In fact, if unsure at any time, stop and ask for guidance. 

 

Joe L.

 

RE: Version 4.x of the software, I have two keys.  I attempted several months ago shortly after 4.0 final was released to upgrade one of my Keys to that Release.  Upon reboot with 4.0, nothing happened, the Server failed to boot and/or load UnRaid.  As I was occupied with other matters, I simply removed that Key inserted the other Version 3.0 and rebooted w/o problems.  My question was whether or not attempting to upgrade to 4.2.1 would offer me more flexibility and perhaps better control.

I think there are several threads concerning users that had a bit of trouble upgrading to v4, although I think they were resolved.  The steps to upgrading from v3 to v4 were more complex than any upgrade since, so you may want to doublecheck them.  It could be something as simple as making sure that the flash has a volume label exactly equal to:  UNRAID

 

I hope I didn't confuse you with my suggestion to upgrade to v4.2.1, as I had already completely forgotten Joe's advice to stick with v3.0.  That is normally always the best choice, until things are stable.  Good troubleshooting involves 'controlling the variables', making only limited changes per troubleshooting step.  In this case, my examination of your syslog did not inspire me with much confidence in your v3.0.

 

Personally, I think the upgrade from version 1.x or 2.x to 3.0 was most complicated for most.  It involved using "dd" to read from the hidden partition on the flash drive Tom had supplied and writing it to a file, then doing all the other steps to make it bootable, changing from using the GRUB bootloader to using syslinux.

 

Looking at Tom's main site, those original 3.0beta instructions are now GONE!  The only instructions to upgrade from a version earlier than 3.0 are in this support forum, and only because a user detailed the steps they had taken for other to follow. you can find it if you search for "if="

 

 

 

 

Wow 

 

What a response (set of responses)!  Thank you both so much (Joe/Rob), I'll try to be worthy of your efforts in my behalf.  Rob what an analysis, whew, I'm sure glad someone can read that stuff and better yet understand it  !!!

 

Joe from the Mount command I get:

 

/dev/ram0 on / type ext2 <rw,noatime,nodiratime>

proc on /proc type proc <rw>

/dev/sda1 on /boot type vfat usbfs <rw>

usbfs on /proc/bus/usb type usbfs <rw>

/dev/md4 on /mnt/disk4 type reiserfs <rw,noatime,nodiratime>

/dev/md5 on /mnt/disk5 type reiserfs <rw,noatime,nodiratime>

/dev/md3 on /mnt/disk3 type reiserfs <rw,noatime,nodiratime>

/dev/md2 on /mnt/disk2 type reiserfs <rw,noatime,nodiratime>

/dev/md1 on /mnt/disk1 type reiserfs <rw,noatime,nodiratime>

/dev/md6 on /mnt/disk6 type reiserfs <rw,noatime,nodiratime>

 

smbstatus:

Samba version 3.0.10

PID             Username        Group             Machine

-------------------------------------------------------------------------------------------

 

Service            pid            machine               Connected at

----------------------------------------------------------------------------------------------

disk5                1290          xpc-mce             Fri Nov 30 11:20:39  2007

 

No locked files

 

The MDRESP.TXT file has been uploaded to http://www.savefile.com/files/1233746

 

Joe, I hope that gives you something, I will try to update my other flash drive to 4.2.1 in the meantime, but as you noted, I may really need to get this one working first.  Up until my recent Router problem, I'd really not experienced significant difficulties.  To work on the unit I did bring it back to a KVM switch so can actually interface directly with it vs telnet if that helps, though I'm not Linux savvy!

 

Dave

Thanks for uploading the mdresp file so quickly.

 

Its content is what is interpreted by the management web-page.

 

Basically, according to it, your array has a single failed drive. (drive 6) 

All of the drives are mounted on their respective mount points, and if you either read or write to the drive it thinks is defective the parity drive in combination with all the other drives in your array would be used to respond to the request.  This feature is exactly why we have all purchased an unRaid array.  As far as unRaid is concerned, the drive has failed and you have not lost any data that was on it.

 

If you want to be absolutely sure to not lose anything important, you can browse /tower/disk6 using windows and copy any files on it to other drives before going any further.

 

Then we have to make the unRaid array think you have replaced the defective drive. (the drive it thinks is defective)

 

We can try something simple, but first lets make a copy of the super.dat file.  We can always revert back to it if we need.

log in via telnet and type:

cp /boot/super.dat /boot/super.old.dat

Then, using the management web-page stop the array.

Once stopped, go to the devices page and unassign disk6. (the disk that is failing)

Now, go back to the main page and re-start the array. It should come back on-line and show disk6 as missing.  This simulates a complete failure of disk6. As a side affect, it also clears the serial number of disk6 from the super.dat file on your array.  You will still see disk6 marked as "red" but will still be able to read and write to disk6 from windows explorer.  This is exactly as if your drive6 had died completely. unRaid will read all the remaining drives to let you get to files it re-creates on the fly by reading all the other working drives.

 

Now, stop the array once more, go to the devices page and re-assign disk6. unRaid will think it is a new drive.

Go back to the main page and re-start the array.

 

unRaid should now see the new drive (new to it) and start re-building it with the contents of the old drive6. (You and I know it is the same physical disk as before, but it doesn't, because we cleared its serial when we marked the slot as unassigned.)

 

When it is done rebuilding disk6, the array should be back to normal. (the re-build could take several hours or more, depending on the speed of your array. On my slower IDE baseed array, a 500gig drive would take 5-6 hours to rebuild.)

 

Now, stop the array once more (to get a clean version of super.dat) and again type

cp /boot/super.dat /boot/super.dat.good

Now assuming everything worked as expected, you can re-start the array one last time and all should be green.

Hi Joe:

 

Thanks for the suggestions - one problem (??) I get back a cp: cannot stat  '/boot/super.dat' No such file or directory.  So I looked on my flash and found that my super.dat file was in a Config sub-directory.  When substituting /config/ for /boot/ I got the same response - cp: cannot stat '/config/super.dat' No such file or directory.

 

I tried to find a set of Linux commands (to not waste your time) but nothing that I've tried seems to get me to the /config/ sub-directory or even to a listing in the flash via telnet.  Sorry to be a bother and such a Linux boob, but I'm frankly lost.  I can work windows/even Dos but not much Linux/Unix or at least this flavor!  Aside from a direct command, can you point me to Tom's Linux (flavor) help file and perhaps a Dos/Linux command line 'Rosetta Stone  '?

 

Regards,

 

Dave

 

PS - I'm back at Hospital tomorrow, so may/may not be back until later!

That should be: /boot/config/super.dat

 

To change directory:

cd /boot/config

To change to "home" directory

cd

To list the contents of the current directory (similar to "dir" commanf in MS-DOS)

ls -l

To list the contents of a different directory (/boot for example)

ls -l /boot

To list all the files, including hidden files  (file whose name starts with a "." are not listed unless requested by use of the -a option to ls)

ls -a /boot

You can give multiple options like this:

ls -al /boot

Or get a short listing of only the file names, without details, like this:

ls /usr

To move a flie (rename it, or move it to a different directory with same or different name)

mv current new    where current=path to current file, new=path to new file

To copy a file

cp current new  where current=path to current file, new=path to new file-name

Joe/Rob:

 

Thanks again for the response, you're GREAT  !

 

The copy command worked but when I halted the Array, I lost the Main.Htm from my computer - running dog slow  .  Anyway, went downstairs to another (off KVM) re-booted server, then was able to Stop Array and Unassign Drive 6.  When I restarted, it didn't see the 6th drive and is currently doing a Parity-Sync ~ 475minutes.  When its back up I'll stop it again and re-enable the 6th drive, though have thought about Rob's suggestion to check it with Reiserfsck.  Can I do that through the server w/o removing it?

 

Also took my 2nd Flash and checked it's Volume name - correct again, it was called Corsair - changed to UNRAID and updated to 4.2.1 from web site.  I plan to try disk in 3.0 first and if ok, will switch to 4.2.1 to see if that gives me more control(s).

 

Again, thanks for the help.  I'll let you know what transpires after the Sync and Re-Boot's and if I switch to the newer release.   

 

Dave

 

PS - when I get this fixed, I have a couple of questions about how to use the server with my network/HTPC and projector.  I'm primarily using it for Movies and would like to transmit them directly to my TV's or Projector w/o using another computer (ie Windows) if possible.  I'm aware of MythTV but that's on another distro, so not sure how I might send my video files out.  Ideally DVI or better HDMI, but the problem I've had is accessing them through a Icon vs. List (eg XXX= sub-directory XXX/Video_TS/*.vob.  While I might be able to perform that task (if trained  ) I'm pretty sure the WAF will rebel!   :'(

 

Warmly,

 

Dave

After you unassigned disk 6 and re-started the array I did not expect it to start a parity calculation.  Did you request one, or did it do it on its own?  Did you press the button to Restore/Initialize the array? or just to Start the array?

 

The reason I ask is because parity is now being calculated without the contents of disk6. (effectively, forgetting disk6 was ever part of the array... as if you asked unRaid to Restore/initialize the array)

 

Regardless of how the parity calc started,

Once parity has been calculated you can stop the array and re-assign disk6.

 

Now, back on the main page, this time check the little checkbox (I am sure...) and then press the button marked "Restore"

Unraid should again re-calculate parity on what it thinks is a new configuration and write a new superblock file. (with a new disk6)

Since disk6 already has a file-system on it it will simply be added to the array and not be cleared.

 

Good luck.

 

Joe L.

Hi Joe:

 

Nope, just asked that the Array be restarted and it ran a Parity Sync.  After completion, I re-assigned Disk6 and as noted did the little check box.  It then classified the drive as Unformatted and cleared, is now formatting the drive (not restoring it).  I was about to write to let you & Rob know that it reported 2 Reads & 2 Writes and 4 Errors prior to starting its formatting.  I'm not sure but 2+2 = 4 which does not make me very comfortable.  Since its started the formatting routine, I'll let it go through but am not sure this is a good drive.   

 

Will keep you posted, as noted nothing really stored on drive that I can remember or saw other than Movies Sub-Directory for the "movies share", thus hopefully nothing really lost!

 

Just checked before posting this reply and it shows a disk6 RED Status Dot - Temp *  / 488,386,552 Size / 488,338,744 Free / 2 Reads / 2 Writes / 4 Errors and the Array minus drive6 is online.  Do I need to Stop and Restart the Array in order to incorporate Disk6 (I don't remember this from before)?

 

Dave 

Time to post another syslog so we can see the error messages in more detail.  But basically, more write errors occurred and the red-indicator shows the drive was taken off-line once again.

 

I think you said earlier you had a spare drive you could install in its place.  Now is as good a time as any to stop the array, then power down, replace the drive with the alternate one, then start it back up.  Let us know if the errors go away.

 

Joe L.