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
Darryl Okahata wrote:
> Terry Lambert <[EMAIL PROTECTED]> wrote:
> > I think this is an expected problem with a lot of concatenation,
> > whether through Vinum, GEOM, RAIDFrame, or whatever.
> >
> > This comes about for the same reason that you can't "mount -u"
> > to turn Soft Updates from "off" t
Terry Lambert <[EMAIL PROTECTED]> wrote:
> I think this is an expected problem with a lot of concatenation,
> whether through Vinum, GEOM, RAIDFrame, or whatever.
>
> This comes about for the same reason that you can't "mount -u"
> to turn Soft Updates from "off" to "on": Soft Updates does not
>
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
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, sometimes the box f
<
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
hi, there!
On Wed, Jan 22, 2003 at 02:43:37PM -0500, Garance A Drosihn 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 b
At 12:53 AM +0600 1/23/03, Max Khon wrote:
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
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 couldn't be done with the background fsck, becau
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, b
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 snap
< 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 filesystem;
thus, it
On Mon, 20 Jan 2003, David Schultz wrote:
> > First two entries clearly correspond to the missing file, which should
> > have been put in /home/lost+found. But, the poroblem is that no lost+found
> > directory was created, while it should (as fsck_ffs(8) says). I guess its
> > a bug, probably in t
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
> OWNER=winfried MODE=1
In the last episode (Jan 20), Jan Srzednicki said:
> After building new world and installing new kernel, I rebooted my
> machine to launch a new kernel. The system mysteriously failed to
> flush 22 disk buffers, and after reboot fsck was launched.
[...]
> This massive disk mangling occured on /usr
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
This happens to me ``almost all the time'' on my dev box:
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/ad0s1a 25406382600 15113835%/
devfs110 100%/dev
procfs 440 100%/
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 eager to do.
Thus, it wasn'
36 matches
Mail list logo
