> 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
This sample was rough or rude.
You may need to care about whiteout, and the possibility of another
p
"Void":
> 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?
Have you tried CONFIG_AUFS_COMPAT?
--
> If I copy a file from
Hans-Peter Jansen:
> Junjiro does such an awesome job here, that he deserves to be named right
> - at least -, or would you like to be called Barjy all the time? ;-)
Thank you, Pete. I didn't realise that misspelling. :-)
By the way, I have found a critical bug in aufs, which makes aufs
confuse
> Ideally, this script should be executed with locking-out all other
> processes.
One important thing.
The inode number will not be kept.
It means the moved file will have different inode number.
It may be harmful.
Junjiro Okajima
"Sandino Flores Moreno":
> fs/built-in.o: In function `aufs_encode_fh':
> /home/tigrux/Documents/kernel/linux-2.6.21/fs/aufs/export.c:538: undefined
> reference to `export_op_default'
:::
There may be some changes in linux-2.6.21. I will check it out later.
Let me make sure one thing.
Did
A critical bug was found in aufs(see the top of the list). It is fixed
now, except a hardlink on NFS branch case.
If you have an NFS branch in your aufs, it is not recommended to use
this version. I will fix it in next Monday release.
o bugfix
- bugfix: re-use inode->i_generation to support the e
o news
- this version of aufs consumes inode number rapidly. it will be fixed
in a week.
o bugfix
- bugfix: fix the obsolete inodes with d_revalidate. the last
temporary bugfix is completed. but this version of aufs consumes
inode number rapidly. it will be fixed in a week.
- refine d_reval
As I announced in last Moday release, a minor bug is fixed which is the
end of a revalidating problem.
- bugfix: stop consuming inode number rapidly.
Junjiro Okajima
--
Index: fs/aufs/i_op_del.c
Index: fs/aufs/i_op_ren.c
- bug
o news
- begin supporting 2.6.21
o misc
- prohibit umount while nowait work in the generic workqueue,
introducing au_mntget/put().
- rename CONFIG_AUFS_AS_BRANCH to CONFIG_AUFS_ROBR.
- rename AUFS_WH_LEN to AUFS_WH_PFX_LEN.
- remove AufsGenOlder/Younger macros.
- rename is_aufsd() to is_au_wkq(
"Sandino Flores Moreno":
> ... on linux 2.6.21.1, I got this error:
Sorry, I may be confused 2.6.21 with 2.6.22.
Please try this patch. If it succeeds, I will update CVS.
Junjiro Okajima
--
Index: fs/aufs/opts.h
==
"Sandino Flores Moreno":
> It applied and compiled cleanly.
Thank you.
I have updated the CVS.
Junjiro Okajima
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and ta
Hello,
Michael Creel:
> I am attempting to update the kernel of the parallelknoppix64-rc1 live CD to
> use
> kernel 2.6.21.1 instead of 2.6.19.7. I updated aufs to yesterday's CVS and
> compiled the aufs.ko module as normal (make KDIR=/usr/src/linux -f local.mk).
> Everything seems to go wel
Hi Ryan,
Ryan Jud Hughes:
> It seems that aufs's unionctl wants a command like:
> unionctl /UNION --mode /foo ro
>
> whereas unionfs's wanted a command like:
> unionctl /UNION --mode ro /foo
:::
> Is there any reason not to do this?
Because unionctl.c in unionfs-1.4.tar.gz s
Michael Creel:
> >> Everything seems to go well, but when the CD is booted (actually, I use
> >> VMware to boot the image), there is a failure at the point that the aufs
> >> filesystem is mounted, leading to a "failure bad /proc/mounts 1" message.
:::
> I am trying this using VMware, and
Hello Wolfgang,
Wolfgang Barth:
> I'm using aufs for live cds and was updating from 2.6.20.4 and aufs
> 20070320 to 2.6.20.11 and aufs 2.6.20.11.
:::
> What is changed since 2.6.21.1 and could introduce this?
I guess you don't want to know the difference between linux 2.6.20 and
2.6.21.
Michael Creel:
> version of ParallelKnoppix64 boots up fine. So there's some problem that has
> cropped up in the time frame from 20070509 to yesterday, I believe.
Thank you for your report.
Please try this patch which is against the latest CVS version.
Junjiro Okajima
> Michael Creel:
> > version of ParallelKnoppix64 boots up fine. So there's some problem that
> > has
> > cropped up in the time frame from 20070509 to yesterday, I believe.
>
> Thank you for your report.
> Please try this patch which is against the latest CVS version.
I have just updated the
Hi,
Wolfgang Barth:
> - Calling ntlm_auth (for AD authentication) from squid needs
>
> drwxr-x--- 2 root proxy
>
> so I only changed the group ownership and restarted all relevant
> processes.
Do you mean that you changed it on the writable branch directly?
If so, you need to use udba=in
o misc
- flush all the scheduled/nowait tasks at umouning and remounting.
- refine the nowait task queuing.
- support the enqueue error in workqueue.
Junjiro Okajima
--
Index: fs/aufs/cpup.c
Index: fs/aufs/dentry.c
Index: fs/au
Wolfgang Barth:
> No, I changed the permissions on aufs, as you recommended, not directly.
If you can see the dir group id was changed expectedly and all the
relevant processes were restarted correctly, then it must be an aufs
bug.
Will you show me the simple way to reproduce it?
For example, ho
Hi,
Wolfgang Barth:
> I can now reproduce my winbind problem in an easy case.
Thank you.
>now is:
>% ls -ld /z-var/lib/xxx /DISK/var/lib/xxx /var/lib/xxx
>drwxr-x--- 2 root root 2048 May 21 11:16 /z-var/lib/xxx/
>drwxr-x--- 2 root proxy 4096 May 21 13:37 /DISK/var/lib/xxx/
>
Wolfgang Barth:
> % ls -ld /var /var/lib /var/lib/xxx
> drwxr-xr-x 26 root root 4096 May 21 11:56 /var/
> drwxr-xr-x 32 root root 4096 May 21 13:48 /var/lib/
> drwxr-x--- 2 root proxy 4096 May 21 13:37 /var/lib/xxx/
Hmm,,, it's a mystery.
What is the shell of user proxy's?
I want to take a
Wolfgang Barth:
> chown root.root /tmp/aufs-ro/test
> chmod 750 /tmp/aufs-ro/test
>
> mount -t aufs -o br:/tmp/aufs-rw:/tmp/aufs-ro=ro none /tmp/aufs
>
> cd /tmp/aufs
>
> chgrp proxy /tmp/aufs/test
>
> su - proxy
> cd /tmp/aufs/test -> permission denied
I was a fool, but aufs.
It is a feature
o pre-announce
As I had announced a few months ago, the unionctl script will not be
supported.
The script the description about it in the aufs manual will be moved
from /aufs/util to /aufs/sample.
And the symlink under /aufs/ will not be created by removing
it from local.mk.
o news
- support unm
Hi Wilhelm,
Wilhelm Meier:
> FYI, aufs works without problems on linux-vserver with the patches I sent to
> the list some times ago. And it would be very good to see a clean solution
> for linux-vserver incorporated into aufs.
I can guess supporting the linux-vserver interface (or function
sig
o news
- the unionctl script is moved from util/ to sample/, and will not be
supported any more.
o bugfix
- bugfix: support the moved root branch.
o misc
- testing is_subdir() kernel internal function.
Junjiro Okajima
--
In
o
- testing dir-lock in open(2).
- describe about the aufs message and errno in the manual, suggested
by Just Marc.
Junjiro Okajima
--
Index: fs/aufs/file.c
- testing dir-lock in open(2).
Index: util/aufs.in.5
- describe ab
Hi,
"Sandino Flores Moreno":
> I'm using aufs to compile.
:::
> The embedded file systems lives in another aufs (so I can have all the
> produced or installed files in within the changes branch for that system).
Do you mean you have two aufs mounted, like this?
# mount -t aufs -o br:/rw
"Jrgen_P._Tjern":
> The thing that's acting up is a dir handle. I opendir() it, and I can
> read fine from it. A bit later in the programs execution, and readdir()
> returns NULL (right after I rewinddir()), and errno is not set.
So your application calls,
{
opendir();
readdir();
> You need to enable CONFIG_AUFS_DEBUG. It will print debug messages to
> syslog.
One more note,
You need to configure /etc/syslog.conf and /proc/sys/kernel/printk to
receive kernel debug message. For example,
# echo 8 > /proc/sys/kernel/printk
(/etc/syslog.conf)
kern.debug /var/log/debug.log
Hello Bertrand,
Bertrand D:
> Working on an embedded projet, i planned on using aufs. The linux kernel I
> use is based on a 2.6.20.7 (it was cross-compiled). It uses the ppc branch
> and not the powerpc one. The kernel works great with different kinds of
> filesystems. No stability issues. Ex
"Igor Karasynskyi":
> I'm use aufs as root filesystem in which I chrooted during boot and
> after this system run from there, my last branch is RW (index = 0) and
> all other is RO, on previous branch (index = 1) exist file /tmp/test
> (/tmp permissions is 777), owner of this file is common user,
"Igor Karasynskyi":
> > - after rm, check the whiteout by 'ls -l /rw/tmp/.wh.test'
> yes whiteout created
And what is its user/group/link_count?
> > - check the dir permission by 'ls -ld / /rw /ro /rw/tmp /ro/tmp'
> yes all ok, all branches has 755 and all tmp has 777
Let me make sure about /t
"Igor Karasynskyi":
> I can't test what you ask now because something wrong now, when I try
> to mount new branch and after that do remount as RO previous branch I
> receive:
> kernel BUG at fs/aufs/finfo.c:31
> invalid opcode: [#1]
Thank you for your reports, Igor.
Do you mean,,,
# mount -
> > > - check the dir permission by 'ls -ld / /rw /ro /rw/tmp /ro/tmp'
> > yes all ok, all branches has 755 and all tmp has 777
>
> Let me make sure about /tmp.
> Is its permission 0777 or 1777?
If your /rw/tmp is 1777, it may be the trigger of this aufs bug and
please try this patch.
Junjiro
Hi Igor,
"Igor Karasynskyi":
> > Do you mean,,,
> > # mount -t aufs -o br:/rw:/ro none /aufs
> > # mount -o remount,mod:/rw=ro /aufs
> > and crashed?
> I can't find information about bug in /var/log/*, so I try do
> screenshot of this problem, on screenshot also steps that I do after
> system boo
"Igor Karasynskyi":
> Yes you are right :) my first RO branch has 0777 and branches after
> that has 1777, this patch fixed this problem, thank you very much :)
God news!
> About this problem with remount branch as RO:
> 1) I have image of Gentoo distributive (with 2.4 kernel)
> 2) after th
"Igor Karasynskyi":
> When I trying to find file vcsa2 the result only was /dev/vcsa*, so I
> think it was device file, and as I say because image is based on 2.4
> kernel stuff, the dev files is located on "image" branch (last index):
> br:/cur=rw:/base=ro:/image=ro. So maybe problem in dev files
"Igor Karasynskyi":
> > Won't you try this patch?
> Didn't help, log attached
Sorry, I should write more.
Please remove the last debug patch which includes au_debug_on().
> I make mistake, error return not mkswap but swapon
:::
> stat64("/var/tmp/swap", {st_mode=S_IFREG|0644, st_size=10
"Igor Karasynskyi":
> No it not really needed, it much more clear when swap located outside of aufs
OK. Then I hope you had already read this description, too.
(from the aufs manual)
When you use aufs as root filesystem, it is recommended to consider to
exclude some directories. For example, /tm
"Jrgen_P._Tjern":
> getting "aufs au_new_inode:...: broken ino", e.g.:
> [ 349.301408] aufs au_new_inode:325:glftpd[3180]: broken ino, b0,
> files/3.Lbs, hi805306524, i1078. Try udba=3Dinotify.
> Also:
> [631021.668293] aufs au_new_inode:325:twistd[27583]: broken ino, b0,
> libxtst/libxtst6_1.0.1
o bugfix
- bugfix: declare 'signed char', a portability problem reported by
Bertrand D.
- bugfix: strict branch index check at the first adding, reported by
Bertrand D.
- bugfix: unlink a whiteout under a dir who has a sticky bit, reported
by Igor Karasynskyi.
o misc
- warn about overlapped
"Jrgen_P._Tjern":
> Branch 0 would be the first branch on the /proc/mounts-line? If so,
> that's /vault/disk3, which is xfs. How do I find largest inode number?
Please send me the output of this script.
Set $path correctly before you execute it.
Junjiro Okajima
-
Hi,
Tomas M:
> My goal is to properly save all filesystem modifications in the writable
> branch. So first I tried to cleanly unmount the union, but it's busy and
> can't be unmounted.
Your aufs is the root filesystem, isn't it?
Generally speaking, the root filesystem cannot be unmounted. It i
> "Jrgen_P._Tjern":
> > Branch 0 would be the first branch on the /proc/mounts-line? If so,
> > that's /vault/disk3, which is xfs. How do I find largest inode number?
Sorry, please add one line.
> #!/bin/sh
>
> path=/tmp
> tmp=/tmp/$$
>
> set -x
> df -i $path
> for i in 1 2
> do
sudo
Hello Michael,
Michael Towers:
> - I made a live cd using your latest larch scripts.
> - I booted into the live cd and did a "pacman -Sl" and pacman lists all
> packages in the repos, about 3925 packages.
> - I did a "pacman -Syu" and all my packages were up to date. Immediately
> after that I do
Hi,
"Igor Karasynskyi":
> after reboot and mounting aufs with new branch 4: br:4=rw:3=ro:2=ro:1=ro
> I don't see this file - OK, but if I do ls /install or cat /install
> then file exist.
Try 3=ro+wh, instead of 3=ro.
By the way, how about /dev/vcsa2 problem at remount,mod?
I hope you have succ
"Igor Karasynskyi":
> Hmm... I have something strange here... what you say about that:
> If I try to add new empty branch with remount option
> mount -o remount,prepend:/mnt/1=rw /
> all OK
> But if I try to do like this (without remount)
> mount -o prepend:/mnt/1=rw /
It is equivalent to 'mount
Tomas M:
> I was just wondering if there is a way to see what resources
> (files/directories/etc) are used by aufs (perhaps through /proc or
> /sys). This would help very much. So please consider this as a feature
> request for aufs sometime in the future :)
I have a plan to show the opened au
"Jrgen_P._Tjern":
> I removed 3.Lbs as it's not on the fs any more. I ran your script with
> the changes, produced a lot of output. See the attached file. :-)
Sorry, I should write more correctly.
The path you set is /storage and it is aufs mount point, isn't it?
It should be branch path. In your
"Jrgen_P._Tjern":
> I picked the most recent entry in my dmesg, and added that hi and fname
> to the commands. (added 536871063 to the egrep)
> Entry was:
> [1081101.429555] aufs au_new_inode:325:find[31722]: broken ino, b0,
> linux-meta/linux-image-generic_2.6.17.11_i386.deb, hi536871063, i50306.
Hello,
Tomas M:
> But then, if I try to umount the branch (because the branch was a
> loop-mounted filesystem), sometimes I can see in the dmesg:
>
> VFS: Busy inodes after unmount of loop3, Self=destruct in 5 seconds.
> Have a nice day...
:::
> So my question is, does aufs completely
Tomas M:
> I modified initrd in order to mount the entire aufs using 'noplink'
> mount option from the beginning. It doesn't help, there is still the
> same problem.
What you did is,
- mount -o remount,del:/squashfs /aufs
- umount /squashfs
- some operation
- aufs crashes
Please tell me how to
Tomas M:
> The 'umount /squashfs' part sometimes causes the error message
> "VFS: Busy inodes after unmount loop* ... etc", so I _think_ the loop
:::
About this problem, please test this patch.
> Hm it's hard :) My problem is that I usually can't reproduce it in a
> normal Linux environ
Tomas M:
> This was a different problem.
> Please consider our conversation about /dev/initctl resolved.
>
> I am working with two problems which are not related together:
I am afraid you are confusing my two patches. :-)
> One is the problem of unmounting union (which probably doesn't work
>
Jason Lunz:
> Restarting system.
> BUG: at arch/i386/kernel/smp.c:177 send_IPI_mask_bitmask()
:::
> Is there an obvious cause for this?
I don't know.
> I'm currently updating to 2.6.21.5 and aufs 20070618, but I won't know
> if they also have the problem for a while.
If you meet again
Tomas M:
> Hm it's hard :) My problem is that I usually can't reproduce it in a
> normal Linux environment, I'm still finding these things in Slax, which
> is a chrooted OS and makes things hard to debug.
>
> Nevertheless, you can download Slax from here
> http://www.slax.org/dl/slax6broken.iso
>
Tomas M:
> Do you think all the problems may be gone if I disable inotify support
> in kernel somehow? (if that is even possible). I think I don't need it
> at all, and for Slax it's more important to support removing of aufs
> branches then using inotify.
It is up to KDE or other applications
"Jrgen_P._Tjern":
> Here is the dmesg, it has only occured once after I applied the patch. I
> also updated to the newest aufs. :-) The machine isn't being used as
> regularly during summer, so use-pattern is a bit different now. :-)
>
> I hope this helps!
Thank you very much for your tests.
Cur
Hello Alexey,
Alexey Bazhin:
> I'm having same trouble, but i'm using udba=reval and have no
> modifications to branches or aufs at all... and i'm also using xfs...
Thank you for your report.
Then a bug probably lives outside inotify.
If you know how to reproduce this problem, let me know.
Ju
o current problem
- isolated inode survived deleting a branch (still testing).
- getdents(2) returns nothing.
- cpup_wh_file() failure.
- setting inode number which was previously assigned ("broken ino"
msg).
- hang at reboot/shutdown (it may not be an aufs problem).
o bugfix
- bugfix: skip non
Hello Philippe,
Philippe Malinge:
> I wrote a script (Cf. end of mail) creating 16384 files in a dummy
> directory (aufs directory), named "dummy.3312", without problem.
:::
> It seems that each round deletes only the half of number files.
>
> If I do the same on standard NFS directory,
Hi,
Philippe Malinge:
> > - it was nfs client where you executed the script and rm -fr.
>
> Yes, nfs client run : rm -fr /mnt/dummy.3312
:::
> > Just after you failed rm -fr, can you see the files named '.nfsXXX...?'
>
> No, but dummy.3312 was created on a read-only fs, and I try to rem
Hi Philippe,
Philippe Malinge:
> I guess below information will clarify the issue.
Now we have common recognition that the target dir in on writable branch
filesystem.
And I need to ask you the same question again,
> > And do you mean that after rm -fr failure there left the whiteouts
> > (dumm
Hi Philippe,
Philippe Malinge:
> please find attached strace files for each round of "rm -fr dummy.3312"
> executed on nfs-client side.
> strace files are named using the round number (1, 2, 3, 4, 5)
Thank you for your test.
I believe it is a known problem which was reported recently by a few
pe
Tapani_Rikknen:
> Andrew Burgess kirjoitti:
> > To get aufs to cpmpile under 2.6.21.5-rt17
> > I changed fs/aufs/misc.h from:
> I just compiled 2.6.21.5 with rt18 patch =
>
> (http://people.redhat.com/mingo/realtime-preempt/) WITHOUT CHANGING =
>
> ANYTHING and was surpised that it compiled fine
Tomas M:
> I didn't test the patch you sent me last time yet because I'm packing
> some stuff and I'm leaving to holidays for 10 days. So no need to hurry,
> take your time :)
Hi Tomas,
When you return from your vacation, please test the latest aufs (last
Monday release).
Junjiro Okajima
--
"Andrew Burgess":
> I tried to do this but rt17 locked up in the middle of editing aufs.h
> So its back to mainstream for me...
Andrew and Tapani,
or anyone else who are trying RT patch on aufs,
Please test this patch.
- it uses 'standard compat_rw_semaphore' instead of 'realtime
rw_semaphore.
Tapani_Rikknen:
> But one thing. I forgot to reverse back this aufs.h patch:
:::
> Does it matter?
It should be removed.
Junjiro Okajima
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the
o current problems
- isolated inode survived deleting a branch (done).
- hang at reboot/shutdown (it may not be an aufs problem) (tried fixing).
- setting inode number which was previously assigned ("broken ino"
msg) (testing).
- getdents(2) returns nothing. this may involve two problems.
- cpup
Hello Jorgen,
"Jrgen_P._Tjern":
> [EMAIL PROTECTED] wrote:
> > Thank you very much for your tests.
> > Currently I am considering about the bug in aufs inotify handler.
> > Do you know whether this file 'Simon and Garfunkel ... .mp3' has ever
> > been renamed or not?
> (bah, sorry for misposting
"Jrgen P. Tjern":
> [2297447.631266] aufs 20070702
> [2297509.899071] aufs au_new_inode:347:smbd[27416]: Un-notified UDBA or
> directly renamed dir, b0, xfs, Simon - Garfunkel - The Best Of Simon -
> Garfunkel - Song For The Asking.mp3, hi1610612893, i16.
>
> It's not an access directly to the und
> "Jrgen P. Tjern":
> > [2297447.631266] aufs 20070702
> > [2297509.899071] aufs au_new_inode:347:smbd[27416]: Un-notified UDBA or
> > directly renamed dir, b0, xfs, Simon - Garfunkel - The Best Of Simon -
> > Garfunkel - Song For The Asking.mp3, hi1610612893, i16.
Please show me your /sys/fs/auf
Hello,
> Philippe Malinge:
> > please find attached strace files for each round of "rm -fr dummy.3312"
> > executed on nfs-client side.
> > strace files are named using the round number (1, 2, 3, 4, 5)
>
> Thank you for your test.
> I believe it is a known problem which was reported recently by
Philippe Malinge:
> The coreutils we used is 5.97 included in RHEL 5. It seems not to be an
> old distribution (and exotic).
Ths host you executed rm is RHEL 4 Update, isn't it?
With my test, I found that rm in coreutils-5.2.1 has a problem, but rm
in coreutils-5.97. And your strace doesn't seem
Philippe Malinge:
> You're right, tests were done on RHEL 4 (coreutils 5.2.1) for now, but
> we plan to test it on RHEL 5 (coreutils 5.97) in the next few days. I'll
> tell you the status on this distribution
Just for your information.
It is worth to try,
- copy /bin/rm from RHEL 5 to RHEL 4.
- r
Michael, Jorgen and Sandino Flores Moreno
or whoever has experienced aufs readdir(3) returns empty.
Michael Towers:
> << Here's the problem:
>
> - I made a live cd using your latest larch scripts.
> - I booted into the live cd and did a "pacman -Sl" and pacman lists all
> packages in the repos,
o current problems
- setting inode number which was previously assigned ("broken ino"
msg) (testing).
- getdents(2) returns nothing. this may involve two problems. (it was
one. testing)
- cpup_wh_file() failure. (testing)
o bugfix
- bugfix: force rewind at re-initializing vdir, reported by Mi
Hello Tomas,
Do you remember this mail?
Tomas M:
> I was just wondering if there is a way to see what resources
> (files/directories/etc) are used by aufs (perhaps through /proc or
> /sys). This would help very much. So please consider this as a feature
> request for aufs sometime in the futur
Hello Chris,
chris rogers:
> I try removing a branch and it crash the kernel 2.6.22. So the kernel 2.6.22
> should not be supported yet. Add branches have no problems. It works like
> normal. So i think its cause of the new mount option trunc_xib and
> notrunc_xib that this is happen. But if i
Tomas M:
> As I can read aufs/branch.c, line 377, there is a test if inode->i_nlink
> ... nevertheless 'stat /mnt' outputs Links: 4. I have no idea if this
> information is relevant though :)
>
> Should the posixovl filesystem be fixed, or should aufs be fixed?
I tried adding a branch which is
chris rogers:
> I try removing a branch and it crash the kernel 2.6.22. So the kernel 2.6.22
> should not be supported yet. Add branches have no problems. It works like
> normal. So i think its cause of the new mount option trunc_xib and
> notrunc_xib that this is happen. But if its only in ker
Tomas M:
> Would you please explain briefly what does the code chcek for?
> I'll resend it to the developer of posixovl.
>
> // from branch.c, lines 377-380
> if (unlikely(!inode->i_nlink)) {
> Err("no existence %s\n", add->path);
> goto out;
>
Tomas M:
> > I tried adding a branch which is mounted by
> > FUSE_CVS/fuse/example/fusexmp.c, and succeeded.
> > If you try fusexmp and it succeeds, then the posixovl should be fixed.
>
> Thank you for the answer.
I noticed that you may be misunderstanding what I wrote.
It may depends upon the f
Tomas M:
> #!/bin/bash
> mkdir dir1
> touch dir1/something
> mkdir union
> mount.posixovl dir1
> mount -t aufs -o br:dir1=rw aufs union
I guess you can succeed if you use dir1 directly without mount.posixovl.
> If we run 'mount.posixovl' with -d parameter (debug), we can see that
> nothing acc
o current problems
- setting inode number which was previously assigned ("broken ino"
msg) (fixed).
- getdents(2) returns nothing. (fixed)
- cpup_wh_file() failure. (fixed)
o bugfix
- bugfix: cpup whiteout which was called #2 in last ci.
o news
- begin supporting linux-2.6.22
+ introduce lha
Tomas M:
> I didn't say it properly, I apologize. I was trying to say: "neither
> getattr nor anything else is called at all, the debug is entirely empty,
> the FUSE filesystem is untouched during aufs mount."
I guess fuse lookup will be called if you override it.
That's why I suggest it.
Addit
> I guess fuse lookup will be called if you override it.
> That's why I suggest it.
> Additionally, mount.posixovl needs to initialize its root inode, since
> the root inode is always in cache and lookup for it will not be called.
Note:
- 'the root inode' here means the root of posixovl fs.
- in
Tomas M:
> Just for the case somebody is interested, here is the patch which should
> fix the problem in kernel:
Interesting fixing.
Will find(1) on this fuse complain about the dir nlink?
Junjiro Okajima
-
This SF.net em
Hello Russell,
"Russell Harmon":
> I was just wondering, has anyone tried to get aufs included in the
> kernel? If not, why not?
Currently, I don't have a plan to ask kernel people to include aufs.
But someday I will try it.
Junjiro Okajima
Hello Miklos Szeredi,
I am developing aufs, and Tomas M forwarded me your mail.
Although I don't know where you have ever read aufs, it calls VFS
path_lookup() and checks the gotten nd.dentry->d_inode members.
Do you mean vfs_getattr() or something should be called after
path_lookup(), and access
Tomas M:
> Well I tested the fix just right now and it seems it doesn't help.
> Aufs succeeds in branch.c, as the branch is 'visible' to aufs now,
> nevertheless then it fails with "aufs init_wh:477 an error(-17) on the
> writable branch /(fuse)"
-17 means "File exists" error (EEXIST).
If you wa
Miklos Szeredi:
> Basically yes. Accessing the file type in inode->i_mode is OK, but
> for all other fields getattr() needs to be called.
>
> > If it is true, current linux lookup routines are totally broken since
> > they check inode.i_mode so often without vfs_getattr().
>
> They only check t
Miklos Szeredi:
> > When you create/remove something, lookup operation involves accessing
> > inode->i_uid, i_gid, permission bits in i_mode, i_ino and i_flags.
> >
> > For example,
:::
> > - may_open() checks inode->i_uid.
>
> Yup.
>
> > - unlink(2) and rmdir(2) check the sticky bit an
Miklos Szeredi:
> > But I could understand that you are still asserting getattr is
> > necessary even in the cases of may_open() or something, and that is a
> > VFS lookup bug.
> > Am I right?
>
> Yes :)
It is very hard for me that they are VFS lookup bug.
If they are really VFS lookup bug, you
Miklos Szeredi:
> > It is very hard for me that they are VFS lookup bug.
>
> Why? What has the sticky check or the O_NOATIME check to do with
> aufs?
If it was VFS bug, it must be a generic problem, not specific to aufs.
While you have mentioned about the race problem, the permission check in
l
Tomas M:
> I prefer to just mention this problem in aufs documentation, so people
> will 'stat' a fuse-based filesystem's mountpoint before adding it as
> aufs branch.
It is not enough since Miklos thinks getattr is necessary for every VFS
lookup. Of course, I don't agree.
> I don't understan
Miklos Szeredi:
> You misunderstand. What I think is:
>
> To be able to correctly perform permission checks based on cached
> inode attributes, those attributes may need to be refreshed before
> making the permission checks.
You seem to be replacing the problem.
The problem is more generic, not
Tomas M:
> I respect you don't wish to ask kernel people to include aufs now. But
> please consider simply submitting aufs code to LKML; not for inclusion,
> but for review. This is the best chance to see VERY VALUABLE feedback
> regarding the code from many developers around the world. You wil
Miklos Szeredi:
> And I've shown, that all the other cases are irrelevant.
I didn't agree all of them, especially about permission bits and i_uid.
> You seem to think, that we've already decided, that the right way to
> deal with this is to refresh the attributes on lookup.
Not *right* way.
Wh
801 - 900 of 2717 matches
Mail list logo
