07.01.2013 03:15, Kirk McKusick пишет:
Date: Wed, 02 Jan 2013 00:46:53 +0400
From: Alex Keda ad...@lissyara.su
To: curr...@freebsd.org
Subject: fsck problem
so, whats reason for use SUJ?
SUJ is used to speed up the fsck process. If you have had hard disk
errors then it is not able to recover
Starting file system checks:
/dev/label/rootFS: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/label/rootFS: clean, 11916812 free (74068 frags, 1480343 blocks,
0.5% fragmentation)
** SU+J Recovering /dev/label/homeFS
** Reading 33554432 byte journal from inode 12.
** Building recovery table.
**
On 10.03.2012 14:01, jb wrote:
Hi,
FB9.0-RELEASE; no updates or recompilation.
In multi-user mode:
$ mount
/dev/ada0s2a on / (ufs, local, journaled soft-updates)
The fs was in normal state (no known problem, clean shutdown),
Booted by choice in single-user mode.
# mount
/dev/ada0s2a on /
Please file a PR and put as much debugging output as you can.
I haven't had it fail for me on any of my test machines that panic
_very frequently_. But I only hvae a single disk with minimal IO, I
haven't had it crash doing lots of ongoing server style iO.
adrian
On 11 March 2012 00:19, Alex
Adrian Chadd adrian at freebsd.org writes:
Please file a PR and put as much debugging output as you can.
...
Because this is a case of clean shutdown and oing on purpose to single user
mode to see how these hings behave, I assume I can go and try again and collect
similar info.
But, is there
Hi,
I think you've included enough info. I don't know if fsck is supposed
to work that way with journalling but if not, it'd be nice to get that
documented.
I'd also like to see that timestamp mismatch print out the
timestamps so we can see what's going on. Eg, if your clock is somehow
skewing.
Hi,
FB9.0-RELEASE; no updates or recompilation.
In multi-user mode:
$ mount
/dev/ada0s2a on / (ufs, local, journaled soft-updates)
The fs was in normal state (no known problem, clean shutdown),
Booted by choice in single-user mode.
# mount
/dev/ada0s2a on / (ufs, local, read-only)
# fsck -F
On Sun, 22 Oct 2000 [EMAIL PROTECTED] wrote:
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
the problem.
With just a quick review of the patch, I'm not sure I
understand what forces the last dirty buffer to be
written.
This worried me too.
Try the enclosed patch. It
See below..
- Bruce Evans's Original Message -
On Sun, 22 Oct 2000 [EMAIL PROTECTED] wrote:
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
the problem.
With just a quick review of the patch, I'm not sure I
understand what forces the last dirty buffer to be
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
the problem.
With just a quick review of the patch, I'm not sure I
understand what forces the last dirty buffer to be
written.
revert the patch? try to fix it? comments?
Try the enclosed patch. It flushes the dirty buffer before
Hi,
I posted a question concerning fsck yesterday. A number of
people replied with the 'bad harddisk' comment.
I have followed up some more on the problem, and can now
reproduce it on different filesystems.
Below, I umount my /usr/obj, newfs it, mount it, unmount
it, and then fsck it.
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
the problem.
With just a quick review of the patch, I'm not sure I
understand what forces the last dirty buffer to be
written.
revert the patch? try to fix it? comments?
-John
- John W. De Boskey's Original Message -
Hi,
I
12 matches
Mail list logo
