Okay, on the latest firmware and seem to have been running fine. Today I decided to reorganize some of my music files and upon attempting to create anything except folders in that directory I get error that states "The request could not be performed because of an I/O device error." in Windows. Tailing the log I see something a bit ominous when this occurs:

 

Sep  1 10:50:21 BEAST kernel: is_tree_node: node level 36680 does not match to the expected one 1

Sep  1 10:50:21 BEAST kernel: md(9,5):vs-5150: search_by_key: invalid format found in block 40599032. Fsck?

 

Now, this looks to me like corruption of the file system. I believe what needs to be done is the equivilent of a checkdisk on the file system. This drive is the only one I know of at the moment having these issues and playback of the files on it seems to work fine so far. I'm hoping I don't lose data and would be interested in hearing how I might prevent this in the future <gulp> I suspect it has to do with some of the lockups I experienced not long ago however I had hoped that the Parity drive would've prevented this kind of issue. It's yet to ever find errors while doing it's check.... Thoughts?

Interesting - a search on Fsck here reveals a posting of mine talking about this back in MARCH on this same drive with no responses. Tom, you still around?

 

http://lime-technology.com/forum/index.php?topic=35.0

 

Edit: Okay, not liking what I'm seeing with regards to this tool - warning of dire destruction if not run correctly etc. Our drives seem to mount in an odd fashion too so I'm not even really sure how to point the Fsck command at them. Anyone else encountering this? I cannot be the only one with issues like this.....

Tom was around today, hopefully he can help!! Sorry, I have not seen this error and even if I did... you would have seen my post on here   Good luck!!

Here's how to fsck a disk.

 

<...previous instructions deleted...>

 

Follow the instructions a few posts down.

THANK YOU!

 

I will run this ASAP, I have a few DVD coying to other drives at the moment and with two machines contending it will be a few mins (lol). As soon as that is done I'll run this - fingers crossed!

Here's part of the first run:

 

bad_indirect_item: block 40751368: The item (22105 22122 0x1 IND (1), len 3184, location 912 entry count 0, fsck need 0, format new)                                              has the bad pointer (794) to the block (40567583), which is in tree already

bad_indirect_item: block 40751368: The item (22105 22122 0x1 IND (1), len 3184, location 912 entry count 0, fsck need 0, format new)                                              has the bad pointer (795) to the block (40567584), which is in tree already                                            / 68 (of 170)                                            block 40566786: The level of the node (22875) is not correct, (1) expected

the problem in the internal node occured (40566786), whole subtree is skipped                            /149 (of 168)/ 57 (of 162)                                            block 40594524: The level of the node (6205) is not correct, (1) expected

the problem in the internal node occured (40594524), whole subtree is skipped              finished                              )

Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.

Bad nodes were found, Semantic pass skipped

2 found corruptions can be fixed only when running with --rebuild-tree

###########

reiserfsck finished at Fri Sep  1 12:31:53 2006

###########

 

 

Will now run with the Rebuild option...

Okay, just done with the rebuild. Claims to have deleted 8 "unreachable" items. Running the normal Fsck again right now just to be sure and then will put it online.

 

All along I've seen odd things like directories or files I could delete or would be stuck R/O. If I'm lucky it's these weird things and not MP3 being deleted Okay, no probs in the last check - putting it online fingers crossed!

 

Okay, it's letting me copy stuff and near as I can tell (heh) I've not lost anything but with this many files it's hard to tell. Any reason why I shouldn't Fsck my other drives? And how do you know that hdj1 is disk 5? That seems weird 

 

Thanks for the support!

Ah, shoudl anyone else do this - do a Parity Check afterwards. This modifies the drive structures without the parity drive knowing about the changes. Updating parity afterwards is a must. I may Fsck the rest of my drives just to be sure but not tonight. Normal Fsck isn't bad but if you have to do the rebuild it takes awhile...

Checking my other drives now. hda1 appears to be the flash and will not allow a Reiserfsck to be run on it since, duh, it's not a Resierfs. My "b" drive came out fine with no errors - it's seldom written to and is used to house my backups. "c" on the other hand also has issues and it being rebuilt now. My last Parity check after having done this encountered 18K errors+. I think this time I'll enumerate all of my drives with Fsck and then run Parity

 

I'll edit this post if I find additional drives with errors. i have 8 data disks and the rebuild takes time so this might be awhile...

Ok - erase that last procedure I gave you - actually I'll probably delete the post soon so that people don't do it...

 

While the procedure I said for executing fsck is correct, as you observed, it results in getting parity out of sync.  There is a way to do it where parity stays in sync, and that's what you want to do:

 

1. Start the array as normal.

 

2. telnet into the server and type the command: 'samba stop'.  This will take all the shares off the network.

 

3. type the command 'df'.  This will show you all the "mounted" disks.  The ones of interest are:

/dev/md1

/dev/md2

etc.

These are all your data disks (md1 corresponds to disk1, md2 to disk2, etc.)

 

3. Decide which disk you want to fsck, for example, let's say disk5.  Type the command 'umount /dev/md5'.  Notice the command is indeed 'umount' and not 'unmount'.

 

4. Now type 'reiserfsck' and when prompted, type 'Yes'.  Let this run - it might take a long time.  There are some options you can give 'reiserfsck' to control how much rebuilding it does.  For a complete explantion check here.

 

5. Once complete you can re-mount the volume by typing the command 'mount /dev/md5 /mnt/disk5'.  Follow the pattern for other disks.  After you've re-mounted all disks you un-mounted earlier, type the command 'samba start' to re-export all your shares.  Note:  the 'mount' command can take several seconds to complete.

 

6. An alternative to step 5 is to just go back to the Management Utility, Stop the array, then Start array again.

 

 

Heh, yeah it sure does knock the array out of Parity but honestly this seems "right" since it's changing things without the Parity disk knowing about it <shrug> Understand your wanting to modify things though if there's a better way - if we could somehow run this from the WEB interface I think it would be something good to add to the "tools" page just in case.

 

As it happens at least one other drive *did* have corruption. I have fixed it up and near as I can tell nothing was lost - whew! I'm not sure how this corruption crept in and suspect a lockup or somesuch did it but who knows. The good news is that all data looks good right now and that the problem wasn't really widespread. Had I not begun to receive I/O errors I'd have never known there was a bad problem although the Fsck? message in my Syslog a bit ago was kind of a hint that something fishy was going on <shrug> all seems well now and i'm about to add a bunch more DVD to the array

 

Hrm, any way to monitor Syslog and run the Fsck as a sort of scheduled or recommended process perhaps?