Re: "au_new_inode: broken ino"

2007-06-15 Thread sfjro
"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

"au_new_inode: broken ino"

2007-06-15 Thread Jørgen P. Tjernø
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Using 20070528 release, I'm at random intervals 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=inotify. Also: [631021.668293] aufs au_new_i

Re: Permission bug?

2007-06-15 Thread sfjro
"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

Re: Permission bug?

2007-06-15 Thread Igor Karasynskyi
> Currently it is an expected behaviour since I am doubtful about swap in > aufs. Is it really needed? As you wrote, you can mkswap on a branch > filesystem directly and the swap file is no need to be stackable. > No it not really needed, it much more clear when swap located outside of aufs --

Re: Permission bug?

2007-06-15 Thread sfjro
"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

Re: Permission bug?

2007-06-15 Thread Igor Karasynskyi
Hmm,,, Won't you try this patch? Didn't help, log attached # mkswap /aufs/regular/file - failed # mkswap /branch/regular/file - succeeded right? I make mistake, error return not mkswap but swapon I have following situation (for example): /dev/sda1 /mnt/disk /mnt/disk/root = aufs (

Re: Permission bug?

2007-06-15 Thread sfjro
"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

Re: Permission bug?

2007-06-15 Thread Igor Karasynskyi
> Do you mean that you are running aufs in 2.4 kernel? > Aufs doesn't support linux-2.4. No, I'm running 2.6 kernel with AUFS, I mean that image on which problem occured is based on 2.4 kernel stuff (modutils, there not exist udev and devfs, just dev files created by MAKEDEV) > > Thank you for yo

Re: Permission bug?

2007-06-15 Thread sfjro
"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

Re: Permission bug?

2007-06-15 Thread Igor Karasynskyi
So what you did is, # mount -t aufs -o br:/rw1:/ro1:/ro2 none /aufs # mount -o remount,prepend:/rw0 /aufs # mount -o remount,mod:/rw1=ro /aufs and crashed. Won't you try this patch which produce more detailed debug information at remount time, and send me the debug log? I apply your patch and r

Re: Permission bug?

2007-06-15 Thread Igor Karasynskyi
> If your /rw/tmp is 1777, it may be the trigger of this aufs bug and > please try this patch. 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 :) > So what you did is, > # mount -t aufs -o br:/rw1:/ro1:/ro2 none