Let a filesystem operation name a container, and report the bytes a trim discarded

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.

[MayCXC]

Summary

A filesystem operation takes a path in the init namespace, and a container's root filesystem is not there: the container mounts it in a namespace of its own, and after the pivot nothing in the init namespace names it. The operations that matter for a root filesystem, trim above all, were out of reach for exactly the filesystems that grow.

A request that names a container reaches its root filesystem through the init process's proc entry: the kernel resolves /proc/<pid>/root through that process's namespace, and the trailing dot component keeps the opened target a directory rather than the magic link itself, which the handler's O_NOFOLLOW refuses. The agent surface takes the container id and answers with the bytes the filesystem reported trimmed, for a single container and for a pod's members alike.

Closes#858. Addresses the requirement described in apple/container#2105.

Relationship to #838

This supersedes #838, which asks for the same thing from issue apple/container#2105. Both add containerID to FilesystemOperationRequest so the operation runs against the intended container. The differences:

• FiTrimResult.trimmed_bytes is populated here. The field arrived with the trim operation in [vminitd]: api for trim filesystem operations #700 and has never been set: trimFilesystem(fd:) throws away the count that FITRIM writes back into the range, and filesystemOperation returns a bare .init(), so the oneof is never set and callers decode the default. [vminitd]: update filesystem operation to run in new namespace #838 keeps return .init(), so the field stays dead after it. Reporting is the whole reason the field exists, and a caller that loops until a trim returns nothing cannot work without it.
• containerID stays optional.[vminitd]: update filesystem operation to run in new namespace #838 rejects a request that does not carry one, which breaks the existing path-addressed callers. Here a request names either a path or a container, so existing callers keep working.
• The host side gains the operation it needs.LinuxContainer.trimRootfs() and LinuxPod.trimContainer(_:) return the bytes discarded, rather than leaving each caller to assemble the request.
• There is a test for the count.testContainerTrimReportsBytes boots a container, trims, and asserts the answer is not zero, which is what fails today.

One thing #838 does that this does not: it enters the container's mount namespace with setns(CLONE_NEWNS) on a dedicated thread after unshare(CLONE_FS). That is a correct way to do it, and it generalises to any path inside the container. Resolving through /proc/<pid>/root reaches the same filesystem through the same namespace without moving a thread between namespaces. If maintainers prefer the setns approach, the reporting fix and the host-side API here apply on top of it unchanged.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• make vminitd builds the guest with the change.
• Integration: ./bin/containerization-integration --filter trim runs container trim reports bytes and the existing container trim ext4 clone, both passing. The new test fails before the reporting fix with trim reported 0 bytes.