New volumes contain "lost+found"

[brightbulbnz]

Newly created convoy volumes contain a "lost+found" directory. This prevents many docker containers from initialising, as they will only write if the volume is empty.

Example: In order to get the official MySQL container to write persistent data to the volume, I had to manually remove the lost+found directory in order to have it start up.

I'm using DeviceMapper with the default filesystem

[jinuxstyle]

The "lost+found" directory is generated automatically by the ext4 filesystem used by convoy as the default when formatting volumes. It's an inherent thing of ext filesystems for recovering filesystem from inconsistency in case of unclean shutdown or power failure. I am afraid there is no way to prevent it from generating the directory. Besides manually removing it, I'd suggest another two alternative ways to workaround it:

1. make empty directories in the volume for writing data
2. use xfs instead (support of xfs in convoy is already in a pull request, hopefully it will be merged soon)

[brightbulbnz]

Thanks @jinuxstyle. Using subdirectories could be a good solution, but I can't seem to find a way to mount a subdirectory of a named volume e.g.: -v volumename:/data is OK but -v volumename/data:/data is not. Do you know of a way to get around this limitation?

[jinuxstyle]

I don't know. For the problem, can't you just mount the volume to /data of the container and get the container write data to a subdirectory of /data?

[jinuxstyle]

I just found a way that may work for your case. You can first mount the convoy volume by using "convoy mount --mountpoint=/path ", then create a empty dir in the mounted volume. Then you can mount the empty directory to your container with "-v /path/dir:/data". After using, unmount the volume by using "convoy umount ". This way, you don't have to remove the "lost+found" directory. Hope it helps.

[dgafka]

Can convoy create an empty subdirecty by itself and mount this one to the container instead of root containing lost+found? Or just delete the lost+found?

[yasker]

The only automatic alternative I saw so far is using new xfs we included in https://github.com/rancher/convoy/commit/eb776165190247c9c4d6a736b6de31fc1d8a044a .

ext4 always created the directory and seems cannot be avoid...

[yasker]

Think about it, we may want to just get rid of directory in someway, probably just remove it.

[brightbulbnz]

I would argue that this is more severe than just an enhancement.

Is there a way for convoy to remove all directories before it mounts? From my understanding, the filesystem can recreate the directory later if necessary.