Apply the patch and
test
it.
J. R. Okajima
--
/| |
\/ | Yair Yarom | System Group (DevOps)
[] | The Rachel and Selim Benin School
[] /\| of Computer Science and Engineering
[]//\\/ | The Hebrew University of Jerusalem
[// \\ | T +972-2-
#x27;s anything else I can do.
Thanks,
--
/| |
\/ | Yair Yarom | System Group (DevOps)
[] | The Rachel and Selim Benin School
[] /\| of Computer Science and Engineering
[]//\\/ | The Hebrew University of Jerusalem
[// \\ | T +972-2-5494522 | F
Thanks, the patch works for me (we're usually not using acl, and that's
what I've checked).
Yair.
On Sun, Jan 22 2017, sf...@users.sourceforge.net wrote:
> Hello Yair,
>
> Yair Yarom:
>> We're also seeing this issue, where removexattr returns EINVAL. O
We're also seeing this issue, where removexattr returns EINVAL. Our ro
branch is nfs (without acl), and rw branch is tmpfs (without
xattr). Mounting with noacl or with +icex doesn't help. On kernel 4.8 it
worked fine.
Simply mv'ing a directory from ext4 to the aufs will complain:
$ mv /tmp/aaa /u
On Sat, Apr 04 2015, sf...@users.sourceforge.net wrote:
> sf...@users.sourceforge.net:
>> Your case looks different a little bit from Christoph Pleger's, but it
>> must be same essentially. I've found linux NFS client always sets
>> MS_POSIXACL (which is a flag in VFS layer) even if it was mounted
On Wed, Apr 01 2015, sf...@users.sourceforge.net wrote:
> How was the configuration?
> If CONFIG_AUFS_XATTR is enabled, try this patch and specify 'verbose'
> option when mounting aufs. It will print the xattr name. If XATTR (ACL)
> causes the problem, then this patch and 'verbose' will tell us.
>
On Tue, Mar 31 2015, sf...@users.sourceforge.net wrote:
> On my test system where NFS server is linux, the first mv back failed.
> :::
> exporting localhost:/tmp/irush/export
> + mv -v /tmp/irush/nfs/a/b /tmp/irush/nfs/a/c
> `/tmp/irush/nfs/a/b' -> `/tmp/irush/nfs/a/c'
> mv: cannot move `/t
On Mon, Mar 30 2015, Yair Yarom wrote:
> On Sat, Mar 28 2015, sf...@users.sourceforge.net wrote:
>
>> Are you using user-space NFS server too?
>> If so, does this script surely reproduce the problem?
>> This script prints "0" at the end when everything is fine.
On Mon, Mar 30 2015, sf...@users.sourceforge.net wrote:
> Yair Yarom:
>> Our nfs servers are NetAPP and FreeBSD machines (not user space...).
>
> Ok.
> And your NFS client is debian 3.16.7-ckt7-1 as Christoph's?
Sorry, I've probably should have mentioned it, we compil
On Sat, Mar 28 2015, sf...@users.sourceforge.net wrote:
>
> Yair Yarom:
>> I think we encountered a similar issue, in our case with the /var/log/*
>> directories (and sometimes /var/cache/man). I don't think it's a real
>> permission issue as we get "Opera
Hello,
I think we encountered a similar issue, in our case with the /var/log/*
directories (and sometimes /var/cache/man). I don't think it's a real
permission issue as we get "Operation not supported" and not "Permission
denied".
I noticed that it happens if the rw branch doesn't contain the
di
On Sat, Jan 24 2015, Oliver Welter wrote:
> Am 24.01.2015 um 14:04 schrieb sf...@users.sourceforge.net:
>>
>> shawn wilson:
>>> I see its not mature, another example of kernel politics, and questions. I
>>> read the thread and the linked message again before writing this - I'm
>>> guessing the au
Hi,
sf...@users.sourceforge.net writes:
> At first, you should update your git tree and use the latest aufs2-33.
> Try,
> $ cd /your/aufs2-standalone.git
> $ git checkout master
> $ git pull
> $ git checkout aufs2-33
This is what was missing :-). As I said, I'm unfamiliar with git, and to
updat
Hi,
We have here diskless machines with aufsed /etc (rw tmpfs /etc_rw + ro
root /etc on /etc). When trying to run sungrid's qmaster daemon, we get
an oops. Without the aufsed /etc there's no oops (even when there are
other aufsed directories).
The kernel is 2.6.33.3 with aufs standalone from git
Hi,
Thanks, I was hoping to avoid this since it tends to be one of the things you
forget to remove or forget they are there during an update (but my other
solution was to mount /sbin using aufs :)).
Thanks,
Yair.
sf...@users.sourceforge.net writes:
> Hi,
>
> David:
>> Why don't you just w
Hi,
I am wondering what will be the effects of using aufs2 kernel with aufs1
binaries/utilities, or aufs1 kernel with aufs2 binaries.
The problem is that we have here a single root filesystem (nfs root) which uses
different kernels. We want to try new kernels but some machines will still boot
f
Hi,
Does that means that the dropped features won't be developed anymore (or in the
future)? or will they still be available (and maintained) in the cvs?
Specifically, without the NFS branch, we won't be able to use aufs.
Regards,
Yair.
sf...@users.sourceforge.net writes:
> Hello all,
>
Hi,
When running nscd (Name Service Cache Daemon) with /etc mounted from nfs and
tmpfs (aufs), the following message appears:
aufs aufs_fallocate:699:nscd[3518]: This operation is not supported. Please
report me this application.
Pid: 3518, comm: nscd Not tainted 2.6.24.2mos-2 #1
[] aufs_fallo
18 matches
Mail list logo
