On 06/02/15 19:16, sf...@users.sourceforge.net wrote:
Hello OmegaPhil,
OmegaPhil:
I'm looking into the inability to rename a directory that is used as an
aufs mountpoint, after the aufs volume has been unmounted - it reports
that the 'device is busy'. The problem shows itself so far
On 07/02/15 01:54, sf...@users.sourceforge.net wrote:
OmegaPhil:
I simply use mount/umount to do and confirm this.
The aufs volume is basically used to pool disks in a RAID0 fashion
without the risk, which is mainly holding up, thanks :)
??
Totally I don't understand what you wrote
On 08/02/15 15:03, sf...@users.sourceforge.net wrote:
OmegaPhil:
The reason I focussed on the refcnt is because I'd done the obvious
basic stuff - the aufs mount point (/mnt/bulk_storage) only exists for
the purpose of mounting the aufs volume, so for it to be 'busy' for no
reason
On 08/02/15 17:54, sf...@users.sourceforge.net wrote:
OmegaPhil:
I've gone through this procedure - everything is fine. This is as
expected as originally I said this problem only arose when the aufs
volume was mounted at boot via fstab - when you do it later on
everything is fine
On 11/02/15 02:54, sf...@users.sourceforge.net wrote:
OmegaPhil:
I will continue fighting this as a cgmanager bug, but any idea why aufs
doesn't know that the reference is still held?
??
Again I don't understand.
You could not rmmod aufs. It is because your system knows the reference
On 10/02/15 14:08, OmegaPhil wrote:
I'll start fiddling with the boot scripts again now.
I have spent the last 4 hours repeatedly booting the machine,
rediscovering Debian's init.d scripts are called in parallel etc...
finally demonstrated that the problem is being caused by cgmanager. I'll
On 10/02/15 17:56, OmegaPhil wrote:
On 10/02/15 14:08, OmegaPhil wrote:
I'll start fiddling with the boot scripts again now.
I have spent the last 4 hours repeatedly booting the machine,
rediscovering Debian's init.d scripts are called in parallel etc...
finally demonstrated
On 09/02/15 15:10, Mike wrote:
On Sun, 08 Feb 2015 16:03:01 +
OmegaPhil omegap...@startmail.com wrote:
I have just tested again, '/proc/mounts' agrees with mount output -
nothing is mounted at '/mnt/bulk_storage', and no other aufs mounts
are present
On 27/07/15 00:36, Ben Hutchings wrote:
On Fri, 2015-07-24 at 19:26 +0100, OmegaPhil wrote:
On Monday 25 May 2015 04:55 PM, sf...@users.sourceforge.net wrote:
Ritesh Raj Sarraf:
Anyways, in the standalone tree, there are a bunch of patches with no
order defined. Is it to assume that they can
On Monday 25 May 2015 04:55 PM, sf...@users.sourceforge.net wrote:
Ritesh Raj Sarraf:
Anyways, in the standalone tree, there are a bunch of patches with no
order defined. Is it to assume that they can all be applied randomly ?
No.
Please refer to README file in aufs4-standalone.git.
On 20/11/15 23:42, sf...@users.sourceforge.net wrote:
> Hello OmegaPhil,
>
> OmegaPhil:
>> For some time now (across kernel versions, aufs versions, machines, etc)
>> I have noticed kernel memory allocation failures intermittently when
>> something lists a large aufs
On 21/11/15 14:25, OmegaPhil wrote:
> On 20/11/15 23:42, sf...@users.sourceforge.net wrote:
>> Hello OmegaPhil,
>>
>> OmegaPhil:
>>> For some time now (across kernel versions, aufs versions, machines, etc)
>>> I have noticed kernel memory allocation failures
On 24/11/15 05:27, sf...@users.sourceforge.net wrote:
> OmegaPhil:
> :::
>> repos, so I'm using this - currently the rsync init.d script has been
>> edited to export the right LD_PRELOAD and LIBAU values, and I've
>> confirmed the library has been loaded via:
>&g
On 20/01/16 22:01, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> It has now been some time since I got the kernel memory allocation
>> failures, so clearly the libau hack has fixed it - thanks.
>
> Glad to hear that!
> (Honestly speaking, I totally
On 21/01/16 19:39, OmegaPhil wrote:
> On 20/01/16 22:01, sf...@users.sourceforge.net wrote:
>> OmegaPhil:
>>> It has now been some time since I got the kernel memory allocation
>>> failures, so clearly the libau hack has fixed it - thanks.
>>
>> Glad to hear
On 24/11/15 12:59, OmegaPhil wrote:
> On 24/11/15 05:27, sf...@users.sourceforge.net wrote:
>> OmegaPhil:
>> :::
>>> repos, so I'm using this - currently the rsync init.d script has been
>>> edited to export the right LD_PRELOAD and LIBAU values, and I've
&
On 20/01/16 20:41, OmegaPhil wrote:
> On 24/11/15 12:59, OmegaPhil wrote:
>> On 24/11/15 05:27, sf...@users.sourceforge.net wrote:
>>> OmegaPhil:
>>> :::
>>>> repos, so I'm using this - currently the rsync init.d script has been
>>>> edi
On 26/01/16 05:50, sf...@users.sourceforge.net wrote:
> Sorry for my late reply.
>
> OmegaPhil:
>> Suddenly the VM doesn't error anymore in the particular test I set up,
>> so back on the server, I fiddled with the rsync init.d script and ran
>> the daemon via '
On 26/01/16 21:23, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> Here is the raw ioctl trace:
> :::
>> [pid 10412] ioctl(0x6, 0xc0404100, 0x74878360) =3D -1 (errno 22)
> :::
>
> Ok, the value 0xc0404100 is correct.
> Just to make sure, I'd ask
files (and then the whiteout) when they 'should' have
been whiteouted from this perspective?
From eb24fdc4ce45496adca0eb3f04ed5db528076fa7 Mon Sep 17 00:00:00 2001
From: OmegaPhil <omegap...@startmail.com>
Date: Sun, 17 Jul 2016 12:39:51 +0100
Subject: [PATCH 1/2] Error objects do not have m
On 03/08/16 01:31, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> 'rdu[rdu_cur++] =3D p;' is failing as rdu is NULL.
>
> Thanx for debugging.
> Now I can understand the bug.
> libau forgot supporting a simple opendir + closedir case (no readdir).
>
Just throwing this out so that people can search on it:
I now have an example file with a filename length of 100 characters,
however most will be wide characters since its mainly Japanese - in python:
=
len(file_name)
100
len(bytes(file_name.encode()))
246
I'm currently looking into the following repeatable crash when I browse
to the root of a large aufs volume with FileZilla:
Program received signal SIGSEGV, Segmentation fault.
0x7fbd72a6988e in rdu_buf_lock () from
On 02/08/16 02:36, sf...@users.sourceforge.net wrote:
> Hello OmegaPhil,
>
> OmegaPhil:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7fbd72a6988e in rdu_buf_lock () from /usr/lib/libau.so
>> (gdb) bt
>> #0 0x7fbd72a6988e in rdu_buf_loc
On 01/08/16 21:54, OmegaPhil wrote:
> I'm currently looking into the following repeatable crash when I browse
> to the root of a large aufs volume with FileZilla:
>
>
>
> Program received signal SIGSEGV,
sfjiro, please can you test the following git commands for me on a
non-aufs filesystem with libau LD_PRELOAD'd:
=
git clone https://git.devuan.org/OmegaPhil/udisks2.git
git remote add alioth-git
https://anonscm.debian.org
On 22/01/17 22:09, sf...@users.sourceforge.net wrote:
> I didn't check the source files of git-fetch, but this symptom indicates
> that git-fetch incorrectly tests errno after libau:closedir() returned a
> success.
> libau can fix this problem (see the attachment again), but it is
> definitly
On 05/10/16 05:24, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> CC is unset, here is the original make command:
>
> Ok, thanx.
> I will apply this and release next Monday.
>
> $ .../aufs-util.git$aufs4.1$ git diff -w
> diff --git a/Makefile b/Makefile
>
On 02/10/16 21:36, sf...@users.sourceforge.net wrote:
> Hello OmegaPhil,
> Thanx for reporting.
>
> OmegaPhil:
>> I'm currently updating aufs-util in the usual way (looks like aufs4.1 is
>> the latest branch), building succeeds but make install fails with the
>> fo
On 05/10/16 21:56, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> Sorry, I've put this email through patch, and then manually copied out
>> the text and tried again, but the patch doesn't apply. Is this supposed
>> to go on top of aufs4.1?
>
> Sorry. There is anot
On 05/10/16 17:52, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> Reading the top of the main Makefile, I'm assuming that test_glibc is
>> doing a compilation that always happens regardless of the make target
>> requested.
>
> You are right.
> Although I don'
I'm currently updating aufs-util in the usual way (looks like aufs4.1 is
the latest branch), building succeeds but make install fails with the
following:
===
make[1]: Entering directory
32 matches
Mail list logo
