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
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 .
26 matches
Mail list logo
