--- Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote:
> On Mon, 2008-03-31 at 17:17 -0600, Ashley M. Kirchner wrote:
> > charles f. zeitler wrote:
> > > 883393808812 torrents_isos/data
> > >
> > > somethings wrong with t*s/data ....
> > >
> > This is very indicative of an open file handle not having been
> > closed properly, and even after removing the physical file, the drive
> > structure still believes it's there.
>
> That's because it is still there. Linux has no builtin operation for
> explicitly removing files, just for unlinking their names. When the last
> reference is gone, it obligingly frees the space because there's no
> longer any way to access the data. A reference means either an on-disk
> structure (a directory entry) or an in-process file handle.
>
> > In my case, that was a syslog issue where I deleted a file, but its
> > handle remained open. Restarting syslog took care of it.
>
> You unlinked the name (using 'rm'). The space was reclaimed by the
> system when the syslog process terminated.
>
> > In your case, I would suggest restarting whatever process it is that
> > writes to those files on that drive, and failing that, restart the
> > computer and force a file check on that drive.
>
> This doesn't explain why the 'du' output for torrents_isos/data gives a
> result larger than the size of the filesystem. A run of fsck should take
> care of it.
>
> poc
>
you'd think it would, eh?
oh well. i'd like to track it down, but i need the free space,
so i'll probably:
1) insert a spare drive
2) copy that dir over
3) delete original dir
4) check the original disk
if solved,
5) copy dir back.
ugh.
charles zeitler
: Do What Thou Wilt :
: Shall Be :
: The Whole of The Law :
--Aleister Crowley--
