Re: solved ? [Re: need help with kern/35704 (UBC-related)]
On Tue, Feb 02, 2010 at 10:53:58PM +0100, Manuel Bouyer wrote: > I found the cause of for this one: > [...] > > To fix this I propose to have ffs_trucate() (and derivatives) always set > v_writesize, even if the real size of the inode didn't change. > The attached patch completely fixes the test case from kern/35704 > for me. I suspect it could also fix other related file system full > related PRs. > > Anyone has commnts about this ? I'd still like to hear some from > UVM/UBC experts ... Should this be pulled up to -4? It applies cleanly and I can probably test it (some...) -- David A. Holland dholl...@netbsd.org
Re: amd64 + Xen + arcmsr = crash
On Fri, Feb 26, 2010 at 12:18:01PM +0100, Manuel Bouyer wrote: > On Wed, Feb 24, 2010 at 03:23:30PM +0200, Jukka Marin wrote: > > The amd64 port itself works just fine with Areca, too - it's only the > > amd64+xen+areca combination that is causing problems. And with the i386 > > port, xen and Areca work ok. > > > > I'm using Xen 3.3.1 and a netbsd-5 amd64 dom0 kernel built a week ago. > > the is the i386 port you're using PAE or non-PAE (if it's a > Xen 3.3.1 i386, it's most probably PAE) ? I'm not using i386 on the test machine at all. I use either amd64 (GENERIC kernel) or Xen dom0 amd64: NetBSD jadis 5.0_STABLE NetBSD 5.0_STABLE (GENERIC) #0: Mon Feb 15 17:10:57 EET 2010 r...@jadis:/tmp/nb5/obj/sys/arch/amd64/compile/GENERIC amd64 or NetBSD jadis 5.0_STABLE NetBSD 5.0_STABLE (XEN3_DOM0) #0: Mon Feb 15 17:11:08 EET 2010 r...@jadis:/tmp/nb5/obj/sys/arch/amd64/compile/XEN3_DOM0 amd64 -jm
Re: raidframe, autoconfigure, and spares
In article <11102.1267360...@jade.coe.psu.ac.th>, Robert Elz wrote: >Is there any way to (more simply than running commands >after each boot) have a raidframe (raid1 or raid5) set >be bother uatoconfiguring, and have hot spares? > >I can add the spare easily ... raidctl -a /dev/wdxP raidN >(and the partition used is of type RAID in the disklabel of wdx) > >but after a reboot, it is gone again. I assume this is >related to ... > > -a component dev > Add component as a hot spare for the device dev. Component > labels (which identify the location of a given component within a > particular RAID set) are automatically added to the hot spare > after it has been used and are not required for component before > it is used. > >which suggests that nothing happens to the spare when it is added. >That makes it kind of difficult for the raid autoconfigure code >to find it, I would guess. > >Is there some way to get a component label added, marking the spare >as belonging to this raidset, and being a spare? No, there isn't. I asked Greg a couple of years ago. It would be a nice thing to add. christos
Exposing internal sysmon_envsys(8) structures to userland
It has always bothered me that src/sys/sys/envsys.h exposes several internal data structures to userland. It seems to me that the only items from this header file that should really be exported are * the definitions for the various IOCTLs * the definitions for the sensor units * the definitions for the sensor states/values * the definitions for the legacy "struct envsys_tre_data" The "struct sysmon_envsys_lim" and "struct envsys_data" should be moved into src/sys/dev/sysmon/sysmon_envsysvar.h along with the related internal flags and properties definitions. Comments? - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
raidframe, autoconfigure, and spares
Is there any way to (more simply than running commands after each boot) have a raidframe (raid1 or raid5) set be bother uatoconfiguring, and have hot spares? I can add the spare easily ... raidctl -a /dev/wdxP raidN (and the partition used is of type RAID in the disklabel of wdx) but after a reboot, it is gone again. I assume this is related to ... -a component dev Add component as a hot spare for the device dev. Component labels (which identify the location of a given component within a particular RAID set) are automatically added to the hot spare after it has been used and are not required for component before it is used. which suggests that nothing happens to the spare when it is added. That makes it kind of difficult for the raid autoconfigure code to find it, I would guess. Is there some way to get a component label added, marking the spare as belonging to this raidset, and being a spare? kre
