start_minio ${start_port}

	# Unmount the disk, after the unmount the device id
	# /tmp/xxx/mnt/disk4 will be the same as '/' and it
	# will be detected as root disk
	while [ "$u" != "0" ]; do
		sudo umount ${WORK_DIR}/mnt/disk4/
		u=$?
		sleep 1
	done

	# Wait until MinIO self heal kicks in
	sleep 60

	if [ -f ${WORK_DIR}/mnt/disk4/.minio.sys/format.json ]; then

* A new volume manager was introduced in kubelet that synchronizes volume mount/unmount (and attach/detach, if attach/detach controller is not enabled). ([#26801](https://github.com/kubernetes/kubernetes/pull/26801), [@saad-ali](https://github.com/saad-ali))
    * This eliminates the race conditions between the pod creation loop and the orphaned volumes loops. It also removes the unmount/detach from the `syncPod()` path so volume clean up never blocks the `syncPod` loop.

		// Add a separator to indicate that this is a proper mount-point.
		// This is to avoid a situation where prefix is '/tmp/fsmount'
		// and mount path is /tmp/fs. In such a scenario we need to check for
		// `/tmp/fs/` to be a common prefix amount other mounts.
		mpath := strings.TrimSuffix(mount.Path, "/") + "/"
		ppath := strings.TrimSuffix(path, "/") + "/"
		if strings.HasPrefix(mpath, ppath) {

- On compatible systems, a mounter's Unmount implementation is changed to not return an error when the specified target can be detected as not a mount point. On Linux, the behavior of detecting a mount point depends on `umount` command is validated when the mounter is created. Additionally, mount point checks will be skipped in CleanupMountPoint/CleanupMountWithForce if the mounter's Unmount having the changed behavior of not returning error when target is not a...

- Fix: Mount point may become local without calling NodePublishVolume after node rebooting. ([#119923](https://github.com/kubernetes/kubernetes/pull/119923), [@cvvz](https://github.com/cvvz)) [SIG Node and Storage]

* fix mount unmount failure for a Windows pod ([#63272](https://github.com/kubernetes/kubernetes/pull/63272), [@andyzhangx](https://github.com/andyzhangx))
* Fix concurrent map access panic ([#65327](https://github.com/kubernetes/kubernetes/pull/65327), [@dashpole](https://github.com/dashpole))
    * Don't watch .mount cgroups to reduce number of inotify watches

# Sub Aplicaciones - Mounts { #sub-applications-mounts }

Si necesitas tener dos aplicaciones de **FastAPI** independientes, cada una con su propio OpenAPI independiente y su propia interfaz de docs, puedes tener una aplicación principal y "montar" una (o más) sub-aplicación(es).

## Montar una aplicación **FastAPI** { #mounting-a-fastapi-application }

	mountsPath := filepath.Join(dir, "mounts")
	if err = os.WriteFile(mountsPath, []byte(successCase), 0o666); err != nil {
		t.Fatal(err)
	}
	// Verifies if reading each line worked properly.
	{
		var mounts mountInfos
		mounts, err = readProcMounts(mountsPath)
		if err != nil {
			t.Fatal(err)
		}
		if len(mounts) != 3 {
			t.Fatalf("expected 3 mounts, got %d", len(mounts))
		}

Essa sub-aplicação é apenas outra aplicação FastAPI padrão, mas esta é a que será "montada":

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[11, 14:16] *}

### Monte a sub-aplicação { #mount-the-sub-application }

Na sua aplicação de nível superior, `app`, monte a sub-aplicação, `subapi`.

Neste caso, ela será montada no path `/subapi`:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[11, 19] *}

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[11, 14:16] *}

### Mount the sub-application { #mount-the-sub-application }

In your top-level application, `app`, mount the sub-application, `subapi`.

In this case, it will be mounted at the path `/subapi`:

{* ../../docs_src/sub_applications/tutorial001_py39.py hl[11, 19] *}