ReiserFS superblock cannot be found

[AeroSteveO]

i was going to backup steam games to my unraid server, set the folder to coincide in my servers backup folders, when i tried to start it, however, the backup failed, with an error, after that all network drives mapped to my server crashed, unable to load, however my vm drive maintained with no issues (its not included in the array). i pulled up the syslog before rebooting it, thinking that would help, however that did nothing, when i went into the webui to look at my shares, the webui showed no samba shares, nothing else seemed out of the ordinary. i tried running reiserfsck on the drives, all i get is the following, for each of my 6 drives in the array

 

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

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.

 

i tried running --fix-fixable, however that runs into the same problem with the superblock not being found, any help would be greatly appreciated, it would be nice to not lose every data drive i have on my server

 

EDIT: i'm running unraid 5.0RC11

transport_endpoint5.txt

[Joe L.]

You are probably not running the reiserfsck on the correct partition on each disk, therefore, since you are not pointing it to where the superblock actually resides, it cannot find it.  (Hint... it must be run on the 1st partition)

 

Please give the EXACT reiserfsck command you are attempting.

 

Joe L.

[AeroSteveO]

So i was running the command on the wrong partition, now i'm running it properly

reiserfsck --check /dev/sda1

[itimpi]

So i was running the command on the wrong partition, now i'm running it properly

reiserfsck --check /dev/sda1

Note that doing that will invalidate parity (if you have it).  If you want parity to be maintained the you should start the array in maintenance mode and run against the /dev/md* style names (e.g. /dev/md1). 

 

When using md style device names you do not need to worry about the partition as they are automatically linked to partition 1.  Also the numeric part corresponds to the disk number in the unraid GUI so it is easier to be sure you are doing the right disk.

[AeroSteveO]

first disk finished the check

No corruptions found

There are on the filesystem:

        Leaves 581902

        Internal nodes 3482

        Directories 470

        Other files 7453

        Data block pointers 588028598 (815021 of them are zero)

        Safe links 0

on the next i'll use the /dev/mdx instead of /dev/sdx, thanks for that pointer itimpi

[dgaschk]

The issue has been fixed in 5.0 final.

[AeroSteveO]

I think the issue is arising from file name limits in unraid, as the steam backup tried to create a folder with every name of every game inside it, when replicating this onto a usb hdd in windows, the folder name was 255 characters long before the backup crashed, i think removing these folders somehow will fix the problem

 

The issue has been fixed in 5.0 final.

 

i'd like to have my server running with all the shares intact before updating to 5.0 final

 

EDIT: fixed the issues i had, removing the poorly named folders allowed me to regain access

 

[dgaschk]

There is no path name limitation. The limit only applies to an actual file or folder name. E.g. </mnt/user/name that is 254 chars long/name that is 254 chars log/> is ok.

 

The exact error "Transport endpoint is not connected" has been specifically address and fixed in version 5 final. It is a known bug mentioned in the change log.

[AeroSteveO]

I will update to 5.0 final as well then, for stability and to avoid this error in the future, thank you for the help