yes, that's to be expected...i've already had a lost+found folder on it before i did all this...so there'll just be more of it, i guess...i'm going to have to keep an eye on this disk...even though it's only a few months old it seems to be giving me problems...we'll see.

ah, it was the telnet session that dis-allowed it...i had to exit from that session and now it stopped the array.

If the current directory is /mnt/something then that is what will happen.

makes sense...another lesson learned.

 

it's now at Pass 3 of rebuilding the tree, restoring a few HD movies it found...not sure whether this is really lost data, per-se, but i'll just let it finish its thing and then move on to finally re-sync (and correct, if necessary) parity, so that i can have a protected array again...what a trip it's been!

Although it could be a good idea to check parity it is probably not necessary as the disk has just been rebuilt using the other disks and parity anyway.  You would only get a parity error corrected if one of the writes to the rebuilt disk was not read back correctly.

bam, it finally finished! will have to take a peek now what has changed, but i already started the array back up into regular mode and did the newperm you suggested...after i evaluate what was found and what is still needed, i'll attempt to do another delete of un-needed data.

 

so you're saying that *not* doing parity-check is an option? being that it's turning to night time here in Berlin now, and that i hope to get a lot of sleep tonight, i may just do the parity-check to give the system something to do overnight and get rid of the pesky "Parity has not been checked" warning in the Web GUI.

 

thanks for you pointers to help me get through these last couple of steps!

There shouldn't be any issues with parity, but it's still a good idea to check it just to confirm all is well and (as you noted) to get rid of the pesky warning about it never being checked 

 

... just let it run overnight.

 

aaaahhhh!! the troubles just don't seem to wanna end!

 

the reiserfsck ended up giving me a lost+found folder that contains all of the previous 63 folders, plus another 36 files that have only numbers for names and some of them claiming to be from 1.41PB to 723.13PB in size, for a total size of 1623PB for the new lost+found folder...trying to delete any of those crazy "files" will get me the "don't have permission to access some of the items" error, which i thought the newperm command itimpi suggested i do would fix.

 

not sure what to do now...something very screwy is going on here, and i am not going to do a parity check before i haven't been able to delete that freakin' lost+found folder.

 

what next?

Well ... clearly something's messed up with that disk's structure that Reiserfsck couldn't handle.

 

Given that you have all of the data you actually want to keep from Disk #13 backed up to another disk (that IS correct -- right?), I'd be tempted to just "brute force" this ... by doing the following:

 

(1)  Do a New Config and assign all of your disks EXCEPT #13 to the config.  Be CERTAIN you assign the correct drive as parity;  then let the system do a parity sync ... if you start this tonight, by tomorrow you'll have a nice "clean" system with good parity but it won't have any of the data from disk #13.

 

(2)  Run a pre-clear on disk #13 ... if you trust the physical disk, you could use the -n option, which will just zero it and write the pre-clear signature (skipping the pre- and post- read phases) => this takes about 1/4th the time of a full pre-clear cycle.    But if you don't mind the time, it's not a bad idea to just do a full cycle.  [This IS, of course, going to completely wipe disk #13 to all zeroes ... so if you think there's ANY data on it that you don't already have backed up, be sure you do that first.]

 

(3)  Add disk #13 to your array [stop the array; add the disk; Start the array].  Since you pre-cleared it (step 2) it will just take a few minutes to format it and you'll be ready to use it.

 

(4)  Copy the data you actually want on that disk back to the array (just copy it directly to disk #13 if you want it on the same disk).

 

Done 

 

yeah, that's what i may do...although i *was* able to delete those obscenely large files with my alternate method of using my FTP client of choice, Transmit, to do what Finder won't let me do...maybe i'll try to synch what's left to the backup of the lost+found folder i made earlier, before the reiserfsck, and see whether i can ridden myself of that folder in this manner.

 

if i run into any more walls while doing this, this disk will be zeroed out, per your instructions!

Sounds like you've got the final few steps well in hand ... you just need some clock time for the long steps (parity sync; possibly pre-clear; copying data) to process.

 

If you have the data backed up elsewhere, then there might be case for taking the opportunity to switch the format of the disk to XFS by:

• Stopping the array
  
• Clicking on the disk in the main tab and change the format to XFS
  
• Start the array - the disk will now show as unformatted
  
• Select the checkbox for formatting unformatted drives.  This will 'wipe' any data and create a new empty XFS file system on the disk
  
• Copy back any data from the backups to the disk that you want to be on that drive.
  

If you have the data backed up elsewhere, then there might be case for taking the opportunity to switch the format of the disk to XFS by:

• Stopping the array
  
• Clicking on the disk in the main tab and change the format to XFS
  
• Start the array - the disk will now show as unformatted
  
• Select the checkbox for formatting unformatted drives.  This will 'wipe' any data and create a new empty XFS file system on the disk
  
• Copy back any data from the backups to the disk that you want to be on that drive.
  

 

Except, of course, that this is a v5 system and v5 doesn't support XFS  :)

If you have the data backed up elsewhere, then there might be case for taking the opportunity to switch the format of the disk to XFS by:

• Stopping the array
  
• Clicking on the disk in the main tab and change the format to XFS
  
• Start the array - the disk will now show as unformatted
  
• Select the checkbox for formatting unformatted drives.  This will 'wipe' any data and create a new empty XFS file system on the disk
  
• Copy back any data from the backups to the disk that you want to be on that drive.
  

 

Except, of course, that this is a v5 system and v5 doesn't support XFS  :)

Obviously I am not wide awake at the moment 

@garycase: after losing the 8 months of time it took me to backup 16TB of my data to Bitcasa only to have those thieving criminals delete it all in a day, even this seems bearable.

 

@itimpi: haha, you and i both! but maybe this would be the moment to do the upgrade to v6 that i've been wanting to do since before i received the system in this state...or is it a really bad idea to do this in the state my system is in right now? probably so, to answer my own question.

... maybe this would be the moment to do the upgrade to v6 that i've been wanting to do since before i received the system in this state ...

 

I WOULD do an upgrade -- but definitely NOT to v6.    But since you're on v5.0.4 I'd go ahead and update the bzroot and bzimage to v5.0.6, so you're on the final v5 version.

 

 

...or is it a really bad idea to do this in the state my system is in right now? probably so, to answer my own question.

 

Agree with your answer 

 

... AFTER everything's stable, if you want to move to the Beta, that's okay.  But unless you have a compelling reason to do so (i.e. Dockers or VMs), I'd be inclined to wait for v6 final.

 

 

ok, so i was able to backup the added lost-found files, delete the PB-sized ones, and delete the entire lost+found folder from disk 13...so disk 13 now is where i want it.

 

is there a pressing need to zero it and do the other steps? i mean, the fact that those PB-sized files appeared in the first place is a sure-fire way to tell that the file-system is still damaged? can this disk not be trusted until i zero it out, pre-clear it and let unRAID reformat it?

 

i'd rather not spend the next 2 days doing what i have been doing, but if you're telling me that it's the only sensible way, i will, of course.

nevermind...why stop here? i'm doing what you suggested as i type this...831 minutes to go...then the pre-clear...anything to look out for on the pre-clear? what's the proper terminal command for that?

just working my way through the wiki to answer my own question(s), like a good citizen.

 

seems like i need to have "screen" installed to do the pre-clear (well, there are instructions for doing this without "screen", although those instructions start with "Don't preclear without screen."), but in order to install "screen" it calls for unMenu...is there a way to do this without having to first install unMenu? i'm simply trying to find out what the proper X for drive 13 is (i mean the "X" in ./preclear_script.sh /dev/sdX).

 

it just seems that every step of the way i am getting deeper and deeper into changing things about my system.

 

FYI, i *have* upgraded to v5.0.6 Final during my last reboot.

just working my way through the wiki to answer my own question(s), like a good citizen.

 

seems like i need to have "screen" installed to do the pre-clear (well, there are instructions for doing this without "screen", although those instructions start with "Don't preclear without screen."), but in order to install "screen" it calls for unMenu...is there a way to do this without having to first install unMenu?

The screen package is not essential - it is just highly recommended as if you are running a pre-clear via a telnet session, then closing the telnet window aborts the pre-clear.  If you are running the pre-clear under screen then this does not matter.

 

It is possible to get screen installed without using unmenu by downloading the 'utempter' (utempter-1.1.5-i486-1.txz) and 'screen' (screen-4.0.3-i486-1.txz) packages from here and putting them in an 'extra' folder on the flash drive.  Make sure you select the versions for slackware 13.37 32-bit edition to be compatible with unRAID v5.  The next time the system is booted any packages found in the 'extra' folder are automatically installed.  They can also be installed manually from a telnet session using a command of the form

installpkg package_file_name

i'm simply trying to find out what the proper X for drive 13 is (i mean the "X" in ./preclear_script.sh /dev/sdX).

You could try getting a list of the sdX type devices by using a command of the form

ls /dev/sd?

and seeing which ones are NOT part of the array.

 

good stuff, itimpi!

 

this is where i am now:

 

root@unRAID:/boot/extra# ls

screen-4.0.3-i486-1.txz*  utempter-1.1.5-i486-1.txz*

root@unRAID:/boot/extra# installpkg utempter-1.1.5-i486-1.txz

Verifying package utempter-1.1.5-i486-1.txz.

Installing package utempter-1.1.5-i486-1.txz:

PACKAGE DESCRIPTION:

# utempter (utmp updating library and utility)

#

# The utempter package provides a utility and shared library that

# allows terminal applications such as xterm and screen to update

# /var/run/utmp and /var/log/wtmp without requiring root privileges.

#

Executing install script for utempter-1.1.5-i486-1.txz.

chown: cannot access `var/log/wtmp': No such file or directory

chmod: cannot access `var/log/wtmp': No such file or directory

Package utempter-1.1.5-i486-1.txz installed.

 

root@unRAID:/boot/extra# installpkg screen-4.0.3-i486-1.txz

Verifying package screen-4.0.3-i486-1.txz.

Installing package screen-4.0.3-i486-1.txz:

PACKAGE DESCRIPTION:

# screen (screen manager with VT100/ANSI terminal emulation)

#

# Screen is a full-screen window manager that multiplexes a physical

# terminal between several processes (typically interactive shells).

# Each virtual terminal provides the functions of a DEC VT100 terminal

# and several control functions from the ISO 6492 (ECMA 48, ANSI X3.64)

# and ISO 2022 standards (e.g. insert/delete line and support for

# multiple character sets).  There is a scrollback history buffer for

# each virtual terminal and a copy-and-paste mechanism that allows

# moving text regions between windows.

#

Executing install script for screen-4.0.3-i486-1.txz.

Package screen-4.0.3-i486-1.txz installed.

 

root@unRAID:/boot/extra#

 

are these anything to worry about?

"chown: cannot access `var/log/wtmp': No such file or directory

chmod: cannot access `var/log/wtmp': No such file or directory"

 

btw, there was no "extra" folder on my flash, so i created it...and i should delete those package now that they are installed right?

 

but when i do this, as suggested by the wiki, i still don't get what i need:

 

root@unRAID:/boot# preclear_disk.sh -l               

-bash: preclear_disk.sh: command not found

 

when i am looking for this:

 

Step 4 Identify the drive to be pre-cleared. Run this command (from the /boot dir)

 

preclear_disk.sh -l

 

The -l is a L as in LIST. The output will look like this:

 

preclear_disk.sh -l

====================================1.13

Disks not assigned to the unRAID array

  (potential candidates for clearing)

========================================

    /dev/sda = ata-ST3000DM001-1CH166_W1F293RJ

 

Make a note of the /dev/sdX or /dev/hdX. This is the drive you're going to be clearing.

oops, i guess i needed to execute "screen" before anything else, but then i get this:

 

root@unRAID:/boot# screen

Cannot find terminfo entry for 'xterm-256color'.

root@unRAID:/boot#

...btw, there was no "extra" folder on my flash, so i created it...and i should delete those package now that they are installed right?...

No, you must leave them there so they can be reinstalled on each reboot. The unRAID OS loads itself completely into RAM by unpacking a couple of files on your flash drive. Anything added is not included in those files that are unpacked, so anything "extra" has to be on the flash drive for unRAID to have it when it boots. The extra and plugin folders are places unRAID looks automatically when it boots up.

Not sure what those messages are about var/log but I do not think they matter.

 

I would leave the packages in the extra folder - that way they will get automatically installed any time you reboot the system without the need to manually run installpkg.  Creating the extra folder when it does not already exist is the correct thing to do.  The extra folder can be used for any standard slackware package that you want without the need for a unRAID specific plugin.  I also use it to install a ntfs-3g package.  However whether you want these installed on every boot is up to you.  The installpkg method is just a way of doing it the first time without the need to reboot, or if you only want it to happen once.

got it.

 

any idea why i get these, though?

 

root@unRAID:/boot# preclear_disk.sh -l               

-bash: preclear_disk.sh: command not found

 

and

 

root@unRAID:/boot# screen

Cannot find terminfo entry for 'xterm-256color'.

 

do i need to first install the preclear_disk.sh command somehow, and if so, how?

and how do i get the screen command to work correctly? i guess there would be a screen emulator visible if it worked correctly?