On Mon, Apr 18, 2016 at 6:23 PM, Robert Nichols <rnicholsNOSPAM at comcast.net> wrote:> lsof will show the sizes of the deleted files. > > lsof | grep deleted | sort -k7nThat's a reasonable G.D. answer. The only problem is that on my system, the default output includes a TID column that is present in only some of the lines, so the size column is 8 for many lines and 7 for the others, so sort doesn't work as expected unless you change lsof's output. And you probably should "grep ' (deleted)$' unless you want to see files like /home/gordon/.thunderbird/xxxxxxx.default/calendar-data/deleted.sqlite. Still, I guess I learned one thing.
Dear Friends, Finally fixed my issue. As you told i have unmount the external hard disk then i checked the /bkhdd/backup folder. I saw that 190GB backup tar.gz file then i deleted and again remount it. Thanks a lot for your kind supporting to me to fix this issue. Why it's happened like this environment and how to avoid it. On Tue, Apr 19, 2016 at 10:16 AM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> On Mon, Apr 18, 2016 at 6:23 PM, Robert Nichols > <rnicholsNOSPAM at comcast.net> wrote: > > lsof will show the sizes of the deleted files. > > > > lsof | grep deleted | sort -k7n > > That's a reasonable G.D. answer. > > The only problem is that on my system, the default output includes a > TID column that is present in only some of the lines, so the size > column is 8 for many lines and 7 for the others, so sort doesn't work > as expected unless you change lsof's output. > > And you probably should "grep ' (deleted)$' unless you want to see > files like > /home/gordon/.thunderbird/xxxxxxx.default/calendar-data/deleted.sqlite. > > Still, I guess I learned one thing. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- *Thanks,* *Manikandan.C* *System Administrator*
On 4/21/2016 7:49 PM, Chandran Manikandan wrote:> Finally fixed my issue. > As you told i have unmount the external hard disk then i checked the > /bkhdd/backup folder. > I saw that 190GB backup tar.gz file then i deleted and again remount it. > > Thanks a lot for your kind supporting to me to fix this issue. > > Why it's happened like this environment and how to avoid it.don't write to mount points when they aren't mounted, the files get written to the file system. and don't create any directories in the mount point... like, if you were mounting /dev/sdb1 as /bkhdd then on the root file ssytem (without that mount) there should never have been any /bkhdd/backup directory. in fact /bkhdd should not be writable by your user processes. I remember older Unix systems would refuse to mount a file system to a non-empty directory, for exactly this reason, it hides stuff thats already there. -- john r pierce, recycling bits in santa cruz
On 04/21/2016 07:49 PM, Chandran Manikandan wrote:> Why it's happened like this environment and how to avoid it.Generally the way to avoid it would be for your backup application to fail if the destination does not exist, and alert the admin. For instance, rsnapshot has the "no_create_root" option to do exactly that. If you're making backups with scripts of your own, just start with something like: test -d $destination || alert_admin_and_exit ...where $destination is a sub-directory under the mount point. Backing up directly to the mount point can make it more complicated to detect the presence of the mounted filesystem.