[Unionfs] Can't make branch read only

[Erez Zadok]

In message <m3myu98zsb.fsf at dynamo.mandriva.com>, Olivier Blin writes:
> Erez Zadok <ezk at cs.sunysb.edu> writes:
> 
> >> - mount -t unionfs -o remount,mode=/live/foo=ro none /live/union
> >> 
> >> The last command, while should switch the branch to read only mode as the
> >> documentation specifies, doesn't work, the branch /live/foo continues to be
> >> read-write, and if you write something to /live/union you confirm this as there
> >> will be still writes to /live/foo (and /proc/mounts continues to show /live/foo as
> >> rw too). Any ideas?
> >> 
> >> I tried this with unionfs 2.1.3 and also with 2.1.7 but with same results.
> >
> > Herton, you cannot set the leftmost branch to be readonly, in a union
> > mounted read-write.  If the union is mounted read-write, then the leftmost
> > branch must be writeable, to allow copyup.  If you want to set the leftmost
> > branch to readonly, it is the same as saying that you want the whole union
> > to be readonly.  In that case, remount your entire filesystem readonly:
> >
> > # mount -t unionfs -o remount,ro none /live/union
> 
> Our use case is / as union, so we can't really remount the union
> read-only (it's busy).
> 
> We used to be able to make the lefmost branch read-only with unionfs
> 1.x, even if the union was writable.
> This allowed to boot with a tmpfs as rw branch of the / union, ask for
> some settings, remount the tmpfs branch ro, safely copy the changes
> from tmpfs to a new directory (on disk), and add this new directory in
> the union with rw mode.

OK, I see what you want to do.  But first, I'd like to understand what's the
scenario in which you want to preserve copied up files from a tmpfs?  I
mean, if you made it a tmpfs, then you knew it wasn't going to persist, so
why preserve it elsewhere?  If you didn't have a persisten storage before,
how come there is one now (maybe a usb device was inserted?).  I'd like to
understand your usage goals and motivation.  Maybe I can find a better way
to achieve the same goal.

Changing unionfs 2.x to allow a readwrite union, where the leftmost branch
is readonly, isn't hard -- it's a couple of lines of code removed.  BUT,
that'll open up a new problem: since the VFS thinks the union is writeable,
it would allow user processes to modify files in the union.  But if there is
a writeable branch, what should unionfs do?  Should it block the processes
from modifying files until the leftmost branch becomes writeable again?
That'll be a considerable amount of complicated code plus it could cause a
lot of possible system processes to hang (imagine anything that needs to
write to /var/log files).  Or should unionfs just return EROFS/EACCESS
instead?  That is sure to break applications.

There's a cleaner way, I think.  Create a new small tmpfs branch while
marking your desired branch readonly, copy your files safely, then remove
the top branch and remark your desired branch readwrite.  The only thing is
that you'll need to check if any copyup had taken place while you were
copying your data and if so, sync it back.  It'd look something like this:

mount -t tmpfs -o size=NNN /live/new
mount -t unionfs -o remount,add=/live/new,mode=/live/foo=ro none /live/unionfs
# copy your files out of /live/foo
mount -t unionfs -o remount,del=/live/new,mode=/live/foo=rw none /live/unionfs
# check if there's anything in /live/new you want to preserve

The last action is a bit racy, in case changes are being made to the union
after the last remount command; if so, you have a classic 3-way diff problem
to merge.  So if this raciness is unacceptable, then we're back to the above
question: what semantics would be required if processes try to write to a
writeable union that has no writeable branches?

Cheers,
Erez.