Screwed up drive replacement

[dealbakerjones]

yes

[trurl]

This was the missing disk1? Was it xfs?

 

That is your default, but Unraid doesn't seem to remember what it was. 

[dealbakerjones]

disk1 was recently consolidated out of the array, so doesnt exist (prior to rhe current issue)

disk3 (450gb now in pool "two") was imoroperly uograded to 900gb (currently assigned to disk3)

Edited February 1 by dealbakerjones
clarity

[trurl]

OK, I get it now. And you formatted emulated disk3 so it is now empty and we need to try to get your files from pool 'two'

19 minutes ago, trurl said:

Was it xfs?

 

 

[dealbakerjones]

yes, correct on both - it was xfs

[trurl]

Have you booted up again?

[dealbakerjones]

yes, standing by

[trurl]

This is less than ideal, because normally I would ask for you to post the output of this command:

xfs_repair -nv /dev/sdg1

It may not all fit on one screen for you to photograph.

[dealbakerjones]

short output:

[trurl]

OK, now without -n

xfs_repair -v /dev/sdg1

 

[dealbakerjones]

only took a few sec, here's the final output:

[trurl]

Are you booted in GUI mode or are you working completely at the command line?

[trurl]

Oh I see the Firefox at the top of the photo so must be GUI.

 

Stop and restart the array, and see if pool 'two' shows it has contents.

[dealbakerjones]

it mounted! contents look like:

/lost+found/1252945

[dealbakerjones]

oh but inside each numbered dir is the folders i recognize, plus a bunch of files with just numbers

[trurl]

What do you get from command line with this?

df -h /dev/sdg1

 

[trurl]

And this?

ls -lah /mnt/two

 

[dealbakerjones]

this matches up with the disk utilization i had before

[dealbakerjones]

reading through the xfs repair doc, it looks like my next step is to copy directories and files manually, and whatever didn't rebuild, is orphaned. i gather that since parity was lost (when i formatted the 900gb disk3 replacement), i can't rebuild data that was originally on 450gb disk3

 

(standing by)

[trurl]

11 hours ago, dealbakerjones said:

parity was lost (when i formatted the 900gb disk3 replacement)

Parity is in-sync with the formatted disk so can't rebuild anything else.

 

Looks like repair put everything in lost+found.

 

The linux 'file' command can help you figure out what type of data is in each file, then maybe you will know what application you can try to use to open it and see if you can identify it.

 

[dealbakerjones]

ok so the next steps are just manually moving the files? didn't want to do anything in case any other unraid operations could get messed up if i move things

[trurl]

How do you plan to move anything? I assume you don't have network so can't do it that way. And you don't have Dynamix File Manager plugin which would allow you to work with files directly on the server.

 

I mostly used Midnight Commander (mc at the command line, built-in) as a file manager on the server before Dynamix File Manager plugin was invented.

 

Of course command line is another method.

 

But I do have a reason for asking. There are possible pitfalls when moving or copying files with mc or command line.

 

That pool is part of user shares. Probably not much danger given the screwed-up paths, but the usual advice is to never mix disks and user shares when moving or copying files.

 

Linux doesn't know that a user share path and a disk path might be referring to the same file, and so it will allow you to accidentally specify paths where the source and destination are actually the same file. This causes it to try to overwrite what it is trying to read, resulting in an empty file.

 

The way around this is to only copy or move from disk to disk, or from user share to user share, and never from disk to user share or user share to disk.

 

Another thing that can happen when moving from user share to user share. Linux can decide to just change the path instead of actually moving the file, since that is more efficient. This will result in the file staying on the same disk, but at a different path. The way around this is to copy (not move) so a new file is created at the destination in conformance with the user share settings, then delete from source.

[dealbakerjones]

understood - i got my pfsense vm rebuilt last night, so Internet is back! i can get Dynamix File Manager installed

[dealbakerjones]

Thanks for all your help so far. I used Dynamix to copy lost+found folder from 450gb to 900gb disk3- is there anything special I need to do to pull the files back into the shares?

For example, inside /lost+found, there are dirs like /3d, /project, like you'd normally have such directories across multiple disks. If I move these folders into the root dir on disk3, will unraid find them?

[trurl]

7 minutes ago, dealbakerjones said:

If I move these folders into the root dir on disk3, will unraid find them?

Not only will it find them, but it will consider each of them a user share if you put a folder at the top level of any disk or pool.