[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upgrade Problem

On Fri 04 Jan 2019 at 16:18:03 (-0500), Roberto C. Sánchez wrote:
> On Fri, Jan 04, 2019 at 02:39:40PM -0600, David Wright wrote:
> > 
> > There's at least one other scenario that it would be worth eliminating
> > by checking that this equation is true (allowing for filesystem overheads):
> > 
> >   # du -shx
> >         +
> >   $ df's Available
> >         ≃
> >  partition's size.
> > 
> > This checks whether the mountpoints for /var and so on had files in
> > them before the partitions were mounted. These files would consume
> > filespace but not be detected by du.
> > 
> It might also indicate files that exist (i.e., occupy blocks) without
> having directory entries.  For example, this is the case when a program
> creates a temporary file, gets the descritor back from the syscall, then
> immediatley calls unlink on it.  The file descriptor is still active and
> the file can be written/read with the descriptor reference, but the file
> cannot be seen with 'ls' and, as I recall, it will not show up in the
> calculation made by 'du'.  The calculation made by 'df' will still be
> accurate, though.
> So, you might ask yourself, why would a program create a file only to
> immediately unlink it?  Well, it happen that if the program terminates
> abnormally (i.e,. crashes), the disappearance of the reference to the
> file descriptor when the kernel cleans up the process table also causes
> it to free the associated blocks.  The same thing happens in a normal
> program termination, but in the abnormal case you have no guarantee that
> any clean up code will run.
> As it happens, this is a great practical interview question for a system
> administrator.  Give them a machine where 'df' reports no free space but
> 'du' says it is not all used up and see if they know why that might be
> the case and how to resolve it.

Yes, that's a standard trick used by browsers when they're playing
videos etc. In fact, I have a program called hoover-streams.py for
just this case. It finds out the browser programs' PIDs and searches
/proc/$PID/fd/ for any that are connected to deleted files. Then it
copies from the file descriptors repeatedly, into files named from
wallclock time, printing the size so far and the filename, prefixed
by a + if something was just copied into that file and - if it wasn't.
(This corresponds to the right marker in the progress bar under the
video; the left one shows how far you've viewed it).
When you haven't seen + for a while, the files should all be complete.

But it does seem unlikely that the OP is going to have GB of files
being hung onto like this, even a chemist. :)


Reply to: