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 ridiculous. To get to the point where I could umount the aufs >> volume, by definition no programs are using it - obviously the first >> thing I did when I initially came across the problem was to 'sudo lsof >> /mnt/bulk_storage' which came up with nothing. > > How about /proc/mounts? > Does it show that aufs is unmounted? > If you run "stat -f /mnt/bulk_storage", what fs-type does it show?
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.
===================================================================
stat -f /mnt/bulk_storage
File: "/mnt/bulk_storage"
ID: 1f2a614f85a526cd Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 58920392 Free: 38925861 Available: 35927116
Inodes: Total: 14974976 Free: 13635988
===================================================================
which is fine.
> I really believe you should confirm your /mnt/bulk_storage is correctly
> unmounted as a first step. I know some people always add "-l" option
> blindly when they unmount something. As you might know, such umount
> command may not fully unmount it while it looks succeeded.
Yes, but its me issuing the command?? If it was something so trivial I
would not have bothered this list...
The very simple commands:
===================================================================
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 ‘/mnt/bulk_storage/’ to ‘/mnt/bulk-storage/’: Device or
resource busy
===================================================================
>> aufs is only used on this system for that one volume, so I tried to
>> unload it - but it refused! Hence investigating into why. When I mount
>> the volume after boot manually there is no problem umounting and then
>> renaming the underlying directory, or unloading aufs - so I know the
>> issue is being caused by something invalidly holding a reference to the
>> aufs module, and the reason I'm not raising this as an aufs bug and am
>
> As I wrote previously, I don't think the module ref-count is related to
> your EBUSY problem. Even if you have some other mounted aufs and the
> ref-count of aufs is 100, you can rename any dir which is not in use. In
> other words, even if you find out who incremented the aufs ref-count,
> fix something, succeeded making the ref-count zero and unloading aufs
> module, you may not be able to rename the dir. It is toally up to "who
> makes the dir busy."
> Even if it is aufs, I don't think searching "who increments the aufs
> ref-count" is effective.
The suspicious refcnt is all I have to go on and currently the only
difference I can see between being able to move the directory and not. I
am a programmer but not a kernel programmer, so all I have to fall on is
common sense here - if no aufs filesystems are mounted, surely there
should be no references to the aufs module, and I should be able to
rmmod without complaint?
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
