T o n g:
Ok, it seems to work at the first glance, but it will fail in real world.
Because --max-delete=0 completely disable file deletion, if there is any
modification to the files in ro_mid branch at the RW level, the script
will fail.
Did it really fail on your side?
In the previous
Thayumanavar Sachithanantham:
i downloaded the 2.6.27 git with aufs source from aufs.sourcforge.net
and had been unable to hit the issue so far. i will continue to test
and provide the info. once i can recreate this issue. Also i am unable
to recreate the issue with the custom kernel.
Ok.
I
Hi Tomas,
Tomas M:
It was my pleasure to double all your donations for AUFS, but you know, life
is changing, all good things have to come to an end. So, August 2010 is the
last month I'm going to double your donations.
OK.
I really appriciate all your supports.
For those folks who
Hello Roopesh,
Roopesh:
I am getting the following crash when I run heavy IO and delete branches at
the same time. I have the attached patch applied to the july first week
release. This patch was sent to me from another discussion in this mailing
list. The config and disassembly of au_do_pin
T o n g:
Ok, I meant to ask, are CONFIG_SYSFS and aufs module parameter brs
compile-time feature, or it's controllable at mount commandline?
$ dmesg | tail -1
[1850101.149904] aufs au_opts_parse:1009:mount[12747]: unknown option
brs=0
You are just confusing the mount option and the
T o n g:
If it should be /dev/shm/tmp_real/u, why aubrsync is complaining that
/dev/shm/tmp/u is not mounted here? IMHO, aubrsync should check the
real path /dev/shm/tmp_real/u instead of /dev/shm/tmp/u.
It might be your shell that returns /dev/shm/tmp/u.
Try
$ cd /dev/shm/tmp/u
$ pwd
$
T o n g:
It works fine.
Thank you for your tests.
The patch will be included in next Monday release.
J. R. Okajima
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry
T o n g:
Ok, 'brs' is a module parameter. All that I wanted to ask is, is it
a compile-time feature? Can I use it to control showing those
info at run time? If yes, how?
modprobe aufs brs=1
--
This SF.net email is
T o n g:
Thanks a lot. To show those xino=...,br:... info, I need to set brs=0,
right?
:::
Anything else that I should look into?
/proc/mounts
and
make sure aufs2-util is installed correctly.
--
This SF.net
T o n g:
$ tail -1 /proc/mounts
none /dev/shm/tmp_real/u aufs rw,relatime,si=a5a2917949144a2e 0 0
If it doesn't show br:.. regardless the module parameter brs, then it is
a problem of aufs. But I am afraid you didn't specify the parameter.
make sure aufs2-util is installed correctly.
I'm
T o n g:
$ lsmod | grep -i aufs || echo no found
no found
% modprobe aufs brs=0
$ lsmod | grep -i aufs || echo no found
no found
You may not have the aufs module. If you (or your distributor) build
aufs statically, then you need to specify the parameter in the kernel
command line.
You may
Jordi Pujol:
I believe that the problem is some incompatibility between the hard disk =
filesystem and the aufs write routines, as write locking-unlocking, =
If you are right, then aufs + ext4=rw will always be a problem.
Hmm, it is hard to agree.
J. R. Okajima
Jordi Pujol:
now I see that aufs does not compile with debug activated,
CC [M] fs/aufs/super.o
/home/JPLive/git/linux-2.6/linux-2.6.33-7.rt29.jpp.4-
lnet/debian/build/source_amd64_rt/fs/aufs/super.c: In function=20
=E2=80=98au_remount_refresh=E2=80=99:
Jordi Pujol:
Yes, sorry I was wrong,
now I try to compile rt25 adding also the first patch, and it not compiles,
the lock seems per_cpu, but the realtime code does not work by cpu,
the functions vfsmount_read_lock and vfsmount_read_unlock are only defined in
the rt23 patch.
the rt25 and
Jordi Pujol:
I have done a modified patch for the rt29,
it includes the patch for 2.6.33-rt10 from:
http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg02512.html
and the mtx patch also,
Yes, only these two patches are what you need for rt25.
I have never tried rt29.
The
Jordi Pujol:
The resulting Debian source package is available in the following URL,
everyone can download to modify and compile it,
http://livenet.selfip.com/ftp/debian/linux-2.6/linux-2.6.33-7.rt29.jpp.4-lnet/
Jordi,
It is ok to modify or combine my patches and create a new one for
Jordi Pujol:
I see that the link for the uloop code on the aufs web page,
aufs.sf.net, does not work,
To add more samples to aufs2-util and aufs.sf.net is still on my todo
list, sorry.
There is some time I did a Debian package for uloop, adding some
modifications
and utilities of my
Daniel Vidal:
The Team of MUSIX distro is working on 3.0 version and have the idea of
build 2.6.33.7 RT kernel... I read this tread and have a question... Now on
the aufs repo exists unofficial code of the aufs-rt patch?
As I wrote in another mail a few days ago, since Merten Lipkowski posted
Lou Gosselin:
Sorry for the delay.
I did give this a shot. It's definitely closer but still doesn't
pinpoint the blocking process for all scenarios.
If it output the process id(s) which caused it to fail it would be
perfect and it wouldn't require aufs to be compiled with debug to parse
Lou Gosselin:
Thanks for responding.
I agree that normally mount syscalls don't bother telling us anything
about what's causing them to block.
Let me counter that by saying this process-parition lock ambiguity is
unique to aufs.
Agreed.
So aufs prints additional info at remounting.
Lou Gosselin:
Yes, but it lacks sufficient information to identify the exact
process(es) blocking the operation.
Then let's think about the sufficient info.
You might remember my old reply.
--
Do you mean that you want to
Christopher Hull:
It would appear that the si_pid_set_slow function or something it calls
has an issue. It appears that this function is only called when pids
are allowed to exceed the default maximum of 32768, which is only
allowed on 64bit kernels.
Unfortunately I cannot reproduce the
Lou Gosselin:
I'm speculating here: my guess is that the VMM is pointing to a struct
inode which has been copied up by aufs into a new inode, but the VMM
continues to refer to the old one. The new and old struct inode continue
to share i_ino #. If this is the case, would it be possible to
Lou Gosselin:
I'm speculating here: my guess is that the VMM is pointing to a struct
inode which has been copied up by aufs into a new inode, but the VMM
continues to refer to the old one. The new and old struct inode continue
to share i_ino #. If this is the case, would it be possible to
sf...@users.sourceforge.net:
Thayumanavar Sachithanantham:
i downloaded the 2.6.27 git with aufs source from aufs.sourcforge.net
and had been unable to hit the issue so far. i will continue to test
and provide the info. once i can recreate this issue. Also i am unable
to recreate the
Hello Audrius,
Audrius aiknas:
What I would like, is for the files to remain in their current branches
even they were modified.
Is there such feature implemented?
How about copyup= mount option?
(from the aufs manual)
--
Hello all,
I have a plan to stop supporting old kernels, 2.6.32 and earlier.
Because it is being very hard for me and takes very long time to support
them. I know 2.6.27.xx series are still maintained, but I don't know
when it ends.
If you have any argument about it, please let me know.
All
o news
- a new aufs patch for 2.6.33.5-rt25.patch is added into
aufs2-standalong.git#aufs2-33.
- in mainline, fsnotify refined much and inotify is removed.
aufs simply follows it and removes inotify support which was
deprecated a few months ago.
Note: there are several bugs reported in
sf...@users.sourceforge.net:
Christopher Hull:
It would appear that the si_pid_set_slow function or something it calls
has an issue. It appears that this function is only called when pids
are allowed to exceed the default maximum of 32768, which is only
allowed on 64bit kernels.
Audrius aiknas:
1. There is a folder which I seem can't rename into a specific name:
$ mv 4.0 XXX - OK
$ mv XXX 5.0 - OK
$ mv 5.0 6.0 - BAD
Please give me these info.
(from README)
--
When you have any problems or
Thanks all who replied this issue.
Thomas Sachau:
I would suggest to follow the kernel maintainers. So if they support 2.6.=
27, keep support for it, at
That sounds reasonable.
Also I received a mail saying several distoribution will release .32.
Honestly speaking, I don't like 2.6.32 since
Hello David,
David Mudrich:
Aufs seems to trigger a kernel BUG() with an NFS writable branch.
I already asked the linux-nfs mailing list, they point me to AUFS.
Refer to the discussion below.
If you need more information, please ask.
Give me these info.
(from aufs README)
wiebittewas:
[ 1179.190965] BUG: MAX_LOCKDEP_SUBCLASSES too low!
::
well, the problem, which occures in kernel/lockdep.c, seems to be
solved easily by increasing a value, but a short look at the code
has shown, that it's not that easy (at least for me without full
knowledge of this
arthur.wang:
I use aufs-utils to protect the rootfilesystem. When commit
changed file to real disk sector through aubrysnc, nothing valid.
Aubrysnc tools will remount the root point, aubrysnc tells that mount
: / is busy. Does aufs must remount aufs read only branch?
If aufs do it
o NEWS
- Begin of aufs2.1.
The branches for linux-2.6.30 and earilier are not maintained.
Other branches are renamed, aufs2-xx -- aufs2.1-xx.
- aufs2-util GIT tree
A new branch aufs2.1 is essentially necessary for aufs2.1.
- Development status
In aufs2-2.6.git and aufs2-standalone.git,
Hans-Peter Jansen:
after moving from 2.6.34.5 to 2.6.34.7, I suffer from crashes like this:
Sep 20 03:51:37 tyrex kernel: [18169.930270] [ cut here ]--=
--
Sep 20 03:51:37 tyrex kernel: [18169.939562] kernel BUG at /usr/src/package=
Hello Kirk,
kirk w:
Does AUFS2.1 support 2.6.36? I tried a couple weeks ago and it would not
compile.
Unfortunately I don't have enough time to keep sitting in front of my PC
in these months and I can only make very small steps forward.
While I am not sure when it will be, I am trying to
Hello George,
Yioryos Asprobounitis:
However, trying to compile aufs-utils in puppy against this kernel/headers
(gcc4.4.3) it fails at plink with:
cc -I./libau -O -Wall -c -o plink.o plink.c
plink.c: In function 'au_plink_maint':
plink.c:220: error: 'AUFS_CTL_PLINK_MAINT' undeclared
Yioryos Asprobounitis:
Thank you, this did it!
You may want to update the main info page though that states:
o aufs2-util tree
$ git clone http://git.c3sl.ufpr.br/pub/scm/aufs/aufs2-util.git \
=09aufs2-util.git
$ cd aufs2-util.git
- no particular tag/branch currently.
Ah, I didn't notice.
Hello Barry,
Barry Kauler:
Badly broken. I got Aufs2.1 from git on October 14, it is the only
patch on pristine source, configured as I have done it many times
before. I also checked that I am using aufs2-util from 2.1 git.
:::
Let make sure,
- linux-2.6.34.1 + aufs2-34 +
Barry Kauler:
The problem does not seem to be due to Aufs, as I mounted another
partition outside of the layered f.s. and also 'md5sum' gave a wrong
sum (a different one from the previous wrong sum inside the layered
f.s.!)
I found that the problem is the 2.6.34.7 kernel, 2.6.34.6 is ok.
Hello Phil,
Phil Miller:
I know you have almost no time to look into this but the latest code of aufs
2.1 don't work with 2.6.36 yet. Current error is now:
:::
I'm glad for any help on this problem. Steven Barrett might have also time to
look into it ...
Yes, I know the changes in
Hello nomad,
nomad Bellcam:
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
Hello John,
Jemiolo, John:
In file included from c2tmac.c:21:
/usr/local/src/aufs2-standalone.git/include/linux/aufs_type.h:160: error: e=
xpected =E2:=E2, =E2,=E2, =E2;=E2, =E2}=E2 or =E2__attribute__=E2 before =
=E2*=E2 token
make: *** [c2tmac] Error 1
Line 160 is __u64 ul;, right?
The
Hi,
Jordi Pujol:
I have been working on the aufs2.1 modification for 2.6.36,
using the official kernel 2.6.36 release,
now it works well on a Debian Live OS where aufs writes the COW on disk,
and also when the COW is on tmpfs.
here are the patches for aufs2.1 standalone,
o news
- I am coming back to aufs work, but it is not full-time yet.
- release aufs2.1-36 branch.
- begin supporting linux-2.6.37-rcN (untested).
o bugfix
- aufs: bugfix, reverse loop in au_update_dbend()
- aufs: bugfix, deadlock around au_plink_lkup()
- aufs: possible bugfix, replace some
Cyanrigger:
What do you exactly mean by stress test? Just copying files from
somewhere - maybe from /dev/zero to /dev/sda1 (which is my
ext3) with various dd's ?
Filesystem stress test is something like this.
Of course, you can customize whatever you like.
#!/bin/bash
Creat()
{
for
Hello Thomas,
Thomas Sachau:
-the build should never leave the builddir for adding/changing/removing f=
iles, this includes places
like /usr/src/linux. The attached build.log shows the prevented access by=
sandbox.
Unfortunately I totally don't understand what it means.
Do you maen
- there
Cyanrigger:
do dd if=/dev/zero of=$f bs=$((($RANDOM % 8) + 16))
I corrected $f to $i. I guess this was a typo...
Sorry.
The general behaviour is:
When I start the stresstest script ( I positioned it in a directory
on /mnt/ro_root/test/ ) I can see a few processes with ps that all
Cyanrigger:
As you can see in the listing below, I let it run for 7 loops total.
Is this enough to make a statement?
The script works - whenever the check is running I can see on a
different shell with watch -n 1 ls /mnt/ro_root/test/ that no changes
are being made.
He runs into mount:
Cyanrigger:
So I think that is just a nasty timing problem and is different from my
original error.
Then, does it mean that you run rsync when your system is very idle?
J. R. Okajima
--
Increase Visibility of Your
Cyanrigger:
However after this, when the stress-test is over the errors are gone
(like it was on ext3):
I have tried the similar test to yours on my linux-2.6.31.
The result has no errors.
I may need to test linux-2.6.36.1 (as you did). It will be next week.
Thomas Sachau:
Actually I or aufs2-stdalone.git/Makefile doesn't try to rm file under
/usr/src/linux.
I'd suggest you to modify Makefile such as
=20
- usr/include/linux/aufs_type.h: d =3D $(shell echo ${CURDIR} | cut -c2=
-)
+ usr/include/linux/aufs_type.h: d =3D ${CURDIR}
Same
Thomas Sachau:
You seem to execute scripts/Makefile.headerinst inside the kernel source =
dir, which operates inside
the kernel source dir, but of course has not access right there.
So you need to run make headers_install BEFORE building aufs.
That may be possible, but the encouraged and
sf...@users.sourceforge.net:
I just looked at linux/scripts/Kbuild.include and found $(TMPOUT) make
variable. It may be one cause of your problem. I'd suggest you to give
this make-var to your build process.
One more make variable which may help you.
Try O=writable dir, and the kernel build
Thomas Sachau:
So you need to run make headers_install BEFORE building aufs.
No. There is a package for those headers, which installs those prepared h=
eaders. No package should
ever install any files anywhere except the current builddir or any explic=
itly named DESTDIR. That
call would
Thomas Sachau:
While you can use certain pieces, you cannot expect them to work with you=
r own build process as with
the original build process. Especially not, when your own sources are in =
a different location than
the script itself.
I am always testing the aufs build process in a
Thomas Sachau:
That O var seems to create even more issues, gives me errors about kernel=
not configured and header
files not found.
You need to specify O=dir from the beginning since .config will be
create in that dir. And Makefile too.
The build issue with aufs2-utils still exists:
I
Thomas Sachau:
All this extra work, just to be able to compile the aufs2 utils? Seems li=
ke very big overhead to me,
As long as you want to keep the kernel source tree in readonly place as
your local rule, I believe O= is the best solution for you. Since this
is a generic build method, I
Thomas Sachau:
I don't understand why specifyin O=3D means to waste resources.
Currently I am thinking these are the main reason of your problem.
- you want to put the kernel source dir readonly
- you don't specify O=3D
You want to prepare another kernel dir and want to call a kernel
Hello Gregoire,
Gregoire Gentil:
Once the system has booted (/root of the initramfs becomes the /), I
need to insert a module into the kernel a module:
insmod module.ko base_img=/image.dof
This modules requires and loads/uses many files (image.dof but also some
others) which are physically
Cyanrigger:
Here is a listing of the files that are moved with the rsync script.
When I compare the inode numbers from that files with the ones, fsck
complains about I found out that they're all log-files.
(please see the comments in the pastebin link)
http://pastebin.com/uiD6PBTH
I tried
My English and brain are broken, sorry.
sf...@users.sourceforge.net:
Here is my guess.
- syslogd opens these log files for write.
- in the beginning, files exist on the lower ext3 only. no on the upper
tmpfs.
- aufs opens files on the lower ext3.
- when syslogd writes to them first time,
Cyanrigger:
rsync copies the file. the target file is removed but ext3 doesn't
release the resources for the file since the inode is still referenced
and alive.
Wow. That really bends my brain.
You say that the target file is removed at copying. So this is the
reason why the inode of the
Cyanrigger:
No, I made a mistake and made the test with just a cp, which behaves
like I said and I assumed rsync would do the same.
Now I also know what these --delete-X parameters of rsync do.
AFAIK you're right about the behaviour of rsync and your explanation in
your second-last post
sf...@users.sourceforge.net:
Do you consider this a bug in aufs, though?
No.
I think it is a problem of your shutdown script.
Generally any shutdown script executes
- kill all processes
- remount / readonly
For the system whose root is aufs, the similar scirpt but more work is
Cyanrigger:
I think it is a problem of your shutdown script.
Generally any shutdown script executes
- kill all processes
- remount / readonly
For the system whose root is aufs, the similar scirpt but more
work is necessary. In your case,
- remount ext3 readwrite
Cyanrigger:
I have no sudo - I executed it as root.
This is the output of the script:
http://pastebin.com/yq7qHxkd
I think 'is busy' is not what you wanted. Should I try it again
slightly modified?
'is busy' is the expected error.
This behaviour is correct, and fsck reports errors very
Cyanrigger:
Yes, it is mounted according to /proc/mounts (here is the whole, for
your amusement) :
Not satisfied.
Please add '-v' to remount ext3 readonly in your rsync script.
cat /proc/mounts after remount ext3 readonly is good too.
J. R. Okajima
Hello andron,
Now I have problem,
DSK | sde | busy 99% | read 230/s | write3/s | avio 4
ms |
DSK | sdf | busy 95% | read 213/s | write0/s | avio 4
ms |
DSK | sdg | busy 34% | read 157/s | write0/s | avio 2
ms |
Unfortunately I
But if you see busy, there are only /storage1, /storage3, /storage5,
/storage7 and other disks not using:
Still I don't understand.
Do you mean,
- creating unique files under /storage repeatedly
- files should be created in round-robin in all 8 branches
- but files are created in only 4
It's simple. I want backup my files, and when one of disks are fail,
:::
When I have same files on two disks and random access for them, I have
and backup and decrease reads per second.
I understood what you want to say.
And my answer is
Aufs doesn't have such feature.
J. R.
Hello Oliver,
Oliver Welter:
As you can see here, a simple du on a directory nearly crahess the box:
29070 root 20 0 97.8m 680 524 R 98.1 0.0 0:11.45 du
I read about a dirlist helper - might this solve the problem? Any hints ?
If the kernel shows OOM message, then libau.so may help you.
-
Oliver Welter:
I dont get OOM messages, I guess libau is the readdir in userspace
option from the kernel config?
As I am running aufs in vservers (kind of jail) - is it necessary to
install the aufs-userspace helpers in every guest or is this all handled
from the root context?
Then what is
Lubomir Schmidt:
$ cd aufs2-standalone.git$ git checkout origin/aufs2
I think i use then the most recent that is available.
You got wrong version.
Try origin/aufs2.1, please.
J. R. Okajima
--
Increase Visibility of
Hello Joonwoo,
Joonwoo Park:
While I'm examining udba=notify option, I encountered a behavior that
I didn't expect.
I have two directories (/tmp/tmpfs0 and /tmp/tmpfs1) which are
branches of /tmp/aufs0 as well asl /tmp/aufs1... which means two
different /tmp/aufs0 and /tmp/aufs1 are
o news
- Intoruce a new strategy to refresh some internal aufs objects in order
to address the problem ,
heavy branch management during I/O stress, reported by Thayumanavar
Sachith.
This is still under testing.
o TODO list
- fix a document, reported by Yioryos Asprobouniti and
Joonwoo Park:
Thanks a lot for your feedback on this.
I'll be stay tuned. Please let me know if you need anything else from my e=
nd.
Would you test this patch?
If it runs well, I will include it in next release.
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
Cyanrigger:
And we need to fix the target kernel version.
When you are ready, please tell me your prefered verion too.
My desired kernel version would be 2.6.36.1.
Hi,
Sorry my late reply.
Here is a patch to confirm ext3's behaviour for linux-2.6.36.1.
- apply this patch and aufs2.1-36.
-
Joonwoo Park:
Thanks for providing me this patch. Patch works flawlessly.
FYI, I did my test with patch applied aufs2.1-standalone.tree-32-20101206.
Thank you very much.
The patch (I already made some minor changes) will be included in next
release.
J. R. Okajima
Hello Ruben,
Ruben Gonzalez Arnau:
I have installed aufs2 as kernel module with no problems, but now trying
to install aufs2-util (latest aufs2.1) does not compile.
:::
make: *** No rule to make target `proc_mnt.o)', needed by `libautil.a'.
It looks like a new problem.
While I don't
o news
- heavy branch management during I/O stress, reported by Thayumanavar
Sachith.
-- Still testing.
o TODO list
- udba=notify with two aufs mounts, reported by Joonwoo Park.
- missing samples in aufs web, reported by Jordi Pujol.
-- Done
- libau causes application segfault, reported
Hello Thayumanavar Sachithanantham,
It was several months ago when you reported a problem about heavy branch
management during I/O stress test. I am not sure whether you are still
interested in aufs and this problem, but all my local tests are passed
and I think current aufs is worth for you to
Hi,
Thayumanavar Sachithanantham:
Thanks for the patch. Nowdays i am no more involved in work related to
AUFS so won't have access to very high multi core CPUs.
But i am going to go through this patch along with current aufs over
the weekend and will give it a try on my virtual machine this
Hello Marco,
Marco Clocchiatti:
using sys-fs/aufs2-0_p20101122-r1 from a gentoo distribution and
gentoo-sources-0_p20101122-r1, system hungs at shutdown when etc is
remounted read-only.
Please try this.
# mount -no remount,noxino,ro /etc
# for i in $writable_branches
# do mount -no
Marco Clocchiatti:
remount /etc, as in your tip, I have the same behaviour.
etc becames anavailable (Resource temporarily unavailable) and the
system needs hardware reset.
Then please show me the output of strace -f fo remount /etc.
Marco Clocchiatti:
aspi2 ~ # uname -rm;strace -f mount -no remount,noxino,ro /etc
2.6.36-gentoo-r5-live i686
execve(/bin/mount, [mount, -no, remount,noxino,ro, /etc],
[/* 50 vars */]) = 0
:::
[pid 2224] execve(/bin/mount, [mount, -i, -n, -t, aufs,
-o,
Marco Clocchiatti:
Do you mean that remount hung?
yes, it do.
I read a lot of -1 EINVAL (Invalid argument) for directories which
should be accessible in a normal configuration.
Let me make sure.
- remount didn't end.
- you could see many EINVAL in your strace -f mount -no
Marco Clocchiatti:
thanks again.
-i option seems really usefull, for me :)
may it be this better for you?
Let me make sure again.
- with -i, remount process exits.
- and all other operations, ls(1) or something, worked correctly.
If so, I'd want you to test these commands just before remount
Hi,
Cyanrigger:
aufs do_refresh:499:mount[2818]: unrecoverable error -2, cache
aufs au_remount_refresh:668:mount[2818]: Refreshing directories
failed,ignored (-2)
-2 means No such file or directory.
2:ENOENT:No such file or directory
It looks like you removed something should not be removed
o bugfix
- possible bugfix, br_count in async rmdir
- possible bugfix, protect branch from deleting in nfsd fh_to_dentry()
- bugfix, missign test for branch management
- rdu: bugfix, return value for exceeding postion
o misc
- libau, v2.5
- describe an error after branch management
o TODO list
Cyanrigger:
I watched what the rsync script wanted to delete on the upper
branch ( /mnt/rw_root - r/w tmpfs) - a part of that list was /root/sbin.
Most propably aufs didn't like that. (The script is running from that
dir...)
If your aufs version is old, I'd suggest you to try latest version.
Ruben Gonzalez Arnau:
This is a self reply, since I get an email from other LFS user with
exactly same problem as me, and if someone is searching about it, it's
good to explain it.
1) Compile errors 'proc_mnt.o' are fixed in the latest aufs version,
also
it's not a bug in aufs, it's a make
Ruben Gonzalez Arnau:
You guess right :)
:::
An no more segfaults here, so again it's not an aufs bug.
Glad to hear that.
Thank you for repeted builds and tests.
J. R. Okajima
--
Learn how Oracle Real
o bugfix
- bugfix, O_CLOEXEC for the plink maintenance mode, reported by Marco
Clocchiatti.
-- need to update both of kernel module and utilities.
o misc
- new make target 'install' for stdalone
- new make target for installing a header
o TODO list
- a small report about squashfs and aufs.
Hello Florian,
Florian Klink:
seems to me as if there is some code adaption needed to get aufs
working
with 2.6.37.
The log doesn't look like linux-2.6.37.
Try the tag 'v2.6.37' in linus' tree and aufs2.1-37 in aufs tree.
J. R. Okajima
The log doesn't look like linux-2.6.37.
Try the tag 'v2.6.37' in linus' tree and aufs2.1-37 in aufs tree.
Sorry, I didn't release aufs2.1-37 yet.
It will next Monday.
Try aufs2.1 which is for 2.6.37-rcN.
On my local test system, it worked with v2.6.37.
J. R. Okajima
Hello Colin,
Colin McInnes:
# mount -t aufs -o br:/mnt/persistent none /mnt/UNION
aufs au_wbr_init:342:mount[1102]: /(jffs2), unsupported namelen 254
Currently aufs expects 255 name length for the first branch.
J. R. Okajima
sf...@users.sourceforge.net:
Colin McInnes:
# mount -t aufs -o br:/mnt/persistent none /mnt/UNION
aufs au_wbr_init:342:mount[1102]: /(jffs2), unsupported namelen 254
Currently aufs expects 255 name length for the first branch.
Correction.
... expects 255 name length for writable branch.
Hello Pasi,
Phasip:
filesystems, but even if I use create=mfs or rr all files are
created on the first filesystem I have in my list (note if I create a
file on the second filesystem manually it shows up in /mnt/storage)
Here's my fstab:
UUID=8433309e-0012-4cd0-b3da-055ad134cc4e
801 - 900 of 1884 matches
Mail list logo
