Re: fsck of large volume with small memory

On 25 Sep, sam wrote:
sam wrote:
Don Lewis wrote:
On 24 Sep, sam wrote:
Expect major file system lossage ...
I think this patch could be better, but this should get you going ...




UNEXPECTED SOFT UPDATE INCONSISTENCY
LOST 74 DIRECTORIES

UNEXPECTED SOFT UPDATE INCONSISTENCY
fsck: /dev/aacd0s1f: Segmentation fault: 11

It would be good to know the cause of this segfault so that the code
could be fixed to prevent it.

#
======================================================

/Vladimir Ermakov


# cat /etc/rc.conf |grep fsck
fsck_y_enable="YES"
background_fsck="NO"

hm, and after system reboot

=================================================
# fsck /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
438959 files, 3567329 used, 69528964 free (94684 frags, 8679285 blocks,
0.1% fragmentation)
#
=================================================

That's the fastest way of getting the file system back into a consistent
state (or you could run "fsck -y" in single-user mode), but it increases
the probability of data loss. The problem is that my patch allows fsck
to examine a bunch of uninitialized inodes in the damaged cylinder
group, and there is the possibility that one or more of these inodes
could look reasonably valid and contain block pointers that point to
blocks in valid files. Fsck will then detect the duplicate block
pointers and clear the inodes for both files. It would be nice if fsck
could be told to put less trust in the inodes that might not actually be
initialized, but this gets complicated ...

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: fsck of large volume with small memory
    ... The patch below should allow a manual fsck to run to completion. ... inodes that are unmasked by setting cg_initediblk to its maximum ... Expect major file system lossage ... ... (Like, say, if there are directories hidden beneath the corrupt inode.) ...
    (freebsd-hackers)
  • Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
    ... It'd be easy to rewrite it from scratch if IFS were recovered. ... In the slightly less intrusive Arla view of the world, cache files do appear in the UFS name space, but an independent namespace is maintained by the cache manager, each with two file system names: a normal path, and its NFS file handle, which can be used to open, stat, etc, the file without a normal file system namespace operation. ... The user application can allocate a set of inodes in some arbitrary directory tree using normal operations, but when it does so also query the NFS file handles for the files using getfh. ...
    (freebsd-stable)
  • RE: serioup problem after running fsck
    ... I'm not an expert in recovery and I'm not sure you could recover at ... > The easiest and first thing is to run fsck again (although I ... Running it once is no guarantee that the file system ... > shutdown command from the command line or the shutdown menu ...
    (RedHat)
  • fstab entries for external USB hard drives led to fsck.ext3 failure on boot, bug?
    ... 'F!3@$%ing fsck! ... Please repair the file system manually. ... CONTROL-D will terminate this shell and resume system boot. ... were to allow me to quickly mount an external hard drive ...
    (Debian-User)
  • Re: fsck - how to use?
    ... I got some lost files and some other file system ... > that there aren't any problems with the files on the disk as a result of the ... > that it is dangerous to run fsck on a mounted partition. ...
    (linux.redhat.misc)