I'm trying to rsync some directories from an existing file server to migrate to using unRAID.  The rsync was interrupted because I changed NFS options in the middle of the job.  When I restarted it, it failed with an error about "no such file or directory."  Looking at it, I find I managed to get a corrupted directory on the unRAID server and I can't figure out how to get rid of it.

 

# ls -la
/bin/ls: cannot access deHTMLxs: No such file or directory
total 0
drwxr-xr-x 1 root root 72 Sep  3  2008 ./
drwxr-xr-x 1 root root 72 Sep  3  2008 ../
d??? ? ?    ?     ?            ? deHTMLxs/

 

I've attached the syslog which includes obvious errors in the NFS parameters from when I tried to set client NFS parameters on the server (oops).  Also, for reasons I don't understand, during the middle of the night, ifplugd seems to have decided that it lost the link on eth0 and kept taking my connection up and down.  I had to manually restart the network this morning.

 

 

I've had corrupted directories like this before.

I had to umount the filesystem then run an reiserfsck on it.

 

See the Wiki for more information

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

 

If it were me I would remove the directory and rsync that directory over again after checking the file system.

 

 

 

I just finished running reiserfsck.  It claims no corruption.  But I can't remove the directory because it says it isn't there.  And I can't create it because it is there.

 

I'm getting a bit frustrated with this whole thing.  The write performance sucks compared to my usual RAID1+LVM, but I figure I can deal with tuning the performance and get something reasonable eventually, but the apparent sensitivity to NFS mount parameters (my other post about the NFS mount just not responding and the drives spinning down while a client was actively trying to write) and now this are hair-pulling experiences.

 

If I can't figure out how to fix this problem, I'm left with trashing the disk contents and starting over.  And no confidence that it won't happen again.  Right now I can afford to start over since I haven't yet sync'd the old data, but if I commit to unRAID and this happens, then what?

 

Okay, I'm rambling at the end of long day, but I am frustrated with this.  I've never seen a situation like this with ext2fs.  Yes, I've got corrupted files and directories, but either they could be deleted or they could be "fixed" with fsck.

NFS support is a beta feature, not well tested yet.  Since you were testing with v4.4.2, I would strongly recommend that you move to the latest beta, v4.5-beta7 at this writing.  However, I can't promise that will completely resolve your issues, but hopefully will improve the NFS behavior.  I suspect that Tom will want to have a look at your syslog.

 

We have some excellent Linux gurus, that should be able to help you remove that dir entry.  Most of us don't use NFS, and have NEVER seen anything like your problem.  I'm rather surprised that reiserfsck did not clean it up.

 

The write performance sucks compared to my usual RAID1+LVM

 

You may be interested in the General Questions about unRAID section of the FAQ, which begins with some discussion of the advantages and disadvantages of unRAID vs other solutions such as traditional RAID.  It's all about using the right tool for the right job, and unRAID is not the best tool if high performance is a requirement.

 

Your Seagate 1.5TB drives are using firmware CC32, which is not one I recognize, could be newer than I have seen, or an older one.  Correct firmware on this drive model is very important, so I would check with Seagate to see if you need a firmware upgrade.  Your syslog showed one of the very typical timeout/frozen episodes.

 

Your networking connectivity was rather bad during certain periods, with only 10/100 speed available then.  Most of the rest of time, it connected at gigabit speeds, and you have very good equipment.  I would make sure you have a good cable between this machine and your router/switch, Cat5e or Cat6, with good well seated connectors.  I would also look for a source of strong interference near some point of that cable.  In particular, that source of interference was operating between 1am and 9:30am on November 4.

I'm aware of the performance issues and expected to have reduced performance compared to RAID1+LVM where "reduced" means I expect to have my 40MB/s drop by half.  In general, I'm not getting 10MB/s.  But perhaps its the cable....

 

I will try swapping cables; cables are always a possibility.  Interference seems unlikely due to both the location of the host and the fact that we were all asleep so no one was near the equipment to be doing anything.  The cable is 6ft Cat 5e, and I have others to try.

 

There's got to be a way to mark that inode as not a directory and let reiserfsck clean it up, but I don't know what it is....

 

 

I'm aware of the performance issues and expected to have reduced performance compared to RAID1+LVM where "reduced" means I expect to have my 40MB/s drop by half.  In general, I'm not getting 10MB/s.  But perhaps its the cable....

 

I'd strongly suggest you try the latest 4.5.8-beta.

There's some major speed increase with it.

 

Purko

 

Okay, I'll try using the beta.

 

As for the cable, my bad.  I had apparently grabbed a random cable and it was a Cat 5 cable instead of a Cat 5e.  I tossed it and haven't had the connection drop since.  I don't know why I even still have any Cat 5 cables since the whole house is gigabit ethernet....

Okay, I'm using the latest beta.  I need to do some real speed tests, but the first thing that is clear is that doing an rsync on the unRAID server to pull files onto it is significantly faster than rsyncing on another host going directory-to-directory through NFS.  If that sounds confusing....

 

One host has the old /data/astrofoto directory,  The unRAID server is automounted as /net/tower/mnt/user/astrofoto.  So this command will transfer over the data:

 

rsync -av --progress /data/astrofoto/ /net/tower/mnt/user/astrofoto/

 

That is running at 8-12 MB/sec, much better than the 2-4 MB/sec I was getting before, but still with room for improvement. 

 

Doing an rsync across the network from the unRAID server gets speeds of about 18-20 MB/sec.

 

But what is the weirdest?  At some point in the past couple of days, the corrupt directory file healed itself.  I have no idea how, but it is now just fine.  And I didn't have to delete it or run reiserfsck or anything.  Obviously, with the update to 4.5 beta 8, there was a reboot.