On Tue, Jul 04, 2006 at 12:43:53AM -0400, Jed Davis wrote:
> Pavel Cahyna <pavel.cahyna@st.mff.cuni.cz> writes:
> 
> > If an application unlinks a file which is opened, the file is not deleted
> > until it is closed, until that it exists as unnamed. Now if the system
> > crashes after the unlink and before the close, the unnamed file is not
> > deleted and remains in the filesystem, taking up space. This is not a
> > problem in a non-journalling scenario, because after a crash fsck is run
> > and takes care of it. But a journalling filesystem should take this into
> > account.
> 
> There is one way in which it can be a problem without journaling: if
> the filesystem is made read-only after the unlink and before the
> close.  In that case, the vnode inactivation won't delete the file
> and, worse, the FS will have been marked as "cleanly unmounted" when
> made read-only, so it's necessary to manually run fsck -f to reclaim
> the storage.

There are much worse bugs in making the filesystem read only.

This one could be solved by deleting the file on disk when the filesystem
is made read-only, I think.

Pavel