Hi,
"Michael S. Zick":
> Several problems here with auFS on a 3.0.4 kernel.
>
> All I can say about the first two is they aren't
> expected based on the on-line man.html.
:::
> The first one is a simple case that the xino section of the manual
> does not mention that the external xino file must not exist at
> mount time:
:::
> [10481.277111] aufs au_xino_create:693:mount[4720]: open /auspace/auxino(-17)
(from the aufs manual)
----------------------------------------------------------------------
.B xino=filename
:::
The files are created per an aufs and per a branch filesystem, and
unlinked. So you
cannot find this file, but it exists and is read/written frequently by
aufs.
----------------------------------------------------------------------
I think "The files are created" is enough since the number 17 in the
message "open ... (-17)" is "17:EEXIST:File exists".
> [10620.585441] aufs au_opts_verify:1368:mount[4727]: first branch should be rw
:::
> Which looks like it would work but it does not.
The message is just a warning and the mount operations succeeded.
I am afraid you misunderstood the warning and the error.
> auplink:plink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
It means the versions of the aufs kernel module and aufs-util are
unmatched. You should upgrade aufs-util. If your distribution (Knoppix)
doesn't provide the matched version of aufs-util to the aufs kernel
module, then I'd suggest you to ask the distribution maintainer first
(still Klaus Knopper?) If you cannot wait for them to provide the
package, then you should get aufs-util.git and install it by yourself.
I guess you would notice that what you did (renaming aufs tools under
/sbin) is almost equivalent to uninstall aufs-util actually. :-)
----------------------------------------------------------------------
> The open call for the xino file needs to have "truncate if exists" rather
> than error exit.
No, I don't agree.
Let's consider the case when user specifies some important file to
"xino=" accidentally, and aufs truncate it. The user never be able to
recover the file, it is totally gone. Comparing the simple case where he
runs "rm /important/file" accidentally, in the "rm" case he can blame it
on himself with shouting "Idiot, idiot. Idiot Me!" because it is obvious
that "rm" removes the file. in the "xino=/important/file" and if aufs
trucates it, he will never blame to himself. Instead he will say "Aufs
should never remove/truncate the "xino=" file! Damn it! Just make it an
error!!" because new users don't know what xino is and never expect the
file is gone.
> The triggering of the "first layer must be rw" dmesg needs (your choice):
> Fixed, if that isn't a requirement
> Prevented from doing the mount if it is a requirement
> Note: Since the documents say an auFS stack will work without a rw layer, I
> don't see how
> it can be a requirement that the first layer be rw. ;-)
It is necessary because some files (on the topmost readonly branch)
becomes readonly and you cannot modify it. Aufs cannot determine it is
intentional operation, so make just a warning.
If you mount aufs itself as readonly, then the warning will not
produced.
J. R. Okajima
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
