I’ve been playing with the Beaglebone and Beaglebone Black once again. To increase the longevity of the SD card media it would make sense to have a read-only root filesystem. While it is not that hard to have a strictly read-only root filesystem, it would be nice to have the features of a union filesystem, where writing is not prohibited, but writes are directed to a dedicated filesystem (such as ramfs or another partition).
Hence the quest for an OverlayFS patch!
Having spent a while looking at a various choices of union filesystems, OverlayFS seems to be most promising as a long term solution. But trying to find a patch for OverlayFS it appears that all development is being done on a git repo, no patches to apply to any kernels.
The OverlayFS patches are in the Github overlayfs-patches repo. Here is how I created the patches.
First clone the linux-stable kernel repo.
If there is an existing local kernel repo then cloning a shared repo is a space saving option.
With the Linux kernel stable git repo on hand, fetch the OverlayFS. This will get us all of the OverlayFS branches into our current repository.
Now that we have the remote branches for OverlayFS available we need to find where the branch of interest started. Let’s say we desire to get a patch for the overlayfs/overlayfs.v20 branch. We will need to know where exactly this branch originated on the kernel source tree. Otherwise a diff will get us a lot of changes that are not at all related to OverlayFS. The merge-base command will result in a git object that is the most likely common point, the merge base, of the two branches we specify in the command.
With the git object on hand we can now create the patch file.
Lastly, the git-diff(1) manual page outlines a single command that is a shortcut for the above ‘merge-base’ and ‘diff’ sequence.
git diff [–options] … [–] […] This form is to view the changes on the branch containing and up to the second , starting at a common ancestor of both . “git diff A…B” is equivalent to “git diff $(git-merge-base A B) B”. You can omit any one of , which has the same effect as using HEAD instead.
So we can do this instead.
One final step remains, examine the patch to make sure we only have OverlayFS relevant code in there. It would also be nice to see what the base of the patch is in human readable form. Start by examining the log as to where the merge base of the overlayfs/overlayfs.v20 is.
Now we know that the base of the overlayfs/overlayfs.v20 branch is the 3.12-rc2 release of the Linux kernel source. With this much more friendly git reference we can now checkout that release and try our new patch.
And the result is:
Without examining the patch in details I would conclude that the patch includes all and only the parts relevant to implement OverlayFS on the v3.12-rc2 Linux kernel release.