Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Possible data loss

Featured Replies

Guys - this is not going to make a difference.

 

I certainly defer to your comment ... but just curious why this wouldn't work.

 

  • Replies 171
  • Views 21.7k
  • Created
  • Last Reply
  • Author

Question - do you have a backup of your Config file from a time when the system was configured with the current disks?

 

If so, why not try that?

 

I do have it. But when I I did it before.....unraid dissapears....I think the initial problem was in that folder.

Should I try???

Guys - this is not going to make a difference.

 

razr: from your email you say this is your config:

 

Parity  WDC_WD40EFRX-68WT0N0_WD-WCC4E0553678

Disk 1  ST3000DM001-9YN166_S1F0PQ9S

Disk 2  ST3000DM001-1CH166_Z1F1YREJ

Disk 3  WDC_WD20EARX-00PASB0_WD-WCAZAC998124

And a cache drive.

 

This is the config you had before the trouble began, correct?

 

That is correct

I would. Not the go file or network cfg, just the disk config file.

I think the critical file in all this is super.dat

 

Too many cooks in the kitchen. I will just listen from outside the window now.

I would. Not the go file or network cfg, just the disk config file.

I think the critical file in all this is super.dat

 

Too many cooks in the kitchen. I will just listen from outside the window now.

 

I'm 'lurking' too but had to contribute when the option to boot into 'safe' mode was suggested ... i do NOT have it either.

I would. Not the go file or network cfg, just the disk config file.

I think the critical file in all this is super.dat

 

Too many cooks in the kitchen. I will just listen from outside the window now.

 

I'm 'lurking' too but had to contribute when the option to boot into 'safe' mode was suggested ... i do NOT have it either.

syslinux was changed and if you did not replace it then you would not have gotten the new menu options. Probably a good idea to replace it when convenient. You will have to run make_bootable again.
  • Author

talking about make_bootable...With this new flash created just now I did not run it....should I have????

talking about make_bootable...With this new flash created just now I did not run it....should I have????

No.

 

But before we go off repairing the file system, please post your system log.  You can go to Utilities/System Log, then select/copy/paste into reply.

talking about make_bootable...With this new flash created just now I did not run it....should I have????

If it booted and gave you safe mode then I must be wrong about needing to run it.

[syslinux was changed and if you did not replace it then you would not have gotten the new menu options. Probably a good idea to replace it when convenient. You will have to run make_bootable again.

 

I'll pick this one up later to allow you to get on with razr's problems, thanks.

Guys - this is not going to make a difference.

 

I certainly defer to your comment ... but just curious why this wouldn't work.

 

The 'super.dat' file stores two vital pieces of data:

1. Which device, by model and serial number, is assigned to which 'slot', that is, it stores what model/sn is assigned to parity, disk1, disk2, etc.

2. Which device, if any, is currently "invalid" and/or "disabled".  This information is used to determine if array parity is valid, and if so, if any disk is disabled, or in the process of being reconstructed.  This is why it's critical to keep the flash plugged in because this info must be updated synchronous with disabling a disk due to write failure (so that a subsequent read does not try to read the disk that just got disabled).

 

In razr's situation we already know what the disk assignments are and which disk is not "valid".

Okay, thanks.  Doesn't sound promising for razr's issue, but hopefully you can work some "magic" for him  :)

 

... Meanwhile ...

Too many cooks in the kitchen.

 

Definitely agree -- and the Chief Chef is already here, so I'm just going to watch while Tom prepares the meal  :)

 

Too long to paste....see attached.

Hmm, well there are errors being reported by Disk 2 - a 3TB Seagate (Z1F1YREJ).  The type of error is usually associated with some kind non-media problem, such as bad cable, bad cable connection, bad disk controller port.  If you browse the disk2 share on your network, do you see your files?  This makes things a bit trickier because there are potentially 2 disks failing.  Have there been any changes to your h/w (other than adding the 4TB drive) lately?

 

Sorry if this is a laborious process... trying to minimize data loss.

 

Just prior to me chiming in here, in the configuration where all disks were assigned in the array but disk 1 showed 'unformatted', did you ever run a parity check and/or parity sync with this configuration?

  • Author

Too long to paste....see attached.

Hmm, well there are errors being reported by Disk 2 - a 3TB Seagate (Z1F1YREJ).  The type of error is usually associated with some kind non-media problem, such as bad cable, bad cable connection, bad disk controller port.  If you browse the disk2 share on your network, do you see your files?  This makes things a bit trickier because there are potentially 2 disks failing.  Have there been any changes to your h/w (other than adding the 4TB drive) lately?

 

Just prior to me chiming in here, in the configuration where all disks were assigned in the array but disk 1 showed 'unformatted', did you ever run a parity check and/or parity sync with this configuration?

 

 

I know it takes time, and I really thank you for spending your time with me.

I took the array out of maint mode and yes, I can navigate to disk2 \\tower\disk2 and see files there

No other changes...other than I booted with the other USB yesterday or two days ago..

Yes. When I booted yesterday with the disk showing unformatted, unraid started parity by itself, I stopped it right away, and there were a lot of errors....se pic attached

Untitled.png.f2c4271ad2e156e0df5c38402ca181b2.png

Too long to paste....see attached.

Hmm, well there are errors being reported by Disk 2 - a 3TB Seagate (Z1F1YREJ).  The type of error is usually associated with some kind non-media problem, such as bad cable, bad cable connection, bad disk controller port.  If you browse the disk2 share on your network, do you see your files?  This makes things a bit trickier because there are potentially 2 disks failing.  Have there been any changes to your h/w (other than adding the 4TB drive) lately?

 

Just prior to me chiming in here, in the configuration where all disks were assigned in the array but disk 1 showed 'unformatted', did you ever run a parity check and/or parity sync with this configuration?

 

 

I know it takes time, and I really thank you for spending your time with me.

I took the array out of maint mode and yes, I can navigate to disk2 \\tower\disk2 and see files there

No other changes...other than I booted with the other USB yesterday or two days ago..

Yes. When I booted yesterday with the disk showing unformatted, unraid started parity by itself, I stopped it right away, and there were a lot of errors....se pic attached

 

In studying that last image I'm thinking this is what happened.  Aside from the original issue, probably when you booted the spare flash with old config, it clobbered your disk1 (because it thought it was parity).  Then later you were able to restore the original config but in the process a correcting-parity sync started, now clobbering your real parity disk (that is, it updated parity with the bad data now on disk1).  What I was trying to determine is whether array parity is valid in case we have to rebuild disk2, but it appears your parity is invalid anyway.  So keep your fingers crossed that disk2 doesn't decide to fail completely any time soon.

 

Back to disk1 - you should be in a state where disk1 is still unassigned, right?  And that the unassigned device is "sdc", right?

 

If above true, then let's go ahead and see what magic reiserfsck can come up with.  Type this command:

 

reiserfsck --rebuild-sb /dev/sdc1

 

This might take a while to execute depending on how many files were in the file system.

  • Author

I get this..

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

 

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, choose 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

 

  • Author

should i have the array in maintenance mode?

should i have the array in maintenance mode?

That won't matter since the device (sdc) is not assigned in the array.

 

You want to select option 1

  • Author

 

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, choose 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]:

 

Here are the values I used long ago. Maybe Tom can just confirm them in one fowl swoop and let you do your thing ...

 

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

 

  • Author

What do I type now?

  • Author

Here are the values I used long ago. Maybe Tom can just confirm them in one fowl swoop and let you do your thing ...

 

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

 

I dont know if I should do as you did.... Lets see what Tom says

  • Author

1

 

Enter block size [4096]:

default

rebuild_sb: wrong block size specified

 

root@Tower:~#

 

What do I do?

 

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.