Thanks for the response.
My knowledge of Unionfs and Aufs is very basic.
In the 'init' script in the initramfs I currently
have this:
mount -t aufs -o udba=reval,dirs=${UMNT1}${UMNTRO} unionfs /pup_new
Which in the case of booting from USB Flash drive
resolves to:
mount -t aufs -o udba=reval,dirs=/pup_rw=rw:/pup_ro1=ro:/pup_ro2=ro unionfs
/pup_new
Where /pup_new will be the '/' after switch_root,
/pup_rw has a tmpfs in RAM,
/pup_ro1 is a ext2 file that files are saved to,
/pup_ro2 is all the Puppy filesystem.
It looks like a later version of Aufs will fix
that problem of the .wh._dir_opaque files, which
is great!
I think that I read in later versions you have dropped the Unionfs
compatibility, so I will have to modify the above line that creates the aufs
union?
Note, the above situation is only for Flash
memory. In the case of the "save" file being in
hard drive, we don't have the tmpfs layer, just
these two:
/pup_rw has the ext2 save file
/pup_ro2 has the Puppy filesystem (squashfs)
Note also, we can also have additional squashfs
files that are combo-packs of applications that
can mount on lower layers. For example, we have
a C/C++ compiler "SFS" file. I am allowing up to
three extra layers, mounted on /pup_ro3, /pup_ro4
and /pup_ro5 -- too many and I guess we will get
degradation of performance.
Everything gets mounted before switch_root, there
is no remounting or maniplution of the branches
while Puppy is running.
Regards,
Barry Kauler
www.puppyos.com
--------- Original Message --------
From: [EMAIL PROTECTED]
To: Void <[EMAIL PROTECTED]>
Cc: [email protected]
Subject: Re: Want hack to prevent .wh.__dir_opaque creation
Date: 23/04/2007 11:55
>
>
> Hello Void,
>
> "Void":
> > Hi, I'm one of the lead developers of the Puppy
> > Linux project. I've just gone over to using Aufs
> > from Unionfs, and using CVS 20061125, with the
> > compatibility turned on, so the directory opaque
> > files are named '.wh.__dir_opaque' -- which I have
> > done as have scripts that directly delete these
> > files at bootup before the aufs is mounted, and I
> > have not yet modified them for the new whiteout
> > filename.
>
> I'd like to suggest you to use the latest aufs.
> Do you have any special reason to use such old aufs?
> And it is not recommended to handle whiteout directly in general.
> I don't know why you need to remove whiteout for diropq, but this aufs
> mount option may help you,
> (quote from <aufs CVS tree>/Histroy)
> ----------------------------------------------------------------------
> 20070129
> - introduce diropq option.
> the behaviour of mkdir(2) and rename(2) dir case is changed. now they
don't
> make '.wh..wh..opq' when it is not necessary. this is the default. if
> you dislike this behaviour and still want to make it always, use
> 'diropq=always' mount option. see the manual in detail.
> ----------------------------------------------------------------------
>
>
> > When boot from usb Flash, the top layer is a tmpfs,
> > next down is a file with ext2 f.s. in it mounted by
> > loop device. We flush the top layer (branch) down
> > to the save layer periodically, which is a mechanism
> > to minimise writes to Flash drive.
>
> If you set '=ro' to the branch on Flash drive, aufs will not write
> anything to Flash drive.
> Additionally, unless you specify '=ro+wh', aufs will not lookup
> any whiteouts including diropq.
>
>
> > I'm using 'udba=reval' but I can't do a true
> > flushing, in some cases can onl copy files down to
> > the "save" layer. The two exceptions that prevent
> > flushing are:
>
> Do you mean that you mounted aufs as,
> - /aufs = /rw(tmpfs) + /ro(loopback ext2, backend is on flash)
>
> and execute such like this periodically?
> - mv /rw/* /ro/*
>
> Then, you should try 'udba=inotify' mount option.
> Actually, I had an idea to develop similar feature as a mount option,
> which will copy/move files between branches. But it is still just an
> idea...
>
> I guess your script which will be executed periodically will be such
> like this (I didn't test it),
>
> mount -o remount,udba=inotify /aufs
> mv /rw/* /ro/*
> mount -o remount,udba=reval /aufs
>
>
> > 1. hidden directory.
> > If I copy a file down to "save" layer then delete
> > it on tmpfs layer, Aufs does not recognise this
> > if there is a hidden directory in the path.
>
> Unfortunately, I could not get what you meant. What do you mean "a
> hidden directory"? Will you show me the actual example?
>
>
> > 2. New directory.
> > This has been our curse for so long, the creation
> > of .wh.__dir_opaque files when a new directory is
> > created. I know it is a POSIX standard, but in
> > Puppy it is just a headache and in the case of
> > booting from Flash we just don't save them.
>
> Please try newer aufs or 'diropq' mount option.
>
>
> > In the Flash case, the problem is in the current
> > session, if say install a package that creates
> > directories, we cannot flush from the tmpfs layer
> > down to the save layer as Aufs refuses to look
> > at new directories created directly in the save
> > layer. After a reboot it is okay as we don't
> > save the .wh.__dir_opaque files.
>
> You need to use 'udba=inotify' or discard dentry cache (cached
> filenames). Try newer version of aufs and read the manual.
>
>
> > So, my question, and this is something I want
> > very much to do, is where in the source can I
> > comment-out the part that creates the
> > .wh.__dir_opaque files?
> > I had a quick look at the source and couldn't see
> > where, so could someone familiar with the code
> > kindly advise me how to do this?
> >
> > Of course, if this could become a configure option
> > that would bereally great!
>
> I don't understand what option you want, but I can tell you about source
> code.
> In the latest version,
> - do_diropq():fs/aufs/whout.c handles .wh.__dir_opaque file.
> - aufs_mkdir():fs/aufs/i_op_add.c and do_rename():fs/aufs/i_op_ren.c
> calls
> create_diropq() --> sio_diropq() --> do_diropq()
>
>
> Junjiro Okajima
>
>
>
>
________________________________________________
This message was sent
using Dodo Webmail - www.dodo.com.au
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
