This just started happening and I have no idea why.

 

My parity check just completed today and there were 0 errors

 

When I try to rename a folder on the tower I get a message in windows saying that it is in use by another program.

I even rebooted the tower and I still get the same thing.

 

I am using 5.0.5.

I have not updated UNRAID in about a month.

 

Really lost on this one.

Any ideas on where I can look?

 

Thanks

Could be a problem on the Windows side.  Try renaming it with MidnightCommander(MC) or the command line in unRAID and see if you get a "in use" type of error.

I was wondering if Windows could be the issue. I will try it from a different computer and see if I get the same problem.

 

Windows machine does not matter. I get the same issue from all of them

 

It is definitely just the one tower.

My other 2 towers are just fine.

I have no idea why this is happening.

 

I logged on with putty and tried this:

 

root@Tower:/mnt/disk4/Data# mkdir Test

mkdir: cannot create directory `Test': Read-only file system

root@Tower:/mnt/disk4/Data#

 

Why would this happen?

 

My parity check finished yesterday with no errors at all.

 

Please help

Could be a reiserfs problem, search for dgaschk as they link to a check file systems wiki that may help

 

Sent from a mobile device, sorry for any typos.

 

 

http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems

 

Just 'Check' don't try to FIX until you check back in with results...

 

It appears to only be disk4 on tower #1

I am running the check now

Will post results

 

Here are the results:

 

root@Tower:~# reiserfsck --check /dev/md4

reiserfsck 3.6.24

 

Will read-only check consistency of the filesystem on /dev/md4

Will put log info to 'stdout'

 

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

###########

reiserfsck --check started at Fri May  2 10:01:56 2014

###########

Replaying journal: Trans replayed: mountid 164, transid 6364468, desc 795, len 1, commit 797, next trans offset 780

Trans replayed: mountid 164, transid 6364469, desc 798, len 1, commit 800, next trans offset 783

Replaying journal: Done.

Reiserfs journal '/dev/md4' in blocks [18..8211]: 2 transactions replayed

Checking internal tree.. \/ 16 (of  20//140 (of 160-/ 40 (of 170-block 179078502: The level of the node (28559) is not correct, (1) expected

the problem in the internal node occured (179078502), whole subtree is skipped                        /152 (of 160|/  1 (of 170/block 181121860: The level of the node (38251) is not correct, (1) expected

the problem in the internal node occured (181121860), 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 May  2 10:24:14 2014

###########

 

Okay.

NOW YOU NEED AN EXPERT...to quote the Wiki:

"Important Note!!!  Do NOT run reiserfsck with the --rebuild-sb or --rebuild-tree switches, unless you are instructed to, by the instruction of a previous run of reiserfsck, or by an expert user!  They are last-resort options, to repair a severely damaged Reiser file system, and recover as much as possible. They almost always create a lost+found directory and place in it the files, directories, and parts of files it can recover.  It will then be up to you to rename them and restore those files and directories to their correct locations.  Many times it will be possible to identify them by their contents, or their size."

I'd probably run "reiserfsck --rebuild-tree /dev/md4", but that's 'cuz I have backups and love living on the edge. But I'm not that expert to tell you to do the same. There are a number of experts here...they'll chime in shortly, I'm sure.

OK hopefully an expert will chime in.

I have to go to bed. Too tired to stay up

 

I will be checking once I get up. Hopefully this can be resolved

 

Thanks for your help

Run with rebuild tree.

Running now. Will post results

 

Here are the last of the results:

 

Pass 1 (will try to insert 466798 leaves):

####### Pass 1 #######

Looking for allocable blocks .. finished

0%....20%....40%....60%....80%....100%                        left 0, 105 /sec

Flushing..finished

        466798 leaves read

                466658 inserted

                140 not inserted

####### Pass 2 #######

 

Pass 2:

0%....20%....40%....60%....80%....100%                          left 0, 18 /sec

Flushing..finished

        Leaves inserted item by item 140

Pass 3 (semantic):

####### Pass 3 #########

... ownload/Games/PC Game ISOs/Grand Theft Auto 4/Grand.Theft.Auto.4.Disc.1.isovpf-10680: The file [483973 483991] has the wrong block count in the StatData (8989304) - corrected to (8151192)

... ownload/Games/PC Game ISOs/Grand Theft Auto 4/Grand.Theft.Auto.4.Disc.3.isovpf-10680: The file [483973 483994] has the wrong block count in the StatData (8704456) - corrected to (6440504)

Flushing..finished

        Files found: 111324

        Directories found: 11756

        Broken (of files/symlinks/others): 2

Pass 3a (looking for lost dir/files):

####### Pass 3a (lost+found pass) #########

Looking for lost directories:

Flushing..finished78, 75 /sec

Pass 4 - finished done 465925, 61 /sec

        Deleted unreachable items 380

Flushing..finished

Syncing..finished

###########

reiserfsck finished at Sat May  3 04:10:17 2014

###########

 

The lost and found folder is empty

 

hmmmm...

So it sounds as if your array's file structure is back to stable.

(i'd run ReiserFS with JUST the 'check' option again, just to be sure)

 

Unfortunately, it looks as if it deleted some data, and didn't have enough to even put it in Lost and Found.Pass 4 -

finished done 465925, 61 /sec

        Deleted unreachable items 380

You can try running with scan-whole-partition if something important is missing.