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.

I mention this here in case it's useful to compare it with the
journaled situation.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))