May 18, 201412 yr Hi All, Just need some assistance in rebuilding for reiserf on md1. Running unraid 6.0-beta5a, but was having issues before this root@Tower:~# reiserfsck --check /dev/sdb1 reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/sdb1 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 Sun May 18 14:53:43 2014 ########### Replaying journal: Trans replayed: mountid 111, transid 644393, desc 6891, len 1, commit 6893, next trans offset 6876 Trans replayed: mountid 111, transid 644394, desc 6894, len 1, commit 6896, next trans offset 6879 Replaying journal: Done. Reiserfs journal '/dev/sdb1' in blocks [18..8211]: 2 transactions replayed Checking internal tree.. \/ 14 (of 31|/ 28 (of 88-/ 40 (of 86-block 176397927: The level of the node (13873) is not correct, (1) expected the problem in the internal node occured (176397927), whole subtree is skipped finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Sun May 18 15:32:21 2014 ########### root@Tower:~#
May 18, 201412 yr Author Also noticed this error in the logfile. May 18 12:04:02 Tower kernel: [mem 0x00000000-0x000fffff] page 4k (Errors) May 18 12:04:02 Tower kernel: BRK [0x01805000, 0x01805fff] PGTABLE May 18 12:04:02 Tower kernel: BRK [0x01806000, 0x01806fff] PGTABLE May 18 12:04:02 Tower kernel: BRK [0x01807000, 0x01807fff] PGTABLE May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x21f400000-0x21f5fffff] May 18 12:04:02 Tower kernel: [mem 0x21f400000-0x21f5fffff] page 2M (Errors) May 18 12:04:02 Tower kernel: BRK [0x01808000, 0x01808fff] PGTABLE May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x21c000000-0x21f3fffff] May 18 12:04:02 Tower kernel: [mem 0x21c000000-0x21f3fffff] page 2M (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x200000000-0x21bffffff] May 18 12:04:02 Tower kernel: [mem 0x200000000-0x21bffffff] page 2M (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x00100000-0x1fffffff] May 18 12:04:02 Tower kernel: [mem 0x00100000-0x001fffff] page 4k (Errors) May 18 12:04:02 Tower kernel: [mem 0x00200000-0x1fffffff] page 2M (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x20200000-0x40003fff] May 18 12:04:02 Tower kernel: [mem 0x20200000-0x3fffffff] page 2M (Errors) May 18 12:04:02 Tower kernel: [mem 0x40000000-0x40003fff] page 4k (Errors) May 18 12:04:02 Tower kernel: BRK [0x01809000, 0x01809fff] PGTABLE May 18 12:04:02 Tower kernel: BRK [0x0180a000, 0x0180afff] PGTABLE May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x40005000-0xd936efff] May 18 12:04:02 Tower kernel: [mem 0x40005000-0x401fffff] page 4k (Errors) May 18 12:04:02 Tower kernel: [mem 0x40200000-0xd91fffff] page 2M (Errors) May 18 12:04:02 Tower kernel: [mem 0xd9200000-0xd936efff] page 4k (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0xda309000-0xda309fff] May 18 12:04:02 Tower kernel: [mem 0xda309000-0xda309fff] page 4k (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0xda34d000-0xdac94fff] May 18 12:04:02 Tower kernel: [mem 0xda34d000-0xda3fffff] page 4k (Errors) May 18 12:04:02 Tower kernel: [mem 0xda400000-0xdabfffff] page 2M (Errors) May 18 12:04:02 Tower kernel: [mem 0xdac00000-0xdac94fff] page 4k (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0xdafdd000-0xdaffffff] May 18 12:04:02 Tower kernel: [mem 0xdafdd000-0xdaffffff] page 4k (Errors) May 18 12:04:02 Tower kernel: init_memory_mapping: [mem 0x100000000-0x1ffffffff] May 18 12:04:02 Tower kernel: [mem 0x100000000-0x1ffffffff] page 2M (Errors) syslog-2014-05-18.txt
May 18, 201412 yr From the log, clearly your movies and PLEX data are on a disk that needs repair. run: reiserfsck --rebuild-tree /dev/sdb1 (Be sure that's the right disk...if you restart unRAID, the disk assignments may change). 1. As a check, you might want to run: reiserfsck --check /dev/sdXX on all your data disks (not Parity...there is no file system on Parity) and replace XX with the disks. 2. Check your PLUGIN versions...make sure you're running plugins that are the latest AND are the Version 6 compatible versions.
May 18, 201412 yr Why on the /dev/sdX device and not on the /dev/md# device? Writes to the physical device will corrupt parity.
May 18, 201412 yr Why on the /dev/sdX device and not on the /dev/md# device? Writes to the physical device will corrupt parity. Ooo... I should have been more thoughtful...I too quickly copied and pasted from the first post.
May 21, 201412 yr Author Thanks for the help, I was aware on how to do the rebuild command itself, but it seems there are very specific questions that will come up once it starts. I was more looking at the correct input at this stage?
May 21, 201412 yr Author See Check Disk Filesystems in my sig. Hi dgaschk, I have previously read that and it recommends that we ask for guiadance before running it. Are these still the correct answers for unraid 6? 1. The version of reiserfs is 3.6.x. This is for unRAID 4.2.1. (This is NOT the default, so be careful) 2. Block size is 4096 (default) 3. “No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified)” Is journal default?” (Answer Y) 4. “Do you use resizer?” (Answer N) 5. It tells you that a new uuid has been generated. 6. “rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header?” Answer Y 7. The following info is displayed: Reiserfs super block in block 16 on 0x901 of format 3.6 with standard journal Count of blocks on the device: 73264320 Number of bitmaps: 2236 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: <my UUID removed> LABEL: Set flags in SB: Is this ok ? (y/n)[n]: 8. Answer “Y”. 9. With amazing speed the program does its thing and ends And then do I do this part? “reiserfsck –scan-whole-partition –rebuild-tree /dev/md1”. (UPDATE 8/8/11: If you ever run on on an OS level device rather than an unRAID device, make sure to use the first partition - ie., “reiserfsck /dev/sdc1", and not the disk level device.) Also can I confirm whether it should be md1 or sdb1 etc?
May 21, 201412 yr Also can I confirm whether it should be md1 or sdb1 etc? You should always use md1 if at all possible. This will maintain parity, and it also allows the reiserfsck to be run against a simulated device rather than a physical device. Note that if you are doing this on a drive that has been 'red-balled' then you are using the logical device rather than the physical one. You can even remove the physical device and the reiserfsck will run ok. This can be useful if you want to see the results before rebuilding the red-balled drive. If you use sdb1 then you immediately invalidate your parity (which might have consequences if you need to rebuild different drive), and also you can only run this against a real physical device.
May 21, 201412 yr Don't confused checking a file system with rebuilding the drive tree. They are both options on the reiserfsck command but do very different things! One other point, using the sdX vs mdx designator does have an impact on whether parity is maintained. There are sometimes good reasons to NOT maintain parity, but often you DO want parity maintained. But the statement that the mdX runs against a simulated disk isn't always true. If the disk is recognized as in the array mdX will refer to it. If it has a red ball (and the array is started) it will refer to the simulated disk. You can get into some confusing scenarios. Just make sure that you understand each step you are asked to do, the reason to do it, the risks, alternatives, and that ultimately you make the decision to do it. There are a lot of helpful people here which is great. But at the end of the day it is your data and you need to stay in control. If anyone can't explain why to do something hold off until someone can. Recovery from problems and avoiding data loss is often straightforward if you follow the right steps, but doing the wrong things can make things so much worse!
May 29, 201412 yr Author Did the rebuild yesterday, and was actually really easy. All sorted now with very little data loss.
Archived
This topic is now archived and is closed to further replies.