Linux lost found delete

How can I clear a lost+found directory in an external drive?

I bought a new drive and loaded a couple GB of data onto it, but wanted to start from scratch again so I deleted all of the files on the drive through $ rm -rf ./* . I then noticed that this drive was formatted as a FAT drive and I wanted an ext4 partition only, so I used parted to format the drive ( /dev/sda ):

$ sudo parted /dev/sda (parted) p (parted) rm 1 (parted) rm 2 (parted) p (parted) mklabel gpt (parted) mkpart primary ext4 0% 100% (parted) p (parted) q 

After quitting and trying to mount the device, I could not mount the new partition. Upon checking the filesystem, I saw that the partition was corrupted and tried $ sudo fsck -y /dev/sda1 (sda1 is the new, sole partition on the drive, formatted as ext4). This went through and formatted my partition as ext2, so I went back and repeated the reformatting steps using parted and tried $ sudo fsck -yt ext4 /dev/sda1 and it seemed to work well enough.

I could now mount the filesystem and it remained ext4. However, there is a lost+found directory with thousands of files within it now sitting in the drive. It is owned by root:root and even with a $ sudo rm -rf lost+found , I cannot delete it. It keeps spitting out rm: cannot remove ‘#’: Operation not permitted for every file I attempt to remove. Neither chmod nor chown help in helping remove the files located within this lost+found directory.

I then tried $ sudo su so I could # cd lost+found and check the attributes of the files with # lsattr but I still, even as root, get lsattr: Operation not supported While reading flags on ./# .

I have no need for any files on the system. I was toying around with rsync between my local machine and host and those are all of the files that I deleted. I know I don’t need any of them (I have other backups in addition to all of those files present on my local machine) so I just want to get rid of this darned lost+found directory but it’s being quite stubborn.

What should I do? What are my next steps? Is there any more information I should provide from program output that could help figure this out?

Would it be easier to just format the drive again? I tried doing so twice already, but each time it will not mount without an $ fsck -t ext4 /dev/sda1 (I include the -y flag in there as well since I don’t want to sit through the millions of confirmations it requires) and I end up here once again. I know that these lost+found files are being generated by the fsck program since I passed the -y option to it: there are parts of the output where it specifies that «there is existing data on the drive and it could be recovered, so should fsck move these files to lost+found ?» and it automatically gets passed an affirmative so the directory gets created and populated with these thousands of files. Is it because I specify this partition as a primary partition? Should it be extended instead (only holding data files)?

Any help would be appreciated! Though the files don’t take up much space on the hard drive (~1%), I would appreciate help in figuring this out since I want to understand why even root cannot delete these files and what I’m doing so horribly wrong in formatting my drives that I end up here every time.

After logging in as root through $ sudo su , I could view the files within lost+found and tried to test the lost+found directory itself for processes that were locking the directory and the first file that was in the directory as well to see if anything was using it:

$ sudo su # lsof lost+found # fuser lost+found # lsof lost+found/#51817 # fuser lost+found/#51817

Doesn’t look like any other processes are locking these files. Upon examining with # lsattr , there are a couple files with the i flag, but there are many more without that flag.

Furthermore, as @PabloBianchi pointed out in the comments, since ext*-formatted filesystems will always have a lost+found directory, I have clarified the question by modifying the title: instead of deleting said directory, how can I clear it so the files I know I don’t need to recover don’t waste space on my drive?

Источник

Можно ли удалить lost+found на подмантируемом разделе ext3 ?

По идее lost+found нужен только при fsck ? Если его удалить при «нормальной» работе, надеюсь ничего не произойдет, так ли это ?

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

Можно поитересоваться? Зачем? 🙂

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

2anonymous (*) (2002-11-09 02:55:26.972)
Спасибо за разрешение 🙂 Будет исполнено после разъяснения некоторых обстоятельств.

Меня другое интересовало, повлияет ли это как-то на работу самой системы ?
Просто у меня этот раздел примонтирован и является рутом(корнем) pub в фтп. Как-то некрасиво получается/не вписывается она туда, пустая и доступа к ней у других нет. Лишнее в общем.

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

>>Меня другое интересовало, повлияет ли это как-то на работу самой системы ?

нет. по необходимости этот каталог (эти каталоги) будут созданы заново.

Re: Можно ли удалить lost+found на подмантируемом разделе ext3 ?

anonymous (*) (2002-11-09 16:32:12.297)
Мерси, мусье. Теперь я буду спать спокойно 🙂

Похожие темы

• Форум Прикол в lost+found (2004)
• Форум Насколько опасно удалить каталог lost+found? (2015)
• Форум HELP. Lost+found (2003)
• Форум Скрипт подбора ключа cryptsetup из lost+found (2010)
• Форум восстановление файлов с папки lost+found (2016)

• Форум lost but not found (2004)
• Форум Как избавиться от lost+found (2004)
• Форум /lost+found/ восстановить данные. (2011)
• Форум ext3 repair (2003)
• Форум lvm и lost+found (2009)

Источник

The lost+found Directory in Linux and UNIX

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

1. Overview

In this tutorial, we’ll take a look at the lost+found directory that many a sysadmin has come across when navigating the Linux file hierarchy. We’ll see why this directory exists and the purpose it serves. We’ll also touch on the subject of recovering data from the lost+found directory.

Finally, we’ll use the find command to find the lost+found directories on the disk and delete them.

2. The lost+found Directory

The lost+found directory is a construct used by the fsck system utility. It’s a special directory that contains data that has become obsolete. The fsck utility creates it on a Linux machine with partitions of the Extended File System (ext2-ext4). However, they’re also created on other file systems like UFS and ZFS on UNIX derivatives.

The fsck utility creates the lost+found directory at the root of a volume. So, we can have multiple lost+found directories – one for each of the volumes.

2.1. The Purpose of the lost+found Directory

The lost+found directory contains files that have been deleted or lost in a disk operation. The files inside this directory have an inode, but they’re missing the corresponding filename that normally enables us to access files on the system. However, we can still access or restore a file’s data if its integrity is intact

The files inside this directory would have been regular files once with an inode and a filename. However, in rare cases, when a process opens a file for an operation, and somehow another process deletes the file when it’s still being used by the old process, it becomes just a data fragment. So, when there’s an improper shutdown or a kernel panic while the data is being used by the process, the data becomes obsolete.

Since the references to the file no longer exist and the file is no longer accessible normally, fsck turns the data back into a new file and deposits it in the lost+found directory.

Since we have already deleted the file, we need not care about it and can safely ignore it. On the other hand, if there is damage to the filesystem due to a hardware or a software bug, it’s up to the users to run an fsck check and find these files after fsck places them in the lost+found directory. Afterward, we can recover the data from these files, which may or may not be helpful to us, depending on how bad the filesystem damage was.

2.2. The mklost+found Utility

If we somehow accidentally delete the lost+found directory, we should use mklost+found instead of using mkdir. The mklost+found command creates the lost+found directory in the current directory and preallocates some space for fsck, so fsck doesn’t have to allocate data blocks in the filesystem during recovery. This is because recovering data and making changes to the filesystem simultaneously might corrupt the data. For that reason, we should avoid using mkdir and use mklost+found instead.

Using mklost+found is pretty straightforward. We just need to cd into the volume and run the command without any options:

$ mklost+found mklost+found 1.46.4 (18-Aug-2021) $ ls -l drwx------ 2 xsh xsh 49152 Dec 7 20:46 lost+found

Moreover, tools like mkfs also create the directory when we create a new partition on the disk.

3. Recovering Data from the lost+found Directory

The fsck utility makes it easy for us to recover the lost data. To recover lost data, we need to have run fsck before. Most Linux distros would run the fsck command on boot if the machine didn’t properly shut down. Otherwise, we’ll have to run it manually.

We have to make sure the partition we’re running fsck on is unmounted because running fsck on mounted partitions can be very harmful. For example, let’s run fsck on a /dev/sda3, which maps to the /home partition:

$ fsck /dev/sda3 fsck from util-linux 2.37.2 fsck.fat 4.2 (2021-01-31) /dev/sda3: 200 files, 38/130811 clusters

The fsck command runs a check on /dev/sda1 and creates a lost+found directory at the partition’s root. Next up, we’re going to mount the partition and navigate to the lost+found directory:

$ mkdir -p /tmp/home $ mount /dev/sda3 /tmp/home $ cd /tmp/home/lost+found

The files have lost their original filenames, so fsck renames them with a random number. Therefore, we’re going to look into the data to make some sense out of it. First, we’ll use the file command, which extracts the metadata from the file’s headers:

$ file * #4605470: ASCII text #4655470: PNG image data, 943 x 436, 8-bit/color RGBA, non-interlaced #4610801: directory #4613588: PDF document, version 1.4, 1 pages . 

If we have a lot of files, then it can be overwhelming to go through each file’s metadata. Therefore, we can grep some useful information from the file command’s output and operate on it:

$ file * | grep PNG #4655470: PNG image data, 943 x 436, 8-bit/color RGBA, non-interlaced . 

Now, let’s say we want to recover the first PNG file. We’ll simply get its filename through awk and copy the file to a location:

$ cp "$(file * | grep PNG | awk '' | cut -d':' -f1)" /tmp/home/username/image.png

Theoretically, it’s possible that the data might be corrupted and, therefore, harder to recover, but there’s also a good chance that the integrity of the recovered data will be intact.

4. Finding and Deleting the lost+found Directory

Sometimes, the data inside the lost+found directory might be huge, and we might not need it. However, we must be aware that the lost+found is different from an ordinary directory because fsck will not create it during recovery as it has preallocated blocks associated with it. Although it’s not recommended to delete the lost+found directory, there’s no harm in deleting the data if we want to make space on the disk.

We can remove the lost+found directories on all partitions using the find tool. Note that we’ll need to make sure that all the partitions are mounted and that we have root access:

$ find "-iname" lost+found -type d -exec rm -r "<>" \;

5. Conclusion

In this article, we saw the use of the lost+found directory and why it exists on Linux filesystems. We also saw how we could create a lost+found directory using mklost+found. Afterward, we briefly went through recovering data from the lost+found directory.

Finally, we saw how to find and remove the lost+found directory to make some space.

Источник