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
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 and
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 c
[ ... 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 re
> 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
s enabled?
>
> yes, you've got it !
>
> 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
Softupdates works reliable from what I can tell.
Sn
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.
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)
>
>
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 f
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 flagg
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
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 num
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
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 t
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 a
command line option to background fsck, which defaults to
"3", if left unspecified), then the fsck is automatically
converted
Good idea, thanks. Nevertheless: I don't think the system 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 s
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
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
in
round 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, which it wasn'
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 t
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 sh
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
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 slo
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
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 wrote:
>
The vinum R5 and system as a whole were stable without
softupdates. Only one problem remained after disabling softupdates,
while being online and u
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste 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 vol
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 misa
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 rema
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 exper
ount -u"
> > to turn Soft Updates from "off" to "on": Soft 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,
"off" to "on": Soft 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
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
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
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
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
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
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 ...
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 & softupda
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 r
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,
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
<
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, which I had forgotten. UFS2 inodes
are only initialized when they
sual?
> > > >
> > > > It certainly 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
ual?
> >
> > It certainly 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.
>
> Still, in case yo
Thus spake Garrett Wollman <[EMAIL PROTECTED]>:
> <<[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 co
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'
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
>
< 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
background fsck works on a snapshot and not the running fi
> a bug, probably 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
&g
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 ema
: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, thoug
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
g 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
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
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 even
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.Lei
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 file
nteresting 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
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
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 use. (There's a
>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
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
>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 e
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
66 matches
Mail list logo