Hello,
we've experienced that background fsck on 8.1 degrades server performance on a
higher degree than in previous fbsd versions (6.3, 7.3; amd64).
We've noticed it after upgrading - same hardware - to a 8.1-RELEASE.
Now, performance of other services (i.e. apache, mysql) during a background
Hi,
I recently reinstalled my scratch box, last time I turned it off, I
didn't shut it down nicely so when I booted it today the file systems
needed a fsck.
While bgfsck was still running I started a cvsup to update /usr/ports/,
which ran fine for a while, and then stopped, and now both cvsup
On Thu, 19 Jun 2003 00:25:22 -0700
Terry Lambert [EMAIL PROTECTED] wrote:
Then you reboot.
Then you start BG fsck again.
Then you panic again.
Repeat this until a human intervenes and manually runs a full FG
fsck on the disk before letting it be used, and/or someone adds
a count-down
[ ... BG fsck ... ]
I haven't got softupdates enabled, but I didn't want to enable it,
because I've heard that it isn't 100% reliable and I didn't want to lose
data
Theer have been no problems with softupdates in regard to data
integrity in either 5.0 or 5.1 release. I do recall a
Hello!:
I tried to make my Nvidia video card work yesterday, and everytime
I launched the X system my computer hang up. So I had to
make a hard reboot.
(I think I will fix the Xs problem this night at home)
But I've got another weird problem. :)
The fsck of my partitions is always made on the
On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote:
Hello!:
I tried to make my Nvidia video card work yesterday, and everytime
I launched the X system my computer hang up. So I had to
make a hard reboot.
(I think I will fix the Xs problem this night at home)
But
On Wednesday 18 June 2003 17:39, Bernd Walter wrote:
On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote:
Hello!:
I tried to make my Nvidia video card work yesterday, and everytime
I launched the X system my computer hang up. So I had to
make a hard reboot.
(I
reliable from what I can tell.
Snapshots might have some issues and background fsck uses snapshots.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL
From: Juan Rodriguez Hervella [EMAIL PROTECTED]
Date: Wed, 18 Jun 2003 17:51:00 +0200
Sender: [EMAIL PROTECTED]
On Wednesday 18 June 2003 17:39, Bernd Walter wrote:
On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote:
Hello!:
I tried to make my Nvidia video
Thus spake Alexander Langer [EMAIL PROTECTED]:
I had several panics related to background fsck now. Once I disabled
background fsck, all went ok.
It began when I pressed the reset buttons on several boots while the
system was still doing fscks.
[...]
Mar 24 21:48:59 fump kernel: panic
Thus spake Terry Lambert [EMAIL PROTECTED]:
o Put a counter in the first superblock; it would be
incremented when the BG fsck is started, and reset
to zero when it completes. If the counter reaches
3 (or some command line specified number), then the
BG flagging is
David Schultz wrote:
Thus spake Terry Lambert [EMAIL PROTECTED]:
o Put a counter in the first superblock; it would be
incremented when the BG fsck is started, and reset
to zero when it completes. If the counter reaches
3 (or some command line specified number), then
Terry Lambert wrote:
The issue with the repeating background fsck's is important.
I suggest a counter that gets reset to zero each time the
FS is marked clean by fsck, and incremented each time the
background fsck process is started.
When this counter reaches a predefined value (I sugest
Thus spake Terry Lambert ([EMAIL PROTECTED]):
Disable write caching on your ATA drive. You should be able to
safely reset after that.
Good idea, thanks. Nevertheless: I don't think the system should
panic on background fsck's, while a manual fsck works.
Alex
To Unsubscribe: send mail to
.
A manual fsck can deal with corrupt data.
A background fsck can only deal with invalid cylinder group
bitmaps, and operates on a snapshot.
For a background fsck to be feasible, the FS has to be in a
self-consistent state already, which it wasn't.
When you killed the power on your system and reset
of the background fsck
itself: it was a result of an attempt to access FS structures
by the kernel through the FS, assuming -- incorrectly -- that
the FS structures were in a self-consistent state.
Actually I don't care _where_ the panic happened. If I hadn't manually
interupted the boot process
On Tue, 25 Mar 2003 16:04:07 +0100
Alexander Langer [EMAIL PROTECTED] wrote:
We claim background fsck as a cool new feature in the release notes,
which is even the DEFAULT, including WC on ATA disks, which is ALSO the
default. So , and if this is broken, there is a serious design flaw,
which
should
panic on background fsck's, while a manual fsck works.
A manual fsck can deal with corrupt data.
A background fsck can only deal with invalid cylinder group
bitmaps, and operates on a snapshot.
For a background fsck to be feasible, the FS has to be in a
self-consistent state already
each time the
background fsck process is started.
When this counter reaches a predefined value (I sugest a
command line option to background fsck, which defaults to
3, if left unspecified), then the fsck is automatically
converted to a foreground fsck.
This counter would be recorded in the superblock
The Anarcat wrote:
When you killed the power on your system and reset it, you
lost the cached data sitting in the ATA disk. This is due
to the fact that the ATA disk lied, and claimed that it had
committed some writes to stable storage, when in fact it had
only copied them to the disk
Hi!
I had several panics related to background fsck now. Once I disabled
background fsck, all went ok.
It began when I pressed the reset buttons on several boots while the
system was still doing fscks.
Then sometime this happened:
Mar 24 21:31:12 fump root: /dev/ad0s2g: 701589 files, 12766670
Alexander Langer wrote:
I had several panics related to background fsck now. Once I disabled
background fsck, all went ok.
It began when I pressed the reset buttons on several boots while the
system was still doing fscks.
Disable write caching on your ATA drive. You should be able
On Fri, Mar 14, 2003 at 01:16:02PM +1030, Greg 'groggy' Lehey
[EMAIL PROTECTED] wrote:
So I did. Loaned two SCSI disks and 50-pin cable. Things haven't
improved a bit, I'm very sorry to say it.
Sorry for the slow reply to this. I thought it would make sense to
try things out here, and so
On Friday, 14 March 2003 at 10:05:28 +0200, Vallo Kallaste wrote:
On Fri, Mar 14, 2003 at 01:16:02PM +1030, Greg 'groggy' Lehey
[EMAIL PROTECTED] wrote:
So I did. Loaned two SCSI disks and 50-pin cable. Things haven't
improved a bit, I'm very sorry to say it.
Sorry for the slow reply to
On Saturday, 1 March 2003 at 20:43:10 +0200, Vallo Kallaste wrote:
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste vallo wrote:
The vinum R5 and system as a whole were stable without
softupdates. Only one problem remained after disabling softupdates,
while being online and user I/O
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste vallo wrote:
The vinum R5 and system as a whole were stable without
softupdates. Only one problem remained after disabling softupdates,
while being online and user I/O going on, rebuilding of failed disk
corrupt the R5 volume
On Thu, Feb 27, 2003 at 11:59:59AM +1030, Greg 'groggy' Lehey
[EMAIL PROTECTED] wrote:
The crashes and anomalies with filesystem residing on R5 volume were
related to vinum(R5)/softupdates combo.
Well, at one point we suspected that. But the cases I have seen were
based on a
On Friday, 21 February 2003 at 10:00:46 +0200, Vallo Kallaste wrote:
On Thu, Feb 20, 2003 at 02:28:45PM -0800, Darryl Okahata
[EMAIL PROTECTED] wrote:
Vallo Kallaste [EMAIL PROTECTED] wrote:
I'll second Brad's statement about vinum and softupdates
interactions. My last experiments with
On Friday, 21 February 2003 at 1:56:56 -0800, Terry Lambert wrote:
Vallo Kallaste wrote:
The crashes and anomalies with filesystem residing on R5 volume were
related to vinum(R5)/softupdates combo. The vinum R5 and system as
a whole were stable without softupdates. Only one problem remained
dirty buffers for which a dependency does not exist, and
will crap out when a pending dirty buffer causes a write.
Does this affect background fsck, too (on regular, non-vinum
filesystems)? From what little I know of bg fsck, I'm guessing not, but
I'd like to be sure. Thanks
Updates does not
tolerate dirty buffers for which a dependency does not exist, and
will crap out when a pending dirty buffer causes a write.
Does this affect background fsck, too (on regular, non-vinum
filesystems)? From what little I know of bg fsck, I'm guessing not, but
I'd like
On Thu, Feb 20, 2003 at 02:28:45PM -0800, Darryl Okahata
[EMAIL PROTECTED] wrote:
Vallo Kallaste [EMAIL PROTECTED] wrote:
I'll second Brad's statement about vinum and softupdates
interactions. My last experiments with vinum were more than half a
year ago, but I guess it still holds. BTW,
Vallo Kallaste wrote:
The crashes and anomalies with filesystem residing on R5 volume were
related to vinum(R5)/softupdates combo. The vinum R5 and system as
a whole were stable without softupdates. Only one problem remained
after disabling softupdates, while being online and user I/O going
Vallo Kallaste [EMAIL PROTECTED] wrote:
I'll second Brad's statement about vinum and softupdates
interactions. My last experiments with vinum were more than half a
year ago, but I guess it still holds. BTW, the interactions showed
up _only_ on R5 volumes. I had 6 disk (SCSI) R5 volume in
At 2:28 PM -0800 2003/02/20, Darryl Okahata wrote:
Did you believe that the crashes were caused by enabling softupdates on
an R5 vinum volume, or were the crashes unrelated to vinum/softupdates?
I can see how crashes unrelated to vinum/softupdates might trash vinum
filesystems.
Using
David Schultz [EMAIL PROTECTED] wrote:
IIRC, Kirk was trying to reproduce this a little while ago in
response to similar reports. He would probably be interested
in any new information.
I don't have any useful information, but I do have a data point:
My 5.0-RELEASE system
At 9:15 AM -0800 2003/02/19, Darryl Okahata wrote:
* The UFS1 filesystem in question (and I assume that it was UFS1, as I
did not specify a filesystem type to newfs) is located on a RAID5
vinum volume, consisting of five 80GB disks.
* Softupdates is enabled.
You know, vinum
Brad Knowles [EMAIL PROTECTED] wrote:
You know, vinum softupdates have had bad interactions with each
other for as long as I can remember. Has this truly been a
consistent thing (as I seem to recall), or has this been an
on-again/off-again situation?
Ah, yaaah. Hmm
Hi
Several seconds into background fsck, this happens. It's easily
repeatable by enabling background fsck and booting after an unclean
shutdown.
Kernel is 2003-02-19 from source checked out on that day (SMP).
The filesystems are UFS1 with softupdates.
panic: vm_fault: fault on nofault entry
Hi all,
I just wanted to tell that I can deadlock one of my current boxes
with a ufs2 filesystem on a 120GB ATA disk. I can reproduce
the problem. The background fsck process hangs some time at the
same place always at the same place, sometimes the box freezes
after some time.
The same box
Thus spake Martin Blapp [EMAIL PROTECTED]:
I just wanted to tell that I can deadlock one of my current boxes
with a ufs2 filesystem on a 120GB ATA disk. I can reproduce
the problem. The background fsck process hangs some time at the
same place always at the same place, sometimes the box
in the background fsck code. Still, is there any way to
reclaim the file now, besides running strings(1) on the whole partition?
Consider what happens when you remove a large directory tree.
Thousands of directory entries may be removed, but in the
softupdates case, the inodes will stick around a bit
On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki
[EMAIL PROTECTED] said:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
On Wed, 22 Jan 2003, Garrett Wollman wrote:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
background fsck works on a snapshot
hi, there!
On Wed, Jan 22, 2003 at 07:18:44PM +0100, Jan Srzednicki wrote:
Would that be a big problem to allow some fsck option not to erase all
these softupdates-pending inodes, but to put them in lost+found as usual?
It certainly couldn't be done with the background fsck, because
couldn't be done with the background fsck, because
background fsck works on a snapshot and not the running filesystem;
thus, it cannot make any allocations -- it can only deallocate things.
Actually, that should work just fine. When background fsck
notices an unreferenced inode in the snapshot
be done with the background fsck,
because background fsck works on a snapshot and not the
running filesystem; thus, it cannot make any allocations -- it
can only deallocate things.
Still, in case you know some of your important files can be lost,
you can boot the system to single user
with the background fsck,
because background fsck works on a snapshot and not the
running filesystem; thus, it cannot make any allocations -- it
can only deallocate things.
Still, in case you know some of your important files can be lost,
you can boot the system to single user and run
On Wed, 22 Jan 2003 11:32:12 -0800, David Schultz [EMAIL PROTECTED]
said:
Unfortunately, I think it is possible that the unreferenced inode
has not been initialized, even though it is allocated in the inode
bitmap, so you could potentially get random junk.
That is definitely true on UFS2,
occured on /usr, but still, one file in /home
got lost - which happened to be quite important file. Background fsck
logged:
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065
OWNER=winfried MODE=100644
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20
15:57 2003
, but still, one file in
/home got lost - which happened to be quite important file.
Background fsck logged:
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065 OWNER=winfried
MODE=100644
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003
(CLEARED
Thus spake Jan Srzednicki [EMAIL PROTECTED]:
This massive disk mangling occured on /usr, but still, one file in /home
got lost - which happened to be quite important file. Background fsck
logged:
Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065
OWNER=winfried MODE=100644
:However, when you are saving a new version of an important file,
:you need to be careful that the new version (and its directory
:entry) hits the disk before the old one goes away. I know that vi
:saves files in a safe way, whereas ee and emacs do not. (Emacs
:introduces only a small race,
Thus spake Matthew Dillon [EMAIL PROTECTED]:
:However, when you are saving a new version of an important file,
:you need to be careful that the new version (and its directory
:entry) hits the disk before the old one goes away. I know that vi
:saves files in a safe way, whereas ee and emacs do
Environment: IBM ThinkPad 600E with fresh RC2 installation
Failure:
mode = 041777, inum = 534, fs = /usr
panic: ffs_valloc: dup alloc
syncing disks, buffers remaining... panic: bwrite: buffer is not
busy???
I was unable to bring up the system long enough to build a new kernel
with debug (or
This was on an x86, 5.0-current as of roughly 8am EST today.
Machine panic'ed when it finished /usr and moved on to /var on
a manually invoked fsck -B (I'd hit ^C to abort multi-user startup
during fsck and was surprised to see the system continue on.. ;)
Drew
panic: ffs_blkfree: freeing free
!= 0xdeadc0de)
~a minute after this the system rebootet (I've used X at that time, so
no handwritten panic strings), no core dump.
I know background fsck isn't mature yet, this is just for the
bughunters.
Bye,
Alexander.
--
Speak softly and carry a cellular phone.
http://www.Leidinger.net
hi,
after some weeks without softupdates, i recently reenabled them on my
notebook. it seems, that my problems still exist. background checking
one of my partitions leads to a panic() complaining about some block
too large error. sorry, i didn't capture the message, and for obvious
reasons i
On 19-May-01 Matthew Thyer wrote:
Is it possible that background fsck is not the culprit here ? I think
this may be fallout from the dirpref changes as Chris Knight recently
emailed in 018b01c0c496$07ed13d0$[EMAIL PROTECTED]. The solution
is to unmount all your filesystems, fsck them
I had exactly the same thing happen to /var on an SMP test box using
-current as of 16 May. It happened once out of about a half dozen panics.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
thing is that it always happens on /usr and /cvs
and no other partitions. Both of these partitions have large
directory hierarchies
Also, FWIW it now takes nearly 30 minutes to fsck my laptop's disk
(20Gb 5400rpm). That's not good
Has anyone else been trying out the background fsck
Has anyone else been trying out the background fsck? Last night I was working
on the ithread code some and managed to panic my laptop while ejecting a pccard.
Anyways, the kernel ate itself while trying to flush its buffers and I ended up
with a dirty filesystem. I rebooted and let fsck -p do
Date: Thu, 17 May 2001 14:31:55 -0700 (PDT)
From: John Baldwin [EMAIL PROTECTED]
Has anyone else been trying out the background fsck?
A little; despite my desire to help debug things, getting to a point
where doing this is appropriate isn't something I am all too eager to do.
Thus, it wasn't
On Thu, 17 May 2001, David Wolfskill wrote:
:From: John Baldwin [EMAIL PROTECTED]
:
:Hmm, that's odd, I did have soft updates on on /usr and /var before the crash.
:It seems to be off now. :(
:
:That also happened to me. I thought it odd at the time, but forgot to
:mention it At least I
Date: Thu, 17 May 2001 22:30:03 -0500 (CDT)
From: David Scheidt [EMAIL PROTECTED]
Does tunefs update the alternate superblocks when it enables soft updates?
It doesn't look it does, but I might be missing something.
I could easily have overlooked something myself, but it doesn't appear
to do so
cc list trimed.
On Thu, 17 May 2001, David Wolfskill wrote:
:(I see it does want the file system clean when soft updates is enabled,
:but doesn't check for that for a disable request.)
:
Right. fsck(8) can make assumptions about the state of the filesystem if it
knows that softupdates were in
66 matches
Mail list logo
