Hello, J. R. Okajima & List
I think I have encircled the issue:
The Problem disappears when I boot the server into Kernel 3.2 instead of 3.16.
So your indication given below was right.
It does not disappear when I change nfs export options from sync to async, as
mentioned in some (older) intern
Michael Johnson - MJ:
> Sorry it's been a bit since I reported back, but I got a chance to apply
> your patch and I have mixed results to report. Basically, it looks like
> the patch may resolve the issues, but not entirely.
:::
> Ultimately, at this time I cannot reproduce the problem, so
Sorry it's been a bit since I reported back, but I got a chance to apply
your patch and I have mixed results to report. Basically, it looks like
the patch may resolve the issues, but not entirely.
After building the new kernel, I was still able to reproduce the problem
initially
Wolfgang Rosner:
> The last signs of life of my NFS client look like
:::
It shows these sequences.
- nfs client sent WRITE
+ nfs server returned OK
- nfs client sent CLOSE
+ nfs server didn't return anything
- nfs client sent READ
+ nfs server didn't return anything
According to th
Dear J. R. Okajima
Am Samstag, 7. Februar 2015 03:14:25 schrieben Sie:
> Wolfgang Rosner:
> > > Do you mean
> > > - you specified "=ro+wh" as a branch permission
> > > - but /sys/fs/aufs/si_*/br2 shows "ro"
> > > right?
> >
> > yes. Thats what I did.
>
> I cannot reproduce this problem.
> I think
Hello Wolfgang,
Wolfgang Rosner:
> short story before
> aufs on server, nfs export as nfsroot for clients
>
> the symptom on the client (first login after boot):
>
> root@blade-008:~# la
> ls: cannot open directory .: Stale NFS file handle
> root@blade-008:~# cd .
> root@blade-008:~# la
:
Michael Johnson - MJ:
> I've made it through the initial build and the problem does in fact still
> occur. I completed the build with CONFIG_AUFS_DEBUG=y and as one would
> expect, the problem still occurs. Interestingly, I cannot reproduce 100%
> of the time in the way previously described. H
I've made it through the initial build and the problem does in fact still
occur. I completed the build with CONFIG_AUFS_DEBUG=y and as one would
expect, the problem still occurs. Â Interestingly, I cannot reproduce 100%
of the time in the way previously described. Here is what doe
MJ, Dan,
I appriciate your efforts.
Dan Kegel:
> That failed with "no config found", so I repeated it after doing
> $ cp -vi /boot/config-`uname -r` .config
> It then asked two questions; I said yes to X86_16BIT and no to
> IPMI_SI_PROBE_DEFAULTS.
:::
(and about the uppercase in aufsD)
I just tested an I get the error even when the aufs branches are reside on
the same btrfs file system, so that doesn't seem to make any difference.Â
Now to get aufs rebuilt.
On Tue, Feb 3, 2015 at 8:05 AM, Dan Kegel <[1]d...@kegel.com> wrote:
On Mon, Feb 2, 2015 at 8:56 PM, <[
On Mon, Feb 2, 2015 at 8:56 PM, wrote:
> [steps to build kernel]
Thanks for posting the steps. I'm following them now.
> - get all source files of ubuntu trusty and build as it is
> $ git clone git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
> $ cd ubuntu-trusty
> $ fakeroot make-kpkg -
I'll try to get to this today/tonight.
I see another difference between my test case and yours which might be
altering the result. In my case, both branches are on physically separate
file systems rather than directories on the same fs. I'll check and see if
this makes a differ
Michael Johnson - MJ:
> I think I know why you were unable to recreate the problem. It appears to
> only occur in attempt the test case from a directory contained within the
> aufs mount point, and not the base of the mount itself. In fact, if the
> directory you are in exists in all branches, t
I think I know why you were unable to recreate the problem. It appears to
only occur in attempt the test case from a directory contained within the
aufs mount point, and not the base of the mount itself. In fact, if the
directory you are in exists in all branches, the problem does
Michael Johnson - MJ:
> I will see if I can reproduce in a vm and generate very specific
> instructions to reproduce. I think I will have time to do this later today.
Thank you very much.
Other testers are also welcome.
The first debug patch I will ask will be the one in
http://www.mail-archive
I will see if I can reproduce in a vm and generate very specific
instructions to reproduce. I think I will have time to do this later
today.
On Feb 1, 2015 10:37 PM, <[1]sf...@users.sourceforge.net> wrote:
[2]sf...@users.sourceforge.net:
> I have tried but could not
sf...@users.sourceforge.net:
> I have tried but could not reproduce the problem.
> - got full trusty kernel source, built it with the default configuration
> (as MJ posted) --> no disk space
> - disabled unnecessary drivers, built again --> succeeded
> - rebooted with the new kernel, tried, but
sf...@users.sourceforge.net:
> Anyway I will try ubuntu kernel by myself, although it will take long
> time...
I have tried but could not reproduce the problem.
- got full trusty kernel source, built it with the default configuration
(as MJ posted) --> no disk space
- disabled unnecessary drive
Dan Kegel:
> root@ubu14-bb-01:/var/lib/lxc/ubu14-bb-01-ubu1204-temp-g-speak-unique/foobar#
> mkdir -p dir1/dir2
> root@ubu14-bb-01:/var/lib/lxc/ubu14-bb-01-ubu1204-temp-g-speak-unique/foobar#
> rm -rf dir1
> root@ubu14-bb-01:/var/lib/lxc/ubu14-bb-01-ubu1204-temp-g-speak-unique/foobar#
> ls
> ls: c
The short repro script reproduces the problem here:
root@ubu14-bb-01:/var/lib/lxc/ubu14-bb-01-ubu1204-temp-g-speak-unique# df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
none aufs 209711104 20796608 186780800 11%
/var/lib/lxc/ubu14-bb-01-ubu1204-temp-g-speak-un
Michael Johnson - MJ:
> All branches of you aufs mount are btrfs and I do see the 'Warning:
> Un-notified UDBA or repeatedly renamed dir' messages in my logs if I have
> things using inotify. I use udba=3Dreval. In fact, here is the full set o=
That is strange.
The message is unrelated to udba o
Michael Johnson - MJ:
> I think this provides all the information from my system that you asked
> for. I am running stock ubuntu 14.10. I have been seeing this problem as
> long as I can recall (all the way back to Ubuntu 10.04?). It's never
> really been a major issue for me, so I've not broug
sf...@users.sourceforge.net:
> Michael Johnson - MJ:
> > $ cd /aufsdir;
> > $ mkdir -p dir1/dir2;
> > $ rm -rf dir1
> > $ ls
> > ls: cannot open directory .: Stale file handle
>
> At least, these steps succeeded on my test machine.
I've tested the same steps on
- plain linux-3.13
- aufs3.13-20140
> According to git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git, it uses
> aufs3.13-20140303. As always, ubuntu uses old version enough to make it
> very hard for me suppport. But I am trying, as always, to support and
> help users.
Ah, I might be confused, sorry.
If ubuntu-trusty.git is release
Dan Kegel:
> I see that Ubuntu 14.04's using kernel 3.13.mumble, and aufs no longer
Is this your Ubuntu 14.04?
2d22fc7 2014-10-09 UBUNTU: Ubuntu-3.13.0-38.65
According to git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git, it uses
aufs3.13-20140303. As always, ubuntu uses old version enoug
Michael Johnson - MJ:
> $ cd /aufsdir;
> $ mkdir -p dir1/dir2;
> $ rm -rf dir1
> $ ls
> ls: cannot open directory .: Stale file handle
At least, these steps succeeded on my test machine.
$ mkdir -p dir1/dir2
$ rm -ir dir1
rm: descend into directory `dir1'? y
rm: remove directory `dir1/dir2'? y
a
Hello Dan and Michael,
Dan Kegel:
> Thanks for the short repro script.
I will try Michael's to reproduce the problem on my test env.
> I believe this is bug #1: http://sourceforge.net/p/aufs/bugs/1/
It is doubtful since the versions, options, branch fs-types are all
different from yours.
J.
... although if it's bug #1, I'm not sure why it just showed up for me
with btrfs and not ext4...
On Tue, Jan 27, 2015 at 4:03 PM, Dan Kegel wrote:
> Thanks for the short repro script.
> This prevents debian packaging tools from working; seems like it'd be
> good to fix it in aufs rather than add
Thanks for the short repro script.
This prevents debian packaging tools from working; seems like it'd be
good to fix it in aufs rather than adding a workaround into dpkg and
friends.
I believe this is bug #1: http://sourceforge.net/p/aufs/bugs/1/
- Dan
On Tue, Jan 27, 2015 at 3:47 PM, Michael Joh
I see very similar behavior (and always have with AUFS) and it is easily
reproducible. Here is how to reproduce 100% of the time:
$ cd /aufsdir;
$ mkdir -p dir1/dir2;
$ rm -rf dir1
$ ls
ls: cannot open directory .: Stale file handle
To mke the error go away:
$ cd .
On Saturday, April 06, 2013 05:53:33 PM you wrote:
> umount -f -l ro
>
> is the closest you will get. The entry will be removed from the mount
> table and the actual unmount will happen when it can (never) but at
> least you needn't worry about it.
Thanks, this does seems to solve the ro dir (sti
umount -f -l ro
is the closest you will get. The entry will be removed from the mount
table and the actual unmount will happen when it can (never) but at
least you needn't worry about it.
On 4/6/13, V.Krishn wrote:
> Did the following to set an aufs.
>
> cd /tmp
> mkdir branch ro u
> mount test.
Lucas de Vries:
> I tried to compile something in my aufs directory (I've tried it with
> multiple applications, so it's not something specific to that), and
> during the configure stage it just dies with:
>
> ls: cannot access .: Stale NFS file handle
I tried btrfs.
As I expected, the aufs XINO f
> I tried btrfs.
> As I expected, the aufs XINO files don't work on btrfs due to its
> internal i_blocks. It is OK. When aufs detects that the first writable
> branch fs cannot handle XINO files, it will try /tmp as next candidate.
>
> Here is a patch attached for you to support btrfs branch.
The
Hello Lucas,
Lucas de Vries:
> I tried to compile something in my aufs directory (I've tried it with
> multiple applications, so it's not something specific to that), and
> during the configure stage it just dies with:
>
> ls: cannot access .: Stale NFS file handle
Give me these info please.
(
> > Nothing interesting in dmesg. Compiled using gcc 3.4, local.mk and =
> >
> > kernel v2.6.20.3. Not using latest daily, will recompile to that and =
> >
> > reload module later on. I'm guessing that will solve the problem =
>
> You have changed your environment, thank you, but you still had
"Jrgen_P._Tjern":
> [EMAIL PROTECTED]:/storage/isos# ls
> ls: .: Stale NFS file handle
>
> It's obviously not the nfs causing the problems. since it's not running. =
Linux VFS returns this error what it failed revalidating, even if the
filesystem is not nfs.
Your aufs failed revalidating the cur
this sounds more like a problem with your shell cacheing an old inode.
a) what shell do you use, b) what happens if you use something that's a bit
stupider like the original sh.
> Jørgen P. Tjernø wrote:
>> I'm toying around, and I want to ls a dir on the aufs.
>> [EMAIL PROTECTED]:/storage/iso
Jørgen P. Tjernø wrote:
> I'm toying around, and I want to ls a dir on the aufs.
> [EMAIL PROTECTED]:/storage/isos# ls
> ls: .: Stale NFS file handle
> [EMAIL PROTECTED]:/storage/isos# grep /storage /proc/mounts
> none /storage aufs
> rw,xino=/vault/disk3/.aufs.xino,udba=inotify,br:/vault/disk3=rw
39 matches
Mail list logo
