On 20140513_0014+1000, David wrote: > On 12 May 2014 23:45, Ron Leach <ronle...@tesco.net> wrote: > > On 11/05/2014 22:07, Sven Joachim wrote: > >> > >> A simple "mount --bind / /mnt" makes all those files > >> visible under /mnt, and you can delete them at your leisure. > >> > > > > I mounted the root partition at /mnt/test and used du. > > > > server4:/home/ron# du /mnt/test/mnt -hx --max-depth=1 > > 2.7G /mnt/test/mnt/backupserver > > 0 /mnt/test/mnt/test > > 2.7G /mnt/test/mnt > > server4:/home/ron# > > > > The 2.7GB is the remnant of a first backup attempt to a new backup server. > > We backup over NFS, to a server mounted at /mnt/backupserver. > > > > During that backup trial, the new backup server was not configured > > correctly, and this machine had not - actually - seen it, though it had > > appeared to do so. As a result, this machine tried to do a backup to that > > destination, /mnt/backupserver, and had - evidently - filled the root > > partition before complaining about space. > > > > I hadn't understood - then - what had happened, and I corrected (only) the > > missing NFS export and connectivity. That fix meant that the mountpoint no > > longer 'pointed' to a set of directories on the root partition but - instead > > - to the NFS export (correctly). A 'proper' backup then succeeded; what I > > hadn't realised, until now, was that the original set of failed-test > > directories was still there, filling the partition and, moreover, now > > invisible. > > Whenever I create a directory that is going to be a mountpoint, I immediately > set its immutable attribute to prevent exactly this. Nothing can be > written in an > immutable directory. chattr must be run by root user. > > # mkdir mountpoint > # chattr -V +i mountpoint
The fact that a mountpoint can be mis-interpreted by the system for the root of a directory sub-tree on the parent disk has been around, as a gotcha, pretty much from the beginning of Unix. 'mountpoint' is also the name of a test program that allows a sysadmin to test for this situation. Too much name space overloading here, IMHO, but I can't make a good suggestion as to what to do about it ;-) -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140512155214.ga32...@big.lan.gnu
