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. > Let's begin with the man-page of rename(2). > > EBUSY The rename fails because oldpath or newpath is a directory > that is in use by some > process (perhaps as current working directory, or as root > directory, or because it > was open for reading) or is in use by the system (for > example as mount point), > while the system considers this an error. (Note that there is > no requirement to > return EBUSY in such cases--there is nothing wrong with doing > the rename anyway-- > but it is allowed to return EBUSY if the system cannot > otherwise handle such situa- > tions.) > > The module ref-count is unrelated here. > I'd suggest you to check these. > - what is your current working dir? > - what are the src- and dst-path are you rename-ing? > - how do you make it sure that no one is using these dirs? > - how do you make it sure that these dirs are not mount-point?
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. 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 just asking for guidance is because it sounds like anything can get a reference to a kernel module, so I can't just pin the problem on aufs by default? Thanks.
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/
