[jira] [Commented] (MESOS-9007) XFS disk isolator doesn't clean up project ID from symlinks

["Ilya Pronin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-9007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516486#comment-16516486 ] 

Ilya Pronin commented on MESOS-9007:
------------------------------------

Per [discussion at the XFS mailing list|https://www.spinics.net/lists/linux-xfs/msg19197.html] it is not possible to unset project ID from a symlink. So we need to change the approach to project ID deallocation. XFS project IDs are 32bit integers, so we have plenty of them. We can leave project IDs on container sandboxes until they are GCed. The question is how track when a directory is GCed, since there's no GC hook that the isolator could use. The simplest way would be to periodically check the work dir to see if any of the sandboxes was removed and the project ID associated with it can be deallocated. Or we can use inotify mechanism. Or add a hook :)

> XFS disk isolator doesn't clean up project ID from symlinks
> -----------------------------------------------------------
>
>                 Key: MESOS-9007
>                 URL: https://issues.apache.org/jira/browse/MESOS-9007
>             Project: Mesos
>          Issue Type: Bug
>          Components: containerization
>            Reporter: Ilya Pronin
>            Priority: Minor
>
> Upon container destruction its project ID is unallocated by the isolator and removed from the container work directory. However the removing function skips symbolic links and because of that the project still exists until the container directory is garbage collected. If the project ID is reused for a new container, any lingering symlinks that still have that project ID will contribute to disk usage of the new container. Typically symlinks don't take much space, but still this leads to inaccuracy in disk space usage accounting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)