fsck is failing to clean a filesystem

Polytropon freebsd at edvax.de
Tue Feb 9 03:15:22 UTC 2016


On Mon, 8 Feb 2016 22:32:24 -0430, Alberto Mijares wrote:
> > However, the fsck output indicates a quite heavy file system
> > inconsistency problem. In worst case, mount -o ro, copy all
> > files, re-initialize the filesystem with newfs, and then copy
> > the files back. Use tar or rsync or cpio to make sure all the
> > file attributes are properly transferred. This should be possible
> > in case you cannot resolve the filesystem problem.
> >
> > And check if /usr/lost+found does already contain something.
> > Just in case.
> >
> 
> I wonder if mounting an external disk on /usr/lost+found can help.
> Don't know, just guessing ;-)

It _might_ be possible, but the lost+found/ subdirectory should be empty
in order to work as a proper mountpoint. On the other hand, fsck does
operate on a "lower" filesystem level, so when an external filesystem
is mounted, it could stop working as intended. The "lost+found mechanism"
usually reconnects files or directories in a manner where an i-node is
not connected to a file or directory entry, but also not marked as free.
In this case, it will be assigned a new name (usually #1234567890 for
the i-node number 1234567890) and established inside lost+found. All
the "appended" content, being a file or a directory full of files,
will then be available by this new name. The i-node now will be
properly marked as in use. Filesystem consistency can be re-established
this way.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list