Iustin Pop writes:
>
> More exactly, do a:
> lsof +L1
> and see if any /var/log/ files show up in this - it lists files deleted
> but still in use - for those Unix won't free space until after they are
> closed.
Could this be responsive for the unlinked inode of a cups log file
that I recovered, and reported on the list, a few weeks ago? Running
the above command today I find:
lsof +L1
COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME
cupsd 380 root 1u REG 3,5 7250 0 71364886
/var/log/cups/error_log.1 (deleted)
What's the exact sequence of events leading to filesystem corruption?
1. File is open and written to.
2. File is unlinked while open.
3. File is closed (unlinked inodes?)
4. Alternatively, system crash before close (unlinked inodes?).
Is this entirely a userspace problem (i.e., files shouldn't be
unlinked while open) or is it a Linux or XFS bug? I would say anything
resulting in unlinked inodes requiring recovery should be prevented at
the operating system level, if possible, unless there are good reasons
to the contrary.
|