Mr. Junjiro R. Okajima, Mr. Michael S. Zick, thanks for your answers concerning the AUFS kernel messages.
Mr. Michael S. Zick,
thanks for your contributed code snip and your notes concerning
pam and gvfs. I put the wrapper code into my trick box.
Thanks again for your engagement.
Mr. Junjiro R. Okajima,
after your last letter I took a second glance at the script
journal-commit.
1. Kernel messages
The pivot element of the script is the shell function
handle-filesystems(). The function reads in a row of the file
/proc/mounts or /proc/self/mounts. On my system /proc/mounts is a
link that points at /proc/self/mounts. The function use the contents
of the field FSTYPE to create a function name with the prefix
handle_ and the suffix ${FSTYPE}. If the contents of the field
contains the string ext3, ext4 or aufs as example it creates the
function name handle_ext3, handle_ext4 or handle_aufs. Two of the
three function names have functions in the script journal-commit.
These are the shell functions handle_ext3() and handle_ext4().
The function command_exists() in the do while loop of the function
handle_filesystems() checks the existence of a function name with
the prefix handle_ and the suffix ${FSTYPE}. If the function is a
member of the script journal-commit the script continues the
execution with following line. If not the script reads in the next
line from /proc/mounts.
The consequence is, the script only calls the command mount, if it
has found one of the FSTYPE ext3 or ext4 in the file /proc/mounts.
The script does what it shall.
Please take a look at the file proc_self_mounts.log. The file is
located in the attached tape archive email-attachment-06.tar.gz.
For the following discussion keep in mind that I called the script
journal-commit in the chroot environment. If I call mount in that
environment to remount the ext3 file system with the option commit,
mount can't see mounts like /tmp/jailcache.ro.var. The command mount
sees only the mount /var. This concerns all the following rows from
the attached file proc_self_mounts.log:
/dev/disk/by-uuid/f71d3... /tmp/jailcache.ro.root ext3 ...
/dev/sda11 /tmp/jailcache.ro.var ext3 ...
/dev/sda9 /tmp/jailcache.ro.usr ext3 ...
/dev/sda10 /tmp/jailcache.ro.usrlocal ext3 ...
/dev/sda6 /tmp/jailcache.ro.home ext3 ...
/dev/sda12 /tmp/jailcache.ro.srv ext3 ...
The question is, why AUFS reacts during the remount of the ext3 file
system and produce the kernel message?
Maybe it could be a good idea to look again over the source code of
AUFS.
The following rows from proc_self_mounts.log doesn't produce a
kernel message:
/dev/disk/by-uuid/f71d3... / ext3 ...
/dev/sda6 /home ext3 ...
/dev/sda7 /opt ext3 ...
/dev/sda12 /srv ext3 ...
/dev/sda8 /tmp ext3 ...
/dev/sda9 /usr ext3 ...
/dev/sda10 /usr/local ext3 ...
/dev/sda /var ext3
Again, in my opinion, I can't blame the script journal-commit. The
script doesn't generate the kernel message.
Maybe the script shouldn't read the inputs from /proc/mounts but
from /proc/self/mountinfo. The file /proc/mounts shows all mounts of
the system. The file /proc/self/mountinfo shows a different view of
the mounts. As example have a look at the attached files proc_self_
mountinfo-in_aufs.log and proc_self_mountinfo-out_aufs.log. The
first file shows the mounts in the chroot environment and the second
file was taken outside the chroot environment.
The file proc_self_mountinfo-in_aufs.log shows only the unions and
no ext3 mounts. This could be a solution, but I don't know the side
effects. Sure, if this is a solution we must convinced the developer
of the pm-utils.
In my opinion, the kernel message isn't caused by the script journal-
commit. Again, the script does what it shall. The script remounts
only file systems with the type ext3 and ext4. That answers your
first suggestion.
It is surely a good idea to look after the reason why the kernel
displays the message. It seems that AUFS stumbled about something
during the remount procedure and the reason for that should be
known. I think, if you know the reason, you could forbid AUFS
the print of the message. That answers your second suggestion.
2. aubusy
- The test of the new aubusy version was successful. I used aubusy
from your git repository aufs3.0 downloaded at 2012-03-26.
A little star and all goes as it shall. Thanks
- Feature request concerning a list function for aubusy. Could I
convince you to provide a list function for aubusy. Something that
mount does if we invoke mount without any option. The pure mount
command shows all current mounts. The tool aubusy should show all
current union and their branches like the following example:
$> sudo aubusy
or
$> sudo aubusy -l
The output could be the following list:
union: /tmp/jail
br0: /tmp/jailcache.ro.root
br1: /tmp/jailcahce.rw.root
union: /tmp/jail/var
br0: /tmp/jailcache.ro.var
br1: /tmp/jailcache.rw.var
:::
This gives us a first and comprehensive overview. The list helps to
run aubusy with the correct union and branch options.
I would be very glad, if you could find some time to answer my
questions. Thanks a lot in advanced.
Regards,
Robert Wotzlaw
Attachment:
1. Tape archive email-attachment-06.tar.gz
- proc_self_mounts.log
- proc_self_mountinfo-in_aufs.log
- proc_self_mountinfo-out_aufs.log
email-attachment-06.tar.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
