ixnu

Anybody got the "reiser_to_xfs" slackware package? Can't seem to find it

Reiserfsck on all disk = 0 corruptions xfs_repair = 0 corruptions Surprising to me since I've had to hard reboot about a dozen times in last two weeks.

True dat. Will run memtest when completed with fsck.

Smarts look OK to me. To answer your question, this is a box that has been running for about 5 years and has gone from 4.7 to 6.0 to 6.2.x to 6.3-rc5. This is the first non stable release that has been on it. Here is a full diag that I got after a hard reboot when I got back home this morning. I certainly appreciate you taking a look at it. The only option that I could think would be fsck fun. I have not run a memtest recently and it's not ECC tower-diagnostics-20161208-0822.zip

Currently running reiserfsck on all the disks. Not a fan of reiser...

More info: I finally got home to take a look. The shfs process was zombie and there were dozens of smbd processes opened by user account. I could not kill or HUP these and the box would never shutdown / restart with either shutdown or the powerdown script. Any ideas?

Unraid 6.3-rc5 No dockers or unsupported plugins - just a vanilla file server. Fix common problems completed. Long story, but I have not been able to properly shutdown my box after it's been up for more than 24 hours for about two weeks. I have attempted to use the powerdown and native shutdown scripts to no avail on 6.2.4. Neither script completes Usually, the box stays up fine after a hard reboot, but eventually samba and http no longer respond and shfs (zombie) pegs the cpu with dozens of smbd prcesses that can't be stopped. I can continue to login via ssh. I upgraded to the newest rc in hopes that the improved shutdown would help, but shutdown never completes. During this time two week period, I had a red ball and rebuilt successfully. I had read on the forums that Reiser could cause this issue if disks were nearing capacity, so i reduced them all below 90%. This did not work, so I started the process of migrating to XFS. I have also read that dockers could cause this, but i have never enabled it. If this should be combined with another topic, please forgive my search skillz. Unfortunately, I have filled my sata slots and I needed to consolidate in order to move to XFS. I shrunk the array and rebuilt parity successfully last night. But the issue has returned after about 24 hours. I can't create the hardware diag from the tools, so I have just included the syslog. I'm currently on travel and can't hard restart the box. I am in the process of building a new server, but I really would like this one to stay up as a backup and eventually replace my existing backup. Anybody have any ideas? log_05170043.log.zip

Great. Thanks. Running Reiser rebuild ^H^H^H^H^H^H^H^H repair now. Looks ~ 38 hrs to go.

Thanks itimpi Sorry, but I want to make sure I follow you. I assume this means a rebuild from parity NOT an additional Reiser --rebuild-tree on the new physical disk that is no longer emulated. Thanks again!

Running 6.0.1 ReiserFS I lost a disk (md7) and tried to rebuild md7. On the rebuild using two different disks, I got this: Aug 12 12:06:23 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 31374 does not match to the expected one 2 Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-5150 search_by_key: invalid format found in block 419397763. Fsck? Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [4565 5071 0x0 SD] Aug 12 12:06:23 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 31374 does not match to the expected one 2 Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-5150 search_by_key: invalid format found in block 419397763. Fsck? Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [4565 7549 0x0 SD] Aug 12 12:06:23 Tower kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 31374 does not match to the expected one 2 Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-5150 search_by_key: invalid format found in block 419397763. Fsck? Aug 12 12:06:23 Tower kernel: REISERFS error (device md7): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [4565 5072 0x0 SD] I am currently running in Maintenance mode and executed the following on the emulated disk: root@Tower:~# reiserfsck --fix-fixable /dev/md7 reiserfsck 3.6.24 Will check consistency of the filesystem on /dev/md7 and will fix what can be fixed without --rebuild-tree 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 --fix-fixable started at Wed Aug 12 12:25:46 2015 ########### Replaying journal: Done. Reiserfs journal '/dev/md7' in blocks [18..8211]: 0 transactions replayed My question while waiting on what will almost certainly be a tree rebuild... What should be the command to rebuild the tree on an emulated disk? Any gotchas? Thanks!

This was my experience also. Tried method 1 without success. Wrote syslinx to usb and run make_boot.bat and all came up.

"Support for Multiple File Systems" Lack of this feature and the problems with ReiserFS were the reasons I left unraid. Native dockers on a native COW FS out of the box has potential far beyond the SOHO NAS market. Thanks and keep up the communication.

CentOS or Debian.

Absolutely no problem. Give me a day or so.

Oh indeed, the script needs work, and I'm happy to clean it up. I was just looking for a quick one line hitter.

Thanks for your input. Sorry that happened, but it sounds like your outcome was similar to mine. The failure condition and the inability to troubleshoot the root cause is what is troubling me. I have asked for an official support ticket, but have not heard back on anything. To recap: I started with a system state of no (or virtually no) corrupt data. I know this because I can pull good data off the red balled drives. I followed the correct procedure per documentation for the system. The principle repair and reporting tool "reiserfsck" found no corruption after completion of the rebuild, however this was not true. As a result of following the correct procedure, data loss and corruption were introduced into the array. The recovery procedure put the array in a far worse situation. Without the "du" and "ls" mismatches, I would not have known about the corruption. This situation sets up a real possibility of a future catastrophic system failure occasioned by data loss. My suggestion would be to have a script that looks for this type of corruption. With this information, at least you would know that your system is unreliable. Thoughts?

memcheck ran 14 hours with no issues. Starting a parity check now.

So this is another wrinkle... These files on the old hard drives are NOT corrupt. I was able to pull everything off of the old two drives that unraid had red balled. The drives write and read fine mounted in a ubuntu box.

yes. root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# ls -lah total 8.6M drwxrwxrwx 3 nobody users 296 2013-10-13 04:48 ./ drwxrwxrwx 177 nobody users 7.4K 2013-10-30 08:22 ../ drwxrwxrwx 2 nobody users 600 2013-08-13 03:58 .actors/ -rw-rw-rw- 1 nobody users 110 2011-10-17 23:33 The\ Great\ Dictator\ (1940).dvdid.xml -rw-rw-rw- 1 nobody users 22K 2011-08-30 05:36 The\ Great\ Dictator\ (1940).jpg -rw-rw-rw- 1 nobody users 6.4G 2010-05-25 05:10 The\ Great\ Dictator\ (1940).mkv -rw-rw-rw- 1 nobody users 994K 2013-10-12 22:36 backdrop.jpg -rw-rw-rw- 1 nobody users 85K 2011-06-02 14:20 mymovies-front.jpg I have an ugly little script that will find my corrupt files: find . -size +1050M | du -hs * | grep M Basically, "find" will _find_ dirs bigger than a gig and du will then sort by MB. So, anything reported bigger than a GB by "find" but smaller than a GB by "du" will be reported.

I was only from a shell, so I could not test all of them. I just got home, and some of them are corrupt. :'( Some will play for a while and then crash. I have not done an wholesale test, but it's obvious that my array is not in a good state.

Thanks for looking at this! In the previous example, "ls" reports agg of 8.6M and "du" gives 14MB. I understand that subs are the difference, but there is a 6.4G ! file in the directory. "ls" reports the correct size of the individual files (but reports the agg incorrectly). "du" does not report correct size of individual files or the directory. root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# du -h ./"The Great Dictator (1940).mkv" 7.5M ./The Great Dictator (1940).mkv root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# The example below is from a correct listing on the same drive. "ls" gives a total of 11G and "du" gives a total of 11G - which are correct. root@Tower:/mnt/disk10/media/Movies/Twelve Monkeys (1995)# ls -lah total 11G drwxrwxrwx 6 nobody users 968 2013-10-13 06:19 ./ drwxrwxrwx 172 nobody users 7.2K 2013-10-30 12:46 ../ drwxrwxrwx 2 user1 users 72 2013-10-09 04:20 .AppleDouble/ drwxrwxrwx 2 nobody users 224 2012-10-04 04:37 .actors/ -rw-rw-rw- 1 nobody users 286K 2012-10-03 23:34 Twelve\ Monkeys\ (1995)-fanart.jpg -rw-rw-rw- 1 nobody users 106 2011-10-18 01:15 Twelve\ Monkeys\ (1995).dvdid.xml -rw-rw-rw- 1 nobody users 33K 2011-08-29 18:50 Twelve\ Monkeys\ (1995).jpg -rw-rw-rw- 1 nobody users 11G 2009-08-01 00:27 Twelve\ Monkeys\ (1995).mkv -rw-rw-rw- 1 nobody users 7.4K 2012-12-26 09:35 Twelve\ Monkeys\ (1995).nfo -rw-rw-rw- 1 nobody users 49K 2012-10-03 23:34 Twelve\ Monkeys\ (1995).tbn -rw-rw-rw- 1 nobody users 63K 2010-12-07 15:22 backdrop.jpg -rw-rw-rw- 1 nobody users 64K 2013-10-12 22:34 banner.jpg -rw-rw-rw- 1 nobody users 76K 2012-08-11 19:27 clearart.png -rw-rw-rw- 1 nobody users 538K 2012-08-11 19:27 disc.png drwxrwxrwx 2 nobody users 96 2012-08-11 19:26 extrafanart/ drwxrwxrwx 2 nobody users 48 2012-08-11 19:26 extrathumbs/ -rw-rw-rw- 1 nobody users 71K 2012-02-21 21:11 fanart.jpg -rw-rw-rw- 1 nobody users 35K 2011-10-18 01:17 folder.jpg -rw-rw-rw- 1 nobody users 51K 2012-08-11 19:26 logo.png -rw-rw-rw- 1 nobody users 143K 2012-02-21 21:11 movie.jpg -rw-rw-rw- 1 nobody users 7.5K 2013-08-14 19:46 movie.nfo -rw-rw-rw- 1 nobody users 143K 2012-02-21 21:11 movie.tbn -rw-rw-rw- 1 nobody users 8.4K 2013-10-12 22:33 movie.xml -rw-rw-rw- 1 nobody users 258K 2011-05-06 18:05 mymovies-back.jpg -rw-rw-rw- 1 nobody users 141K 2011-05-06 18:05 mymovies-front.jpg -rw-rw-rw- 1 nobody users 17K 2011-10-18 01:17 mymovies.xml -rw-rw-rw- 1 nobody users 104K 2010-12-07 15:22 poster.jpg -rw-rw-rw- 1 nobody users 194K 2013-10-12 22:34 thumb.jpg root@Tower:/mnt/disk10/media/Movies/Twelve Monkeys (1995)# du . -h 64K ./extrafanart 4.0K ./.AppleDouble 100K ./.actors 0 ./extrathumbs 11G . root@Tower:/mnt/disk10/media/Movies/Twelve Monkeys (1995)# Now, all of the recovered dirs from reiserfsck have this same issue. None of my other directories have this issue. This is troubling to me, but I'm not sure if it's a bug or a feature.

Thanks. That's one nice feature of ASUS AM3+ mb's - they all support ECC. About to pull the trigger on a FreeBSD ZFS box and AMD with ECC is so much cheaper than Intel.

USE AT YOUR OWN RISK! Take a look here: http://oreilly.com/openbook/samba/book/ch08_01.html 8.1.1.3 dos filetimes 8.1.1.4 dos filetime resolution 8.1.1.5 fake directory create times These are not set @ /etc/samba/smb.conf Not sure if you could set those, but it's a thought.

Reiserfsck came back fine # reiserfsck --check /dev/md10 reiserfsck 3.6.21 (2009 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to [email protected], ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will read-only check consistency of the filesystem on /dev/md10 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 Wed Oct 30 08:39:09 2013 ########### Replaying journal: Done. Reiserfs journal '/dev/md10' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 282304 Internal nodes 1762 Directories 801 Other files 6945 Data block pointers 285114925 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Wed Oct 30 09:23:47 2013 ########### root@Tower:/# However, I still get this not-so-comfortable report: root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# ls -lah total 8.6M drwxrwxrwx 3 nobody users 296 2013-10-13 04:48 ./ drwxrwxrwx 177 nobody users 7.4K 2013-10-30 08:22 ../ drwxrwxrwx 2 nobody users 600 2013-08-13 03:58 .actors/ -rw-rw-rw- 1 nobody users 110 2011-10-17 23:33 The\ Great\ Dictator\ (1940).dvdid.xml -rw-rw-rw- 1 nobody users 22K 2011-08-30 05:36 The\ Great\ Dictator\ (1940).jpg -rw-rw-rw- 1 nobody users 6.4G 2010-05-25 05:10 The\ Great\ Dictator\ (1940).mkv -rw-rw-rw- 1 nobody users 994K 2013-10-12 22:36 backdrop.jpg -rw-rw-rw- 1 nobody users 85K 2011-06-02 14:20 mymovies-front.jpg root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# du . -h 5.3M ./.actors 14M . root@Tower:/mnt/disk10/media/Movies/The Great Dictator (1940)# This just feels bad. Updated syslog: https://gist.github.com/anonymous/7233604

That's a good idea. I have not run memtest on the new rig. I think I'm going to get ECC RAM to replace it anyway. Should have done it from the start. Right now I have an additional issue. "du" does not report the correct sizes of directories with recovered files. "df" and "ls" agree, but "du" does not see the correct sizes of many of the recovered files. Running reiserfsck --check now.