> Date: Mon, 1 Nov 2010 16:15:04 +0100
> From: a...@knopper.net
> To: i...@aerobiology.ca
> CC: damonswir...@hotmail.com; aufs-users@lists.sourceforge.net
> Subject: Re: ro first branch
>
> Hi Ian & list,
>
> On Mon, Nov 01, 2010 at 09:23:19AM -0400, Ian Stakenvicius, Aerobiology
Research wrote:
> >
> > On 30/10/10 10:50 PM, nomad Bellcam wrote:
> >
> > > Date: Sat, 30 Oct 2010 22:35:19 -0400
> > > From: [1]...@aerobiology.ca
> > > To: [2]damonswir...@hotmail.com
> > > Subject: Re: ro first branch
> > >
> > > On 30/10/10 09:26 PM, nomad Bellcam wrote:
> > > > hello,
> > > >
> > > > it is unclear to me from the docs and man page whether is is
possible
> > to
> > > > have a rw aufs file system with a ro "first (upper-most) branch. the
> > man
> > > > page says "The default branch permission for the first branch is
ârwâ,
> > and
> > > > the rest is âro.â" and "When you mount or remount your union
without
> > âo ro
> > > > common mount option and without writable branch, aufs will warn you
> > that the
> > > > first branch should be writable." but i cannot find any more info
> > regarding
> > > > this.
> > > >
> > > > what i want to do is this:
> > > >
> > > > mount -t aufs -o br:one=ro:two=rw none base
> > > >
> > > > this works, but when i try to write to base i cannot (ro file
system).
> > i am
> > > > not sure why aufs will not simply write to "two"
> > > >
> > > > if this is not possible, what is the best solution for keeping "one"
> > at the
> > > > top of the stack? i thought of making a dummy empty directory an
> > mounting
> > > > it like this:
> > > >
> > > > mount -t aufs -o br:dummy=rw:one=ro:two=rw none base
> > > >
> > > > is this the recommended way?
> > > >
> > > > sincerely,
> > > >
> > > > proctor
> > >
> > > What's the end goal of this, exactly? I mean, why can't you mount -o
> > > br:two=rw:one=ro ?? No matter what, the read-write branch -must- stand
> > > on top of the reference (read-only) branches, as that's the only way
for
> > > it to actually work like a regular fs whenever a change is made.
> >
> > > What's the end goal of this, exactly? I mean, why can't you mount -o
> > > br:two=rw:one=ro ??
> >
> > what i am trying to accomplish is mounting user-defined changes to a
file
> > system from a live-cd (knoppix).
> >
> > i want to be able to make changes to the base knoppix system (using a rw
> > aufs overlay on e.g. usb stick).
> >
> > then i want to burn the resulting "changes file" to the dvd and mount
them
> > from there. since
> >
> > they no longer reside on a writeable media i must use "ro" (i believe).
but
> > i still require them to
> >
> > be the "highest level changes" made to the system at that point.
> >
> > with "one" being my custom changes and "two" being the base knoppix
system,
> >
> > i can do
> >
> > br:two=rw:one=r
> >
> > but (i believe) any files that are in both "one" and "two" would only be
> > visible in "two" (the highest level overlay)
> >
> > in this case. is this assumption/understanding correct?
> >
> > OK so to reiterate:
> > - You have the livecd (i'll call it 'x')
> > - You have your user-defined changes to the livecd (i'll call it 'y')
> > So firstly what you're doing is you mount -o br:y=rw,x=ro to make the
image
> > for 'y', right? Then you burn it to DVD, so that it becomes read-only.
> > So then what you need, if I'm understanding this properly, is a -third-
fs
> > (say, a tmpfs) 'z' that serves as your rw branch when you're using the
dvd.
> > Then you can mount -o br:z=rw,y=ro,x=ro ... it will be up to you whether
or
> > not any changes in 'z' get written back to 'y' or not.
>
> I believe that what you are attempting to do, is already implemented in
> Knoppix. Please have a look at minirt.gz's /init:
>
> mountunion(){
> local dir tree=""
> for dir in /KNOPPIX /KNOPPIX[0-9]; do
> [ -d "$dir" ] && tree="$dir=ro${tree:+:$tree}"
> done
> mount -t aufs -o "br:$1=rw:$tree,noplink" unionfs /UNIONFS
> return $?
> }
>
> mountunion() supports incremental overlays, i.e. the filesystem mounted
> as /KNOPPIX is the base, /KNOPPIX[0-9] are changes vs. the base and vs
> each other in ascending order, and the only argument to mountunion() is
> the ONLY writable branch, either ramdisk or a read-write on-disk image
> that's mounted somewhere.
>
> Don't worry about "unionfs" here, it's just naming because of historical
> reasons.
>
> Now, if you want to record your changes from, let's say /ramdisk, to
> another read-only image, you would do a
>
> mkisofs -R /ramdisk | create_compressed_fs - 65536 > /tmp/KNOPPIX2, and
> put the resulting file on your new DVD master directory into the KNOPPIX
> folder. On next boot, KNOPPIX/KNOPPIX2 will be read-only mounted as
> /KNOPPIX2, and mountunion() will stack your changes there on top of the
> base image and put the read-write branch on top of that.
>
> If you would like to do this without rebooting, you have to call the
> full mount -t aufs command with all branches and with /UNIONFS as target
> mountpoint, which will shadow the previous mount. In theory, a "-o
> remount" with the additional branch in the "add" option, should also be
> possible, but it never worked for me, maybe because of existing process
> references to the previous stack.
>
> Does this cover your desired scenario? You will again only need one
> single writable branch, but have several read-only branches which are
> stacked in reverse order of creation.
>
> Regards
> -Klaus
hello klaus,
as a matter of fact, yes this does cover my desired scenario. i have read
mountunion() in some detail
as in fact it is the very function that i intended to modify once i learned
the correct method to use. as far
as i can tell, this KNOPPIX[0-9] functionality is otherwise undocumented,
and one of the reasons i was
unsure of it's true use is the fact that as far as i understood, EITHER
/KNOPPIX-DATA (as a mount point of
knoppix-data.img) OR /ramdisk was always mounted in the "0 position" in the
aufs. i had feared that
the data in /ramdisk might overwrite important data in the /KNOPPIX-DATA
position if i used it as
you described above, and so avoided using it in that manner. upon better
inspection however, i see
that there is actually hardly any data in /ramdisk after booting the system,
and what is there is mostly
due to the auto-detection system.
i shall use the /KNOPPIX[0-9] functionality unchanged for my application.
thank you very much to ian, j. r. okajima, and klaus for your attention to
this matter. you have each
contributed much to my understanding of this matter.
sincerely,
proctor
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
