headers
Jukka Marin | 1 Oct 2009 06:42
Picon

Re: softdeps and NetBSD 6.0

On Wed, Sep 30, 2009 at 03:47:34PM -0400, Thor Lancelot Simon wrote:
> On Wed, Sep 30, 2009 at 08:44:38PM +0200, Marc Balmer wrote:
> >
> > there is also a middle ground.  the code/filesystem could just be left  
> > there for people to use it, with all it's "known bugs".
> 
> Not really.  As Andy pointed out when he originally proposed removing
> softdep, the softdep implementation we actually have (as opposed to the
> one we might perhaps like to have) is entangled in various horrible ways
> with the FFS, UFS, and VM code.  Having it in there makes maintaining all
> of that code harder and makes developing new code that interacts with any
> of those parts of the system harder.  And in more than one case, the
> softdep code -- when not in use! -- has caused serious bugs in the other
> components of the system which is touches.

Does this also apply to FreeBSD softdeps code (I guess so)?

  -jm
Permalink | Reply | 1 comment |
headers
Marc Balmer | 1 Oct 2009 08:12
Picon
Favicon

Re: softdeps and NetBSD 6.0


Am 30.09.2009 um 21:47 schrieb Thor Lancelot Simon:

> On Wed, Sep 30, 2009 at 08:44:38PM +0200, Marc Balmer wrote:
>>
>> there is also a middle ground.  the code/filesystem could just be  
>> left
>> there for people to use it, with all it's "known bugs".
>
> Not really.  As Andy pointed out when he originally proposed removing
> softdep, the softdep implementation we actually have (as opposed to  
> the
> one we might perhaps like to have) is entangled in various horrible  
> ways
> with the FFS, UFS, and VM code.  Having it in there makes  
> maintaining all
> of that code harder and makes developing new code that interacts  
> with any
> of those parts of the system harder.  And in more than one case, the
> softdep code -- when not in use! -- has caused serious bugs in the  
> other
> components of the system which is touches.
>
> In other words, there's a huge opportunity cost to leaving the softdep
> code in the kernel.  By comparison, the wapbl code is much cleaner and
> better modularized -- its one major wart is that it duplicates  
> ufs_rename(),
> which means bugs can need to be fixed twice, but on the other hand  
> that
> means wapbl bugs are isolated to wapbl; they don't infect the rest
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 1 Oct 2009 09:20
Picon
Favicon

Re: softdeps and NetBSD 6.0

On Thu, Oct 01, 2009 at 07:42:49AM +0300, Jukka Marin wrote:
> On Wed, Sep 30, 2009 at 03:47:34PM -0400, Thor Lancelot Simon wrote:
> > On Wed, Sep 30, 2009 at 08:44:38PM +0200, Marc Balmer wrote:
> > >
> > > there is also a middle ground.  the code/filesystem could just be left  
> > > there for people to use it, with all it's "known bugs".
> > 
> > Not really.  As Andy pointed out when he originally proposed removing
> > softdep, the softdep implementation we actually have (as opposed to the
> > one we might perhaps like to have) is entangled in various horrible ways
> > with the FFS, UFS, and VM code.  Having it in there makes maintaining all
> > of that code harder and makes developing new code that interacts with any
> > of those parts of the system harder.  And in more than one case, the
> > softdep code -- when not in use! -- has caused serious bugs in the other
> > components of the system which is touches.
> 
> Does this also apply to FreeBSD softdeps code (I guess so)?

It's the same code, pretty much.  Evidently the FreeBSD developers have
a higher tolerance for pain than we do; on the other hand, they also
don't really have journaling code that's as stable and long tested as
wabpl, which Wasabi shipped in their products for years.

--

-- 
Thor Lancelot Simon	                                   tls <at> rek.tjls.com
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Bellovin | 1 Oct 2009 18:51

Re: Problems after xorg patch to 5.0_STABLE


On Oct 1, 2009, at 5:28 AM, Geert Hendrickx wrote:

> On Mon, Sep 21, 2009 at 06:08:43PM -0400, Steven Bellovin wrote:
>>
>> On Sep 21, 2009, at 5:50 PM, Jukka Salmi wrote:
>>
>>> Rafal Boni --> port-i386 (2009-09-21 17:22:13 -0400):
>>>> On Mon, Sep 21, 2009 at 12:44:35PM -0700, Soren Jacobsen wrote:
>>>>> On Sep 21, 2009, at 12:14 PM, Jukka Salmi wrote:
>>>>>
>>>>>> However, I removed the directory in question and extracted the  
>>>>>> set
>>>>>> again, but the screen still goes black as soon as Xorg is  
>>>>>> running.
>>>>>
>>>>> Sadly, this is expected.  See PR xsrc/41870.  I am very tempted to
>>>>> change our X server back to the old behavior of installing a  
>>>>> default
>>>>> cursor immediately and painting the background to that horrible
>>>>> horrible eye-killing pattern.  Much as I hate that default
>>>>> background,
>>>>> black with no cursor is all kinds of wrong.
>>>>
>>>> Yeah, too many people's reaction to the black screeen w/no cursor  
>>>> has
>>>> been "OMG, it's fuxored" (including mine, even now  
>>>> occasionally).  We
>>>> should go back to the damn grey stipled screen; it's not like it
>>>> can't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Pumford | 2 Oct 2009 21:46
Picon
Picon

Re: softdeps and NetBSD 6.0

Aaron J. Grier wrote:
> On Tue, Sep 29, 2009 at 04:51:22PM -0700, Dieter wrote:
>> >From the discussion softdeps obviously works well for others, it
>>> isn't just me.
>> There is no reason to remove softdeps.  It is optional, those who
>> don't like it don't have to run it.
> 
Why not actaully try WAPBL before writing it off. I've switch several of 
  my systems over from softdep to WAPBL since upgrading to NetBSD 5 and 
in all cases the performance change has been unnoticable. Oh and my 
testing hasn't all been on fast machines with multiple cores big piles 
of memory either the journaled FS is as the same speed as softdep on my 
64MB acorn32 machine as well. The speed of reboot with journaling is 
wonderful. A machine that used to take 20mins if I had to fsck the fs on 
a reboot now comes up in a minute instead.

> just like nobody can force you to a newer version of NetBSD, you can't
> force the maintainers to continue dealing with the softdeps code.
> 
> they don't want to deal with the maintenance.  do you?
> 
As someone who writes software for a living if removing softdep reduces 
the complexity of the FFS code then its a good thing. Especially if the 
journaling code that replaces it is less complex and easier to maintain. 
Simpler code usually has less bugs in it! Less bugs when it comes to 
filesystems is a good thing.

Mike
(Continue reading)

Permalink | Reply | 0 comments |
headers
matthew sporleder | 3 Oct 2009 00:38
Picon

Re: /etc/security produces ci / co "unexpected end of file"

On Wed, Sep 30, 2009 at 2:24 AM, Mike Bowie <mbowie <at> buzmo.com> wrote:
> Howdy folks,
>
> Had this one[1] coming up in my daily security logs for a while on one
> particular server.  I'm not sure if it was the upgrade from 4.99.xx to
> 5.0 or the relocation from /dev/sd0 to /dev/sd1... but it sure hasn't
> done it "forever".
>
> I found this post[2] which references the same error on raq1 devices
> under 1.6.1 and cites fdisk as a factor... sadly the only thing I have
> in common with said post is the error message.  (This is a Dell PE 2970
> with NetBSD 5.0 and fdisk runs just fine.)
>
> Things I know(tm):
> - vi'ing the file in question shows what appears to be a happy and
> complete context; with content beyond line 1429
> - removing the file only gets me a one day reprieve from "le message"
> - running "sh /etc/security" by hand yields the same output
> - /etc/security is identical to that of other systems which are managing
> not to produce the same message
>
> Suggestions graciously welcomed!
>
> Mike.
>
> [1]
> ci: /var/backups/work/device.current,v:1429: unexpected end of file
> ci aborted
> co: /var/backups/work/device.current,v:1429: unexpected end of file
> co aborted
(Continue reading)

Permalink | Reply | 3 comments |
headers
matthew sporleder | 3 Oct 2009 01:39
Picon

Re: /etc/security produces ci / co "unexpected end of file"

On Fri, Oct 2, 2009 at 6:45 PM, Mike Bowie <mbowie <at> buzmo.com> wrote:
> On 10/2/09 3:38 PM, matthew sporleder wrote:
>> On Wed, Sep 30, 2009 at 2:24 AM, Mike Bowie <mbowie <at> buzmo.com> wrote:
>>>
>>> [1]
>>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>>> ci aborted
>>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>>> co aborted
>>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>>> ci aborted
>>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>>> co aborted
>>>
>>> [2] http://mail-index.netbsd.org/port-cobalt/2004/06/29/0001.html
>>>
>>
>> Does it go away with if put:
>> check_devices=NO
>> in /etc/security.conf?
>
> It most certainly does.
>
> That strikes me as suppressing the issue more-so than resolving it...
> and unless I'm mistaken, I then miss out on a good number of file-system
> checks, no?
>

Definitely.  :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Bowie | 3 Oct 2009 02:10
Gravatar

Re: /etc/security produces ci / co "unexpected end of file"

On 10/2/09 4:39 PM, matthew sporleder wrote:
> On Fri, Oct 2, 2009 at 6:45 PM, Mike Bowie <mbowie <at> buzmo.com> wrote:
>> On 10/2/09 3:38 PM, matthew sporleder wrote:
>>> On Wed, Sep 30, 2009 at 2:24 AM, Mike Bowie <mbowie <at> buzmo.com> wrote:
>>>>
>>>> [1]
>>>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>>>> ci aborted
>>>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>>>> co aborted
>>>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>>>> ci aborted
>>>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>>>> co aborted
>>>>
>>>> [2] http://mail-index.netbsd.org/port-cobalt/2004/06/29/0001.html
>>>>
>>>
>>> Does it go away with if put:
>>> check_devices=NO
>>> in /etc/security.conf?
>>
>> It most certainly does.
>>
>> That strikes me as suppressing the issue more-so than resolving it...
>> and unless I'm mistaken, I then miss out on a good number of file-system
>> checks, no?
>>
> 
> Definitely.  :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Bowie | 3 Oct 2009 00:45
Gravatar

Re: /etc/security produces ci / co "unexpected end of file"

On 10/2/09 3:38 PM, matthew sporleder wrote:
> On Wed, Sep 30, 2009 at 2:24 AM, Mike Bowie <mbowie <at> buzmo.com> wrote:
>>
>> [1]
>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>> ci aborted
>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>> co aborted
>> ci: /var/backups/work/device.current,v:1429: unexpected end of file
>> ci aborted
>> co: /var/backups/work/device.current,v:1429: unexpected end of file
>> co aborted
>>
>> [2] http://mail-index.netbsd.org/port-cobalt/2004/06/29/0001.html
>>
> 
> Does it go away with if put:
> check_devices=NO
> in /etc/security.conf?

It most certainly does.

That strikes me as suppressing the issue more-so than resolving it...
and unless I'm mistaken, I then miss out on a good number of file-system
checks, no?

Cheers,

Mike.
(Continue reading)

Permalink | Reply | 2 comments |
headers
6bone | 4 Oct 2009 19:35
Picon

cpu usage

hello,

at my system (NetBSD 5.0_STABLE amd64) are running some perl based 
simulations. The server has 16G ram and 71G swap. When a process is using 
more than 16G ram, the system swaps. But sometimes it looks as if anything 
is blocked. The simulation process is only using 3% CPU time, 96.8% idle, 
0.1% system, 0.1% interrupt. The system load is near 1.10. Iostat shows 
no significant disk i/o. The simulation process has the state biowait.

Can you give me some hints why the process does not get more CPU? Because 
of the low disk i/o it does not seam to be blocked by swap i/o.

Thank you for your efforts.
Uwe
Permalink | Reply | 4 comments |

Gmane