Re: Do you use a value other than AUTO for network_interfaces?
On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > > Up till Sunday in 8-current, and for a long time in general > > > network.subr (part of the rc.d system) has emitted a warning > > > that values of network_interfaces other than AUTO are > > > deprecated. I removed that warning in HEAD Sunday, and there is > > > no a discussion about whether or not it should be put back, and > > > whether or not there is any need for the user to specify the > > > list of network interfaces at all. > > > > > > If you use a value of network_interfaces other than AUTO please > > > speak up so that we can make an intelligent decision about this > > > issue. > > > > > > Thanks, > > > > > > Doug > > > > I'll have to preface this by disclosing that I have not been > > running -current, nor following any changes to the RC system. > > > > In 7.1, if you compile a custom kernel and comment out an > > interface (such that it is compiled as a module), one way to > > ensure that the module is loaded is to explicitly list it in > > network_interfaces. If -current works the same way, then users > > will be required to modify /boot/loader.conf in order to load the > > module. Could there could be possible side-effects to this > > change, since the loading of the module happens at a different > > time? > > Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I > removed that warning in HEAD Sunday, and there is no a discussion > about whether or not it should be put back, and whether or not there > is any need for the user to specify the list of network interfaces > at all. > > If you use a value of network_interfaces other than AUTO please > speak up so that we can make an intelligent decision about this > issue. > > Thanks, > > Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS deadlock ?
On Fri, Nov 09, 2007 at 11:28:27PM +0100, Henri Hennebert wrote: > Richard Arends wrote: > >On Fri, Nov 09, 2007 at 09:35:59PM +0100, Henri Hennebert wrote: > > > >>>This won't start the scrubs at the same time, but after each other. And > >>>the second will only start if the first one not fails (exitcode == 0) > >>> > >>Not at all, the scrub is asynchronious, I'm sure of it > > > >Running 2 commands seperated by && will not run at the same time. Scrub > >could be asynchronious, i don't know, but that has nothing to do with the > >way you are running it. > > > >See: echo "sleep 1" && time sleep 2 && echo "sleep 2" && time sleep 2 > >and: ls -l /notfound && echo yes > > Per the man page, zpool scrub *begin* a scrub witch go on in background, > so two scrubs are running simustaneously on 2 different pools. > > Henri Henri is 100% correct. zpool scrub kicks off a scrub which occurs in the background. I'm not sure I like this behavior that much, but it's not like it's my call :) lothos# zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT tank 1.81T368G 1.45T19% ONLINE - lothos# time sh -c "zpool scrub tank && echo Done\?" Done? 0.000u 0.010s 0:04.35 0.2% 116+152k 14+0io 8pf+0w lothos# zpool status tank pool: tank state: ONLINE scrub: scrub in progress, 3.97% done, 0h40m to go config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 raidz1ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad5 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad7 ONLINE 0 0 0 errors: No known data errors Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
