• 9
name

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191

Backtrace:

File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

What is the use of the lost+found directory?

I would like to use digitalocean's block storage decive as a dedicated file system to manage Docker containers. The plan is to have this file system mounted at /var/lib/docker at boot time, before the Docker service is started.

My attemps to do so thus far have been unsuccessful. While my playbook does not report an error, running ls -la /var/lib/docker after formatting and partitioning DO's block storage device indicates that I might have a problem:

drwxr-xr-x  3 root root  4096 
drwx--x--x 14 root root  4096
drwx------  2 root root 16384 Jan 25 16:47 lost+found

After reading this, this, and this, I can't decipher what lost+found means but I do grasp that it isn't a good sign.

I would like to understand why and fix it of course. My playbook is below (please note that playbook below is using static/explicit values due to needing to debug):

---
- name: mount point of attached volume 
  stat: 
    path: /mnt/name_of_attached_volume

- name: get digital_ocean_volume_path_by_name 
  stat:
    path: /dev/disk/by-id/scsi-0DO_Volume_name_of_attached_volume

- name: unmount images volume
  command: umount /mnt/name_of_attached_volume


- name: Label the volume
  command: parted -s /dev/disk/by-id/scsi-0DO_Volume_name_of_attached_volume mklabel gpt

- name: Create an ext4 partition
  command: parted -s -a opt /dev/disk/by-id/scsi-0DO_Volume__name_of_attached_volume mkpart primary ext4 0% 100%

- name: Build the ext4 metadata
  command: mkfs.ext4 /dev/disk/by-id/scsi-0DO_Volume__name_of_attached_volume-part1

####################################################################
#  since the mount point  -- `/var/lib/docker`  -- already exists  #
#  by virtue of docker being installed on the host, no need to     #
#  create a mount point but I do need stop docker running          #
####################################################################

- name: stop docker service 
  service: 
    name: docker 
    state: stopped

- name: mount volume read-write
  mount:
    path: /var/lib/docker
    src: /dev/disk/by-id/scsi-0DO_Volume__name_of_attached_volume-part1
    fstype: ext4 
    opts: defaults,discard
    dump: 0
    passno: 2
    state: mounted

- name: remove mount point for images volume 
  command: rmdir /mnt/name_of_attached_volume

- name: Start docker service 
  service: 
    name: docker
    state: started
    enabled: "{{ docker_service_enabled }}"

I am obviously missing/misunderstanding a step. Greatly appreciate tips please. Thank you!

      • 1
    • What is the problem you are having? You explained what you did, and it looks like you succeeded in mounting the storage. But you haven't explained what has gone wrong?
      • 1
    • Hello, @MichaelHampton the problem is that the part to the mounted volume says lost+found. I don't know what that means and I am looking for clarification on it. Thank you
      • 1
    • yes and its implications for my mounted volume (will I be able to write to and read from it?). Thank you so much.

Lost and found is an (American) English expression which means a place where lost items are turned in and the owners might find them again.

Similarly, the lost+found directory is where the system, upon checking the filesystem for corruption with fsck, places files which were recovered but for which the original pathname could not be determined.

This directory is normally empty, and so long as it remains empty, you have no problem. If files appear in the directory after you check the filesystem, you must determine manually what the content of the file was and restore it to its original location or otherwise act on it. If a file has gone missing after checking the filesystem, you might find it there, thus it acts very similarly to the real-life lost and found.

  • 4
Reply Report
    • Thank you for providing clarification. From your answer, I gather that when a file system is formatted, partitioned and mounted at a mount point (in this case /var/lib/docker), the mount point itself becomes a lost+found directory? So this is normal and to be expected - and my comment about "but I do grasp that it isn't a good sign" isn't correct?
      • 2
    • No, the mount point itself is not lost+found, that directory is one below the mount point. i.e. /var/lib/docker/lost+found, if you mounted the filesystem at /var/lib/docker.
    • ha! okay. Thank you so much. I am going to try reading and writing to var/lib/docker now and see what happens. Appreciate you taking the time to help.

Trending Tags