The mini_fo filesystem

Posted May 21, 2005 6:03 UTC (Sat) by AnswerGuy (guest, #1256) [Link]

I don't know the answer to that question in this case, but consider that
a "rename" is really series of link and unlink operations (at the system
call level). Also a directory is a type of file (a list of link/inode
pairs).

Given those semantics I'd guess that a "rename" would unlink on the
top/writable layer (writing a version of the directory that did NOT
contain the link in question) and a link (possibly to that same directory
possibly to another) resulting in more writes to the writable layer.
This wouldn't affect the underlying inode (but that would probably
be copied up from the lower layer to the write layer because the
link count was incremented and then decremented).

So know I have one or two directory "files" that contain updated
contents (like any other file that got copied up to the writable
layer). The ls command (and other readdir() operations) will show
the copy of the directory that does not contain the old name and does
contain the new one.

Is this making any sense?

I do have to wonder what happens if you have multiple layers that are
writable and mounted in multiple places (bind mounts of some layers
outside of the stack). That sounds ugly.

Posted May 22, 2005 12:28 UTC (Sun) by markus78 (guest, #30082) [Link]

Renaming works differently for directories and non-directories. For example renaming a regular file will result in the file beeing marked as deleted (whiteouted), and then copied up to the storage branch with the new name. From now, renaming this file again will really only rename it in the storage branch.

Renaming directories is a lot more complicated, because we don't want to copy up all directory contents (by the way, this is what "mv" does when a file system's rename function returns -ENOSUPP). So what happens is that the original directory is whiteouted, a new empty directory with the new name is created in storage and both directories are associated by a special meta tag that is saved in the meta-data.

If you rename that directory in the underlying file system while the mini_fo file system is not mounted (you should not do this while it is mounted, see above post), this association will be broken, as mini_fo has no way to "detect" changes that occured while not mounted.