On 11/02/15 13:35, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> The crux of the problem is aufs returned success when unmounting, when
>> it shouldn't have as not everything had released references to the
>> volume. That was my question.
>
> Still I don't understand what you wrote.
> It woul
OmegaPhil:
> The crux of the problem is aufs returned success when unmounting, when
> it shouldn't have as not everything had released references to the
> volume. That was my question.
Still I don't understand what you wrote.
It would be better if you write a simple script or C program
(in system
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 referen
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
to the module is held, right?
Do you mean that every module sh
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 tha
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
tr
On 09/02/15 15:10, Mike wrote:
> On Sun, 08 Feb 2015 16:03:01 +
> OmegaPhil 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.
>>
>> =
OmegaPhil:
> I have now managed to get a script to run prior to mountall.sh, which
> demonstrated nothing held a reference to aufs at that point. I then put
> the kernel tracing stuff into the script, but it completely failed to
> record anything obtaining a reference to aufs prior to the X login
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.
>
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.
Then what will happen if you put 0 - 6 steps just before moun
On 08/02/15 16:24, sf...@users.sourceforge.net wrote:
> OmegaPhil:
>> omega@omega1:/mnt$ sudo umount /mnt/bulk_storage
>> omega@omega1:/mnt$ sudo lsof /mnt/bulk_storage/
>> omega@omega1:/mnt$ sudo mv /mnt/bulk_storage/ /mnt/bulk-storage/
>> mv: cannot move =91/mnt/bulk_storage/=92 to =91/mnt/bulk-s
OmegaPhil:
> omega@omega1:/mnt$ sudo umount /mnt/bulk_storage
> omega@omega1:/mnt$ sudo lsof /mnt/bulk_storage/
> omega@omega1:/mnt$ sudo mv /mnt/bulk_storage/ /mnt/bulk-storage/
> mv: cannot move =91/mnt/bulk_storage/=92 to =91/mnt/bulk-storage/=92: Dev=
> ice or
> resource busy
OK, then probabl
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 is
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 is ridiculous. To get to the point where I could umount the au
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 w
2015-02-07 2:54 GMT+01:00 <[1]sf...@users.sourceforge.net>:
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 :)
??
Tota
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.
Let's begin with the man-page of rename(2).
EBUSY
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
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 as a refcnt
> on the aufs module of 1, after this single aufs
19 matches
Mail list logo
