0
$\begingroup$

Systems impose semantics to clarify functionality. For example, a system may disallow a mount over a directory that contains files; or it may make the mounted file system available at tha directory and obscure the directory's existing files until the file system is unmounted, terminating the use of the file system and allowing access to the original files in that directory. As another example, a system may allow the same file system to be mounted repeatedly, at different mount points; or it may only allow one mount per file system.

  • Galvin et al, Operating System Concepts

When a file system is mounted, the contents of the directory at that mount point are unavailable to users unitl the file system is unmounted.

  • Deitel et al, Operating System

So, basically this means we're trying to say at one mount point we can have only one file system. i.e a directory can have only one filesystem.

But why?

In a tree structured directory, I see no reason to allow a mount point to have multiple filesystems.

When I asked this to my professor, he asked me this question.

So to which file system would you store a resource that goes to a directory with multiple mounts?

I didn't understand what he meant. The below figure is how I visualize my system would look like.

enter image description here

PS can we call an umounted file system as "device"?

enter image description here

Source: https://warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/students/david_goodwin/teaching/operating_systems/l5_filemgt2013.pdf

$\endgroup$

2 Answers 2

1
$\begingroup$

Perhaps your confusion comes from the fact that you're imagining the filesystem being mounted as a subdirectory of the mount point. That's not the case.

If you mount what you call file_system_1 at, say, /something/mount_point then the path that refers to root of the file system will be /something/mount_point and not /something/mount_point/file_system1 as you seem to imply. (How would the OS even know the name file_system_1?).

As you see it doesn't make sense to have two file systems mounted on the same mount point (which one are you expecting to see when you access /something/mount_point?*). Of course nothing prevents you from mounting one file system on the mount point /something/mount_point/file_system_1 and the other on the mount point /something/mount_point/file_system_2.

*If you were imagining the directory structures of both file-systems to be combined into one, look at overlay file systems. Notice that handling path collisions and writes becomes much more tricky in this case.

$\endgroup$
3
$\begingroup$

SunOS 4.1 supported something like what I think you're getting at, called the Translucent File System. The idea is you could stack multiple filesystems in the same location.

When searching for a file, searching was performed from the top of the stack downwards, until the first file with that name is found.

However, mutations of the filesystem could only be done on the topmost filesystem. For example, writing to a file created a new copy on the topmost filesystem, and removing a file created a "whiteout" in the top-level filesystem which effectively hid that file in any filesystems that were underneath.

TFS was removed in SunOS 5.7.

Linux, FreeBSD, and NetBSD have varying support for union-mount filesystems that are based on the broad same ideas: UnionFS, aufs, and OverlayFS.

The idea has turned out to be useful for lots of applications in the modern era, such as:

  • Containerisation, e.g. Docker. The same mechanism supports snapshots and rollback during container building, as well as stacking a live running container over a read-only image.
  • Embedded devices which overlay read-write storage over EPROM.
  • Flash memory devices with limited write cycles.
$\endgroup$
4
  • $\begingroup$ please explain which idea you're talking about and how they turnt so important in docker etc. $\endgroup$
    – Team B.I
    Oct 2, 2023 at 5:35
  • $\begingroup$ @achhainsan Consider a simplified version of a container system like Docker, where an image only has one filesystem. When you run an instance of the image, what happens internally is that the container system mounts two filesystems in the same location: The read-only image, and a read-write overlay on top of it. If the instance writes to what it thinks is its own copy of the filesystem, it is actually modifying the read-write overlay. This way, when the instance exits, the image is untouched. You can also easily run multiple instances of the same image on the same machine. $\endgroup$
    – Pseudonym
    Oct 2, 2023 at 6:02
  • 1
    $\begingroup$ Wow, Being a devops egr as well, You've intrigued me a lot! Never though docker used cs. $\endgroup$
    – Team B.I
    Oct 2, 2023 at 6:45
  • $\begingroup$ Docker needs to know a lot about operating system design and implementation. $\endgroup$
    – Pseudonym
    Oct 2, 2023 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.