Jump to content

33 posts in this topic Last Reply

Recommended Posts

Posted (edited)

Hello. After many years of zero problems, I'm finally posting due to an issue I can't seem to get myself out of.

I was trying to Upgrade my parity...5TB to 6TB. The rebuild was going super slow...less than 5MB/s. I figured out it was something funky with a Sata card/cable.

While trying to figure out that issue, I resorted to skipping the upgrade, going back to my original 5TB parity.

I think in my haste, I somehow messed with disk10. Now, I can access my files, but cannot reassign disk10 as it only shows up as 'unformatted'. I've been running around in circles getting nowhere. I even went out and purchased a new disk hoping it was disk related and that it would rebuild. No such luck.

I finally went with the 'New Config' option, but that hasn't helped either. The system is in the process of a parity-sync after the New Config. Disk10 still unformatted.

There's nothing wrong with the disk, the cable, the sata card. I've troublshot all those.

I'm sure I'm not giving enough info.

Anyone able/willing to try to help a brother out?

unraid_unformatted_disk.thumb.jpg.85b2e8fd4ae3df757ce185b0a3720578.jpg

 

Thanks in advance.

unraid_syslog.txt

Edited by zOnk
syslog

Share this post


Link to post

You need to check the filesystem on that disk. I don't remember the procedure off the top of my head for 7 year old software, I think the wiki has an entry with the procedure.

Share this post


Link to post

You have connection issues on disks 7,8, which will likely affect your parity rebuild. After you take care of that and get parity rebuilt, you can try to deal with the filesystem on disk10.

 

https://wiki.unraid.net/Check_Disk_Filesystems

 

Please upgrade after you get your system stable again. Most of us barely remember the version you are running.

Share this post


Link to post

Thanks for the quick replies.
*I would have upgraded long ago...but not having a 64bit setup laying around has kept me where I'm at. Plus...never had any issues til now. It's on the todo list tho.

Share this post


Link to post
17 hours ago, zOnk said:

Thanks for the quick replies.
*I would have upgraded long ago...but not having a 64bit setup laying around has kept me where I'm at. Plus...never had any issues til now. It's on the todo list tho.

Maybe I am missing something - from your log you are running an Intel Core 2 Duo E7200. 

 

This suggests that your hardware should be 64 bit capable already...

 

https://ark.intel.com/content/www/us/en/ark/products/35348/intel-core-2-duo-processor-e7200-3m-cache-2-53-ghz-1066-mhz-fsb.html

 

Share this post


Link to post

Dude...no way?! For real? I honestly don't even know what hardware is in that old ass machine...I just figured it's so old there's no way it can be 64 bit. Does the motherboard matter tho? (sorry to sound so IT ignorant, but...at times, I am).

At this point I'm 65% through the parity-sync and 0 errors. Fingers still crossed.

Share this post


Link to post
23 minutes ago, zOnk said:

Does the motherboard matter tho?

Nope.  It's all purely based upon the CPU

Share this post


Link to post

Ok...good news (for me) parity-sync finished without any issues/errors.
Started the array in maintenance mode and ran: reiserfsck --check /dev/md10

Got this:
reiserfsck 3.6.24

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

reiserfs_open: the reiserfs superblock cannot be found on /dev/md10.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

root@Tower:~#

Since the Wiki recommends talking to experts first, I'm posting this and gonna wait to hear back before moving forward.

Share this post


Link to post

Ok...ran reiserfsck --rebuild-sb /dev/md10 and followed the directions in Wiki. Got all the way to the bottom, but instead of what the wiki shows, I see this:

 

Set flags in SB:

Mount count: 1

Maximum mount count: 30

Last fsck run: Mon Sep 2 10:19:35 2019

Check interval in days: 180

Is this ok ? (y/n)[n]:

 

I got the above instead of the (y/n) prompt after Set flags in SB:

 

Here's the whole line by line, just in case:

 

root@Tower:~#  reiserfsck --rebuild-sb /dev/md10
reiserfsck 3.6.24

Will check superblock and rebuild it if needed
Will put log info to 'stdout'

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

reiserfs_open: the reiserfs superblock cannot be found on /dev/md10.

what the version of ReiserFS do you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, ch
oose this one)
        (3) < 3.5.9 converted to new format (don't choose if unsure)
        (4) < 3.5.9 (this is very old format, don't choose if unsure)
        (X)   exit
1

Enter block size [4096]:
4096

No journal device was specified. (If journal is not available, re-run with --no-
journal-available option specified).
Is journal default? (y/n)[y]: y

Did you use resizer(y/n)[n]: n
rebuild-sb: no uuid found, a new uuid was generated (d309e289-04e3-4cca-8a56-31f
51d62fe67)

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? (y/n)[n]: y
Reiserfs super block in block 16 on 0x90a of format 3.6 with standard journal
Count of blocks on the device: 488378624
Number of bitmaps: 14905
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: d309e289-04e3-4cca-8a56-31f51d62fe67
LABEL:
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Mon Sep  2 10:19:35 2019
Check interval in days: 180
Is this ok ? (y/n)[n]:

Edited by zOnk
added entire process

Share this post


Link to post

Ok...did it. Here's what I got:

 

Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.

root@Tower:~# reiserfsck --check /dev/md10
reiserfsck 3.6.24

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 Mon Sep  2 11:11:27 2019
###########
Replaying journal: No transactions found
Zero bit found in on-disk bitmap after the last valid bit.
Checking internal tree..

Bad root block 0. (--rebuild-tree did not complete)

Aborted (core dumped)
root@Tower:~#

Share this post


Link to post

Maybe a stupid question, but since it shows parity is valid and I have a 4TB disk that isn't in the array. Can I just replace this md10 (2TB) disk with this new 4TB?

Share this post


Link to post

Rebuilding from your newly built parity would rebuild the data disk exactly as it is now. Parity is valid because it is consistent with the bit-by-bit contents of all the other disks. Parity knows absolutely nothing about filesystems. Each disk is just a bunch of bits.

 

Rebuilding from parity is never the way to repair filesystems.

Share this post


Link to post
12 hours ago, zOnk said:

Bad root block 0. (--rebuild-tree did not complete)

Like mentioned:

On 9/2/2019 at 7:23 AM, johnnie.black said:

likely will need --rebuild-tree after.

 

Share this post


Link to post

Ok. ran the --rebuild-tree. Here's the result:

 

Tower login: root
Linux 3.9.11p-unRAID.
root@Tower:~# reiserfsck --rebuild-tree /dev/md10
reiserfsck 3.6.24

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **
** something is broken and MAKE A BACKUP  before using it. **
** If you have bad sectors on a drive  it is usually a bad **
** idea to continue using it. Then you probably should get **
** a working hard drive, copy the file system from the bad **
** drive  to the good one -- dd_rescue is  a good tool for **
** that -- and only then run this program.                 **
*************************************************************

Will rebuild the filesystem (/dev/md10) 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
Replaying journal: No transactions found
Zero bit found in on-disk bitmap after the last valid bit. Fixed.
###########
reiserfsck --rebuild-tree started at Thu Sep  5 17:59:49 2019
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 456426578 blocks marked used
init_source_bitmap: Bitmap 2009 (of 32768 bits) is wrong - mark all blocks [6583
0912 - 65863680] as used
init_source_bitmap: Bitmap 2010 (of 32768 bits) is wrong - mark all blocks [6586
3680 - 65896448] as used
init_source_bitmap: Bitmap 2011 (of 32768 bits) is wrong - mark all blocks [6589
6448 - 65929216] as used
init_source_bitmap: Bitmap 2012 (of 32768 bits) is wrong - mark all blocks [6592
9216 - 65961984] as used
init_source_bitmap: Bitmap 2013 (of 32768 bits) is wrong - mark all blocks [6596
1984 - 65994752] as used
init_source_bitmap: Bitmap 2014 (of 32768 bits) is wrong - mark all blocks [6599
4752 - 66027520] as used
init_source_bitmap: Bitmap 2015 (of 32768 bits) is wrong - mark all blocks [6602
7520 - 66060288] as used
init_source_bitmap: Bitmap 2016 (of 32768 bits) is wrong - mark all blocks [6606
0288 - 66093056] as used
init_source_bitmap: Bitmap 2017 (of 32768 bits) is wrong - mark all blocks [6609
3056 - 66125824] as used
init_source_bitmap: Bitmap 2018 (of 32768 bits) is wrong - mark all blocks [6612
5824 - 66158592] as used
init_source_bitmap: Bitmap 2019 (of 32768 bits) is wrong - mark all blocks [6615
8592 - 66191360] as used
init_source_bitmap: Bitmap 2020 (of 32768 bits) is wrong - mark all blocks [6619
1360 - 66224128] as used
init_source_bitmap: Bitmap 2021 (of 32768 bits) is wrong - mark all blocks [6622
4128 - 66256896] as used
init_source_bitmap: Bitmap 2022 (of 32768 bits) is wrong - mark all blocks [6625
6896 - 66289664] as used
init_source_bitmap: Bitmap 4736 (of 32768 bits) is wrong - mark all blocks [1551
89248 - 155222016] as used
init_source_bitmap: Bitmap 4737 (of 32768 bits) is wrong - mark all blocks [1552
22016 - 155254784] as used
init_source_bitmap: Bitmap 4738 (of 32768 bits) is wrong - mark all blocks [1552
54784 - 155287552] as used
init_source_bitmap: Bitmap 4739 (of 32768 bits) is wrong - mark all blocks [1552
87552 - 155320320] as used
init_source_bitmap: Bitmap 4740 (of 32768 bits) is wrong - mark all blocks [1553
20320 - 155353088] as used
init_source_bitmap: Bitmap 4741 (of 32768 bits) is wrong - mark all blocks [1553
53088 - 155385856] as used
init_source_bitmap: Bitmap 4742 (of 32768 bits) is wrong - mark all blocks [1553
85856 - 155418624] as used
init_source_bitmap: Bitmap 4743 (of 32768 bits) is wrong - mark all blocks [1554
18624 - 155451392] as used
init_source_bitmap: Bitmap 4744 (of 32768 bits) is wrong - mark all blocks [1554
51392 - 155484160] as used
init_source_bitmap: Bitmap 4745 (of 32768 bits) is wrong - mark all blocks [1554
84160 - 155516928] as used
init_source_bitmap: Bitmap 4746 (of 32768 bits) is wrong - mark all blocks [1555
16928 - 155549696] as used
init_source_bitmap: Bitmap 4747 (of 32768 bits) is wrong - mark all blocks [1555
49696 - 155582464] as used
init_source_bitmap: Bitmap 4748 (of 32768 bits) is wrong - mark all blocks [1555
82464 - 155615232] as used
init_source_bitmap: Bitmap 4749 (of 32768 bits) is wrong - mark all blocks [1556
15232 - 155648000] as used
init_source_bitmap: Bitmap 4750 (of 32768 bits) is wrong - mark all blocks [1556
48000 - 155680768] as used
init_source_bitmap: Bitmap 4751 (of 32768 bits) is wrong - mark all blocks [1556
80768 - 155713536] as used
init_source_bitmap: Bitmap 4752 (of 32768 bits) is wrong - mark all blocks [1557
13536 - 155746304] as used
init_source_bitmap: Bitmap 4753 (of 32768 bits) is wrong - mark all blocks [1557
46304 - 155779072] as used
init_source_bitmap: Bitmap 4824 (of 32768 bits) is wrong - mark all blocks [1580
72832 - 158105600] as used
init_source_bitmap: Bitmap 4825 (of 32768 bits) is wrong - mark all blocks [1581
05600 - 158138368] as used
init_source_bitmap: Bitmap 4826 (of 32768 bits) is wrong - mark all blocks [1581
38368 - 158171136] as used
init_source_bitmap: Bitmap 4827 (of 32768 bits) is wrong - mark all blocks [1581
71136 - 158203904] as used
init_source_bitmap: Bitmap 4828 (of 32768 bits) is wrong - mark all blocks [1582
03904 - 158236672] as used
init_source_bitmap: Bitmap 4829 (of 32768 bits) is wrong - mark all blocks [1582
36672 - 158269440] as used
init_source_bitmap: Bitmap 4830 (of 32768 bits) is wrong - mark all blocks [1582
69440 - 158302208] as used
init_source_bitmap: Bitmap 4831 (of 32768 bits) is wrong - mark all blocks [1583
02208 - 158334976] as used
init_source_bitmap: Bitmap 4832 (of 32768 bits) is wrong - mark all blocks [1583
34976 - 158367744] as used
Skipping 23115 blocks (super block, journal, bitmaps) 457595811 blocks will be r
ead
0%..                                                   left 414643572, 32343 /se
block 311144394: The number of items (5135) is incorrect, should be (1) - correc
ted
block 311144394: The free space (1024) is incorrect, should be (3792) - correcte
d
pass0: vpf-10110: block 311144394, item (0): Unknown item type found [4229627906
 436217958 0xd70040f1 ??? (15)] - deleted
                                                          left 0, 25316 /secc
Could not find a hash in use. Using "r5"
Selected hash ("r5") does not match to the hash set in the super block (not set)
.
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 457595811
                Leaves among those 1
                        - leaves all contents of which could not be saved and de
leted 1
                Objectids found 2

Pass 1 (will try to insert 0 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished

Flushing..finished
        0 leaves read
                0 inserted
####### Pass 2 #######
Flushing..finished


No reiserfs metadata found.  If you are sure that you had the reiserfs
on this partition,  then the start  of the partition  might be changed
or all data were wiped out. The start of the partition may get changed
by a partitioner  if you have used one.  Then you probably rebuilt the
superblock as there was no one.  Zero the block at 64K offset from the
start of the partition (a new super block you have just built) and try
to move the start of the partition a few cylinders aside  and check if
debugreiserfs /dev/xxx detects a reiserfs super block. If it does this
is likely to be the right super block version.

Aborted (core dumped)
root@Tower:~#

 

What is recommended? I read the above debugreiserfs /dev/xxx but want to make sure before I proceed.

Thanks in advance.

Share this post


Link to post

Can't see how the start of the partition could have changed, Unraid can use two different starting sectors, unaligned or 4k aligned, but whatever partition existed would be used, are you sure the disk was never cleared or assigned as parity? Mostly out of curiosity post the output of:

 

fdisk -l /dev/sdX

 

for disk12 and a couple others, like disk1 and disk3, replace X with correct letters.

Share this post


Link to post

Here's the output (figured out 'sd' needed to be 'md'):

 


Tower login: root
Linux 3.9.11p-unRAID.
root@Tower:~# fdisk -l /dev/sd10
root@Tower:~# fdisk -l /dev/sd1
root@Tower:~# fdisk -l /dev/sd2
root@Tower:~# fdisk -l /dev/md10

Disk /dev/md10: 2000.4 GB, 2000398901248 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md10 doesn't contain a valid partition table
root@Tower:~# fdisk -l /dev/md1

Disk /dev/md1: 2000.4 GB, 2000398901248 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table
root@Tower:~# fdisk -l /dev/md2

Disk /dev/md2: 4000.8 GB, 4000786976768 bytes
255 heads, 63 sectors/track, 486401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md2 doesn't contain a valid partition table
root@Tower:~# fdisk -l /dev/md3

Disk /dev/md3: 1500.3 GB, 1500301877248 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md3 doesn't contain a valid partition table
root@Tower:~# fdisk -l /dev/md4

Disk /dev/md4: 1500.3 GB, 1500301877248 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md4 doesn't contain a valid partition table
root@Tower:~# fdisk -l /dev/md5

Disk /dev/md5: 2000.4 GB, 2000398901248 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md5 doesn't contain a valid partition table
root@Tower:~#

Share this post


Link to post

I think you will find that it SHOULD have been sdX where x is the letter corresponding to a particular drive as shown on the Main tab.    The mdX devices are looking at a specific partition, not the actual physical drive.

Share this post


Link to post

My bad. I never noticed those (sdX) labels.


Tower login: root
Linux 3.9.11p-unRAID.

root@Tower:~# fdisk -l /dev/sdk

Disk /dev/sdk: 2000.4 GB, 2000398934016 bytes
1 heads, 63 sectors/track, 62016336 cylinders
Units = cylinders of 63 * 512 = 32256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdk1               2    62016336  1953514552   83  Linux
Partition 1 does not end on cylinder boundary.
root@Tower:~# fdisk -l /dev/sdg

WARNING: GPT (GUID Partition Table) detected on '/dev/sdg'! The util fdisk doesn
't support GPT. Use GNU Parted.


Disk /dev/sdg: 5001.0 GB, 5000981078016 bytes
256 heads, 63 sectors/track, 605626 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1               1      266306  2147483647+  ee  GPT
Partition 1 does not start on physical sector boundary.
root@Tower:~# fdisk -l /dev/sdi

WARNING: GPT (GUID Partition Table) detected on '/dev/sdi'! The util fdisk doesn
't support GPT. Use GNU Parted.


Disk /dev/sdi: 2000.4 GB, 2000398934016 bytes
1 heads, 63 sectors/track, 62016336 cylinders
Units = cylinders of 63 * 512 = 32256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1               2    62016336  1953514552+  83  Linux
Partition 1 does not end on cylinder boundary.
root@Tower:~# fdisk -l /dev/sda

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn
't support GPT. Use GNU Parted.


Disk /dev/sda: 4000.8 GB, 4000787030016 bytes
256 heads, 63 sectors/track, 484501 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      266306  2147483647+  ee  GPT
Partition 1 does not start on physical sector boundary.
root@Tower:~# fdisk -l /dev/sdd

Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes
1 heads, 63 sectors/track, 46512336 cylinders
Units = cylinders of 63 * 512 = 32256 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               2    46512336  1465138552+  83  Linux
Partition 1 does not end on cylinder boundary.
root@Tower:~#

Share this post


Link to post

Those values are very weird, maybe because using old fdisk, that's one of the reasons it's a bad idea to stick with an old release, very difficult for us to help.

Share this post


Link to post

What sucks is that I can't just copy the files off that disk. It's inaccessible (I'm sure that's known by you guys), but I don't seem to be missing any files when I fire up UnRaid. 

If this is a dead end, what is possible? Is starting the disk as a new disk (lose all data on it) an option? I'm currently running DirLister to make a txt file of all the files on the user share that Disk10 (the bad one) is part of. Then, at least, if I lose all the data on disk10, I have a list to check.

Again, thanks in advance for taking the time to help me out.

Share this post


Link to post
15 hours ago, zOnk.oNe said:

but I don't seem to be missing any files when I fire up UnRaid. 

That's only possible if that disk was never in use, i.e. never formatted, which is a strong possibility based on the --rebuild-tree results.

 

15 hours ago, zOnk.oNe said:

all the files on the user share that Disk10

If you have an user share disk10 it's a folder on other disks.

Share this post


Link to post
19 hours ago, zOnk.oNe said:

I'm currently running DirLister to make a txt file of all the files on the user share that Disk10 (the bad one) is part of. Then, at least, if I lose all the data on disk10, I have a list to check.

Not sure I know what your mean here. If you now get the directories of all user shares that included disk 10, they won't include anything that was on disk10 since it isn't accessible.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.