Lost & Found folder of 320GB size...

[ullibelgie]

I recently changed my Parity disk for a bigger one and after that changed one of my data disks to a bigger one as well.

I followed the guide in the Unraid wiki for doing that and although it took a very long time (3 days and nights) all went find with no errors.

 

So at the very end, when everything was finished fine, I switched off the server safely  - I stopped the array followed by the shutdown button in Unraid.

 

When I wanted to restart the server the next morning, my newly installed (bigger) data disk was unmountable, but not disabled. Pre-clearing, formatting and rebuild process was without any error however before.

I was wondering how that can happen....!?!

So finally after reading a lot in forum and Unraid wiki documents, and still not understanding why the brand new HDD is unmountable, I decided to check the filesystem and finally run the repair routine...

 

Fortunately the new disk with all the data rebuilt from the old Data-disk now was mountable again and it seems, that the system runs without faults...

 

However what concerns me is, that I now have a folder of 360GB on this newly installed disk (lost & found) as well as a new Share with the same name. This is to me really a waste of HD-space.

It was not my intention to install a bigger data-disk just to waste the more space with a file, which I don't want...

 

It is annoying to have a share 'lost & found', which I don't want, but which is bigger than most other folders...

 

Can I delete it ?

Or at least delete all content of it ?

 

Should I install the old disk again and go to the total disk change procedure once again  to get rid of that large lost & found folder ?

I really do not want the lost & found folder occupy most of the additional space of my new hard disk - the exchange of data disk would be useless then.

 

What is the experts advice ?

[itimpi]

30 minutes ago, ullibelgie said:

However what concerns me is, that I now have a folder of 360GB on this newly installed disk (lost & found) as well as a new Share with the same name. This is to me really a waste of HD-space.

 

A lost+found folder gets created as a place for the repair to put any files it cannot find directory entries for to give their correct name.   Since all top level folders on any drive are treated as a User Share you got a share with this name appearing (with default settings).

 

If you are happy to lose the 320GB that was put there by the repair process then you can simply delete it and remove the share.  

 

Quite why it got created in the first place is not clear if all the steps appeared error free (including the repair) as you state.  Just for interest what file system type is on the drive in question.

[ullibelgie]

I use XFS file system for all drives

 

To clearify:

"If you are happy to lose the 320GB that was put there by the repair process then you can simply delete it and remove the share. "

 

What does it mean ?

Of coarse I do not want to loose data, but I also do not want to store data twice. The data should be in the original folders, but not somewhere in lost and found.

 

So what I need to know:

Has the repair process as a result of the repaired file system moved the data from it's original folder to lost and found ?

As the lost & found file contains 1926 objects, 1874 directories and 52 files it would be a very cumbersome process to find out...

 

What would you do ?

 

[itimpi]

Files/folders only get put into lost+found if the repair process cannot find the directory information to put them into the correct folder with the correct name.  On that basis that 320GB should not exist elsewhere on the drive although that is a very large amount to have lost the directory information.

 

In most cases it is easiest to 'nuke' the lost+found folder and restore any missing files from your backups as going through the lost+found folder is a very laborious manual process to try and identify what the files there were originally called.   That does rely on you having adequate backups, and without them if the data was important you may have no other choice.  When restoring from backups you can use  options so that only files that are missing are copied from the backup. 

 

If you DO decide to process the lost+found folder the Linux 'file' command can at least tell you what type of content (and thus likely file extension) the file originally had).

 

[JonathanM]

4 hours ago, ullibelgie said:

changed one of my data disks to a bigger one as well.

Is the old drive unmodified still, or did you already repurpose it?

[ullibelgie]

I still have the old drive and unchanged since I have taken it out.

This disk had a few read errors before but was not disabled. I never had to xfs_repair the old disk.

 

 

[JonathanM]

1 hour ago, ullibelgie said:

I still have the old drive and unchanged since I have taken it out.

That disk is probably your best bet to recover the files that were moved to lost and found.

[ullibelgie]

I think I know the reason for the XFS - file system problems:

My machine is a very old hardware and slow.

However the disk settings for wait until shutdown is only 90sec. It could be, that this timing is too short to guarantee a clean shutdown under normal circumstances, because the server hardware is old and rather slow...

So I increased the timer now to 600sec to be save and to prevent a unclean shutdown...

 

I am considering to rebuild the total server with a new clean install - all data I have offline ...

[trurl]

8 hours ago, ullibelgie said:

formatting and rebuild process

This one thing you said in your first post makes me wonder though. Format is NEVER part of the rebuild process. Did you actually format the new disk in the array?

[ullibelgie]

I followed the procedure of the Unraid wiki for taking out disks to replace them with bigger ones.

Every new disk needs to be formatted - that is, when Unraid sees the new hardware for the first time and place it in the unassigned disk plug-in. Here I pre-cleared the new disks (stress test for 2days) then formatted them in XFS

After that assigned them in the disk array, so at that moment the rebuild process started and finally finished with zero errors...

Then I switched off the Server in the evening to switch it on next morning with the new Data disk being unmountable

After XFS_Check and XFS_repair, I end up with half of the data moved from Data Disk 1 to Lost & Found folder

The problem is that for example files which have been before in "Audio"  share, have been moved to "Lost & Found" and are not in the Audio share anymore...

 

In total this in total 360Gb moved from all shares (incl system, AppData....) to lost and found and many are unreadable...

 

I don't know how to correct this -- rather than build a new server ... copy & paste for weeks from offline data files.... no real server backups, just the original data at it original place had not (yet) been erased, as the server is only about 4weeks old...

[trurl]

37 minutes ago, ullibelgie said:

Every new disk needs to be formatted

That is incorrect.

 

But if you did the format before assigning it to the array, then the format you did, though pointless, wouldn't have been a problem. I say pointless because rebuild is going to overwrite the entire disk, including any format you did.

 

I always get worried when someone says "format" in contexts where it doesn't belong.

 

Format means "write an empty filesystem to this disk". That is what it has always meant in every operating system you have ever used.

 

In the case of disks assigned to the array, Unraid treats that write operation (format) just as it does any other write operation, by updating parity. So, if you format a disk in the array and then rebuild it from parity, the rebuild can only result in an empty filesystem.

 

Also note that if you preclear a disk, then format it as you did, it is no longer clear. So if you add that disk to a new slot in the array, Unraid must clear it again so parity remains valid.

[ullibelgie]

"But if you did the format before assigning it to the array, then the format you did, though pointless, wouldn't have been a problem. I say pointless because rebuild is going to overwrite the entire disk, including any format you did."

 

Thanks for explanation - I was not aware, that there is no need to format the disk.... but I am just a stupid user of computer applications until I started with Unraid a few weeks ago. I am depending on people like you who explain to me how things work and I try to read as much as possible about it...

 

"So, if you format a disk in the array and then rebuild it from parity, the rebuild can only result in an empty filesystem."

 

This is clear to me now, but it is not what I have done - the disks were formatted before they were assigned to the Array - useless though... But thanks for the warning !

 

"Also note that if you pre-clear a disk, then format it as you did, it is no longer clear. So if you add that disk to a new slot in the array, Unraid must clear it again so parity remains valid."

 

Another reason not to format a disk in the replacement process

So you can see, that even there is a extensive wiki available, which I at least have read 10times, you still can misunderstand a lot with no IT-background at all... we call it learning...;-)

I did not expect my server to last longer than one month.... I almost reached it, before it breaks...

Now it is time to do it again, I think - I still have the old data-disk, which contains the files of Disk 1, which I now moved partly to lost&found... so I can recover it, I hope

 

[trurl]

18 minutes ago, ullibelgie said:

"Also note that if you pre-clear a disk, then format it as you did, it is no longer clear. So if you add that disk to a new slot in the array, Unraid must clear it again so parity remains valid."

 

Another reason not to format a disk in the replacement process

That example is not about replacement, but about adding a disk to a new slot. Unraid requires a clear disk when adding to a new data slot, since a clear disk is all zeros, and so has no effect on existing parity. If a disk for a new slot isn't precleared Unraid must clear it before it can be added to the array so parity remains valid. Then it can be formatted in the array.