-2

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!

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 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? – Michael Hampton Jan 26 '19 at 03:11
  • 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 – fusedflyn231 Jan 26 '19 at 04:32
  • So there's nothing actually wrong. You just want to know what `lost+found` is for? – Michael Hampton Jan 26 '19 at 04:39
  • yes and its implications for my mounted volume (will I be able to write to and read from it?). Thank you so much. – fusedflyn231 Jan 26 '19 at 04:41
  • I do not understand the downvotes. Question meets requirements stated [here](https://serverfault.com/help/on-topic). Is asking for clarification on a concepts we do not understand discouraged? Is the question not clear enough? It would be better if folks can downvote only when a reason is given (e.g - duplicate question, does not belong here, etc). Downvoting without giving a reason is counter productive to building community/discussion - the person asking the question learns nothing about how this community operates; voters exercise power without justification. – fusedflyn231 Jan 27 '19 at 00:31
  • Votes are not only for the person who wrote the question or answer. Voting tells anyone who sees a Q or A what the community thinks of it. A post with many downvotes means the community doesn't think it's very good. Many upvotes means the opposite. A few votes one way or another can be an indicator of which way the community is tending... When no other comment is given, the "default" meaning of a downvote is given by the tooltip you see when your mouse is over the button: "This question does not show any research effort; it is unclear or not useful." – Ward - Reinstate Monica Jan 27 '19 at 00:50
  • Since no comment is given then I would argue that the default reason "the question does not show any research effort" is incorrect. The user clearly points to the research discussing term and use of `lost+found`. And also states "can't decipher what lost+found means but I do grasp that it isn't a good sign". The downvotes DO bother me but not as much as the perception that folks abuse their ability to downvote. Forcing users to actually state why they are downvoting and penalizing low quality downvotes (after discussion of course) I think will lead to better community involvement – fusedflyn231 Jan 27 '19 at 01:26
  • @fusedflyn231 The idea of mandatory comment in downvote is a concept that was studied a *lot* on stackexchange, as seen there https://meta.stackoverflow.com/questions/357436/why-isnt-providing-feedback-mandatory-on-downvotes-and-why-are-ideas-suggestin as you can see, not moderator like me, but the staff itselft didn’t coded that. You can go vote and make your voice heard there or on meta stackexchange, but I fear its a lost hope topic alas. – yagmoth555 Jan 27 '19 at 01:55
  • @yagmoth555 thanks for pointing me towards that link. Good to know that folks have voiced their opinions; and I also I got to voice mine. At the end of the day, using stack overflow and its family of services is an option. If we can't fix it together, then only those who find it useful will keep using it. – fusedflyn231 Jan 27 '19 at 02:04

1 Answers1

4

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 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? – fusedflyn231 Jan 26 '19 at 04:57
  • 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`. – Michael Hampton Jan 26 '19 at 04:59
  • 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. – fusedflyn231 Jan 26 '19 at 05:01