5

This question is not about me having any kind of technical problem. It is about understanding a design decision.

To me, the question "Why do mount points in Linux need to be existing directories?" splits into two parts:

  • Why do mount points need to be directories?
  • Why do mount points need to be existing files?

Neither of these circumstances make sense to me.

If we for now assume that mount points need to exist for some reason, clearly the VFS does something with them that the FS itself doesn't support. So why even bother checking whether a mount point is a directory? The only counter argument to this I can come up with myself is "Yeah, but what if an application has already determined that a certain path points to a directory?", to which I'd reply: "Well, if it only has the path then anything can happen with it anyway. Even without mounting, the next time it checks, that path might point to a directory. Or it might not exist anymore. If it has a file handle of it already, then no matter the mount, it will still have access to it."

The second part of the question makes even less sense to me. Again, the VFS is doing something the FS doesn't support. So why care what the FS says is there? Or if we decide to care, then why enforce that there is something rather than enforce that there is nothing? Sure, if there is nothing, then you have to tackle the question of what happens if someone tries to create something in this path. But this seems like a very simple thing to deal with. On the other hand, if we enforce that there is something, then always when there is a mount, a subtree of the FS one level higher up is hidden. This seems like it causes many other problems, including the inverse of the one problem we had before: What if someone tries to delete that something? But it also causes problems like "What if some process currently is navigating that subtree or its pwd is in that subtree?" and "What if space of the FS higher up needs to be freed and the files to be deleted are in that subtree?".

I'm not necessarily looking for the point where this design decision was made (though that would be interesting to know as I think it will go quite far back in time). I'm looking for the reasons why this design decision was made.

UTF-8
  • 3,237
  • 2
    A mount point can be a non-directory see https://unix.stackexchange.com/questions/503251/is-that-true-we-can-only-bind-mount-directory-to-directory-and-file-to-file Also, a mount point can't be deleted. The last few sentences of paragraph 4 are not understandable to me. – 炸鱼薯条德里克 Jun 25 '19 at 17:35
  • I'd say it follows from the "do one thing and do it well" philosophy - there're already tools to make directories and create files, so why have mount do that job too? – muru Jun 25 '19 at 17:37
  • If the mount point doesn't exist, what path would you use to access the mounted filesystem? – Andrew Henle Jun 25 '19 at 17:43
  • 1
    standard procedure to access a "covered" space is to bind mount (non recursive) a parent directory not covered elsewhere. Then the covered part is available at that new mount point (eg: https://unix.stackexchange.com/questions/4426/access-to-original-contents-of-mount-point) – A.B Jun 25 '19 at 17:57
  • @AndrewHenle The rule could be that the directory the mount point is in already has to exist. Lots of tools work like that. – UTF-8 Jun 25 '19 at 18:50
  • @A.B I know. The point is that mandating that a subtree be hidden complicates stuff. – UTF-8 Jun 25 '19 at 18:51
  • @muru The design option I talked about does not involve having the mount command create directories. – UTF-8 Jun 25 '19 at 18:52
  • It is not necessarily true that a mount point must exist before a filesystem can be mounted. ZFS, for example, does not require that a mount point has to already exist. If it doesn't exist, it will be created when the filesystem is mounted. – Jim L. Jun 25 '19 at 19:44
  • 1
    @JimL. anyone can make a mount wrapper / helper that mkdir -p the target first... strictly speaking you still mkdir because it has to exist first. Actually dropping the requirement would change a ton of semantics ... dependencies and permissions and how to discover mountpoints when reading directory contents doesn't include them... too many headaches to count – frostschutz Jun 25 '19 at 19:53
  • 2
    "Linux" didn't appear in a void. Many of the design decisions were just copied from Unix. A mount point should exist just as a variable should exist before being assigned a value. And just as a variable could be popped into existence (google for perl and autovivification) a directory could just be created automaticaly when used as a mount point. Look at the direct descendant of Unix and its mntgen(4) fileserver. Such a thing could be easily implemented in Linux now, either with fuse or directly in the kernel... –  Jun 25 '19 at 20:58
  • The design you talked about probably didn't exist at the time mount came into existence, and so is irrelevant to why mount is designed this way. – muru Jun 26 '19 at 00:08
  • 1
    [continuing my comment] ... A file system where directories are created as needed sounds intriguing, and the only way to really find out whether that's a good idea or not is to implement and test it. I wish you good luck in that endeavor ;-) –  Jun 26 '19 at 08:47
  • @frostschutz, that sounds like an answer. So does mosvy's comment. – Wildcard Jun 28 '19 at 00:10
  • @Wildcard No, those comments do not answer the question. I'm not asking why the directories aren't created automatically. I'm not asking what ways there are to create those directories automatically after the design of mount has been finalized. I'm asking why the virtual file system requires those directories to exist. This is about the corresponding design decision of the virtual file system. It's not about mount, about file systems, about anything magical slapped onto the whole thing. – UTF-8 Jun 28 '19 at 10:44
  • how can mount prevent typos without checking mount point exist? – alecxs Jan 04 '21 at 08:18

1 Answers1

1

In Unix, a directory is also a file, whose content is a list of the subfiles.

Assume that you are gonna mount /dev/sdb1 to /mnt/usb, and meanwhile /mnt is a empty directory.

If it's allowed to mount without an existing mounting point, After mounting:

  • You can access /mnt/usb
  • But in the list of /mnt there isn't an entry named usb.

This results in inconsistency.

So the mounting point must be an existing file to sync the /mnt's list. The exsiting file doesn't even have to be a dirctory, but can be a regular file either as well.

Zim
  • 189
  • I think your logic is somewhere close, but as written I think this is wrong. The Kernel could do anything it likes. IE it would be possible for the Kernel to patch in mount points to any file listing. It would have been possible for the kernel to have allowed mounting without existing files and without inconsistency. However . and .. both exist in the file system "for performance". Likewise I suspect the real reason is that searching for mount points every file listing would be too costly and therefore the logic is similar to your description, but for performance, not necessity. – Philip Couling Nov 10 '22 at 21:04
  • But after mounting /dev/sdb1 to /mnt/usb, if I list the contents of /mnt, there still is an entry saying "file usb points to inode 37", not "i know about a file usb but if you're looking for that, you can't continue here. go to inode 0 on file system /dev/sdb1". It seems to me that having fake information available is worse than having no information available and having to look somewhere else. – UTF-8 Nov 11 '22 at 07:58