On 5/13/2013 1:34 PM, Andrew Deason wrote: > On Fri, 10 May 2013 13:05:34 +0200 > Christof Hanke <[email protected]> wrote: > >> As for your general problem, >> we've set up a special machine called "afsrw", where we mounted a >> special "root.cell.rw" volume, which has no RO-copies. >> Like this, we are always in the RW-Path on that machine and can >> perform the "make install" into the RO-PATH. > > Yeah, this is one way to achieve this. From discussing with Arne, I > believe that that approach is undesirable because it requires an > administrator to create (and maintain) such a 'root.cell.rw' volume. > Having a separate startup option to afsd to just mount the root vol RW I > think has a few advantages: > > - It doesn't require anything from an administrator > - It works/could work for -dynroot > - It means you don't have to maintain two separate root volumes (if > they ever change for whatever reason, or if you move them around, > etc) > > It also just seems a bit silly to me that you can currently say that > /afs can point to any volume anywhere in AFS space, but if it has any RO > copies, you must use the RO. From a user perspective, it just seems like > such a weirdly specific restriction. > > The only downside I am aware of is possible confusion that /afs points > somewhere else. But it seems much more clear to me than the current > practice of pointing -rootvol somewhere else. If someone uses some silly > name like '-rootvol root.afs2', it's not very clear what is being done > or why; since what it's doing depends on the contents of 'root.afs2'. > But if you have something like '-rwrootvol', that always means that we > want an RW /afs, regardless of cell/volume contents.
I have no objection to a change to explicitly mount the rw instance of a volume as /afs. That is not what was proposed in the patch to gerrit. The patch to gerrit modifies the volume selection semantics for all volumes. I would also have no objection to a patch that permits dynroot to explicitly mount the rw instance of root.cell provided that the behavior can be specified on a per mount basis. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
