Re: [HEADSUP] zfs root pool mounting
On Wed, Nov 28, 2012 at 8:35 PM, Andriy Gapon wrote: > > Recently some changes were made to how a root pool is opened for root > filesystem > mounting. Previously the root pool had to be present in zpool.cache. Now it > is > automatically discovered by probing available GEOM providers. > The new scheme is believed to be more flexible. For example, it allows to > prepare > a new root pool at one system, then export it and then boot from it on a new > system without doing any extra/magical steps with zpool.cache. It could also > be > convenient after zpool split and in some other situations. > > The change was introduced via multiple commits, the latest relevant revision > in > head is r243502. The changes are partially MFC-ed, the remaining parts are > scheduled to be MFC-ed soon. > > I have received a report that the change caused a problem with booting on at > least > one system. The problem has been identified as an issue in local environment > and > has been fixed. Please read on to see if you might be affected when you > upgrade, > so that you can avoid any unnecessary surprises. > > You might be affected if you ever had a pool named the same as your current > root > pool. And you still have any disks connected to your system that belonged to > that > pool (in whole or via some partitions). And that pool was never properly > destroyed using zpool destroy, but merely abandoned (its disks > re-purposed/re-partitioned/reused). > > If all of the above are true, then I recommend that you run 'zdb -l ' > for > all suspect disks and their partitions (or just all disks and partitions). If > this command reports at least one valid ZFS label for a disk or a partition > that > do not belong to any current pool, then the problem may affect you. > > The best course is to remove the offending labels. > > If you are affected, please follow up to this email. > > -- > Andriy Gapon > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hello, What is the status of the MFC process to 9-STABLE? I'm on 9-STABLE r244407, should I be able to boot from this ZFS pool without zpool.cache? zpool status pool: zwhitezone state: ONLINE scan: scrub repaired 0 in 0h53m with 0 errors on Sat Dec 15 23:41:09 2012 config: NAME STATE READ WRITE CKSUM zwhitezone ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 label/wzdisk0 ONLINE 0 0 0 label/wzdisk1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 label/wzdisk2 ONLINE 0 0 0 label/wzdisk3 ONLINE 0 0 0 errors: No known data errors ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] zfs root pool mounting
On Thu, Dec 13, 2012 at 2:56 PM, Freddie Cash wrote: ... > You could at least point to the FreeBSD Forums version of that post. :) > > https://forums.freebsd.org/showthread.php?t=31662 Andriy, I figured out my problem. It was really, really stupid PEBKAC (copied a KERNCONF from one system that didn't have the appropriate storage driver for the other system and I didn't put the right entries into src.conf). Sorry for the noise >:(. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski wrote: > W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: > >>> I wrote a small patch for /etc/network.subr to add support for >>> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >>> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >>> aliases can be written like: > > [...] > >> Did anyone try my patch? I thought it would be nice to have the >> ipv6_addrs_IF syntax supported to complement the existing >> ipv4_addrs_IF alias syntax. > > Can I use range syntax in it like in ipv4? I mean something like: > > ipv4_addrs_lagg0="x.x.x.10-30/22" > > That feature would be very nice to have for ipv6. > > -- > best regards, > Lukasz Wasikowski I have to admit I overlooked the possibility to use ranges like that. It doesn't look too hard to add that feature as well for ipv6 aliases using the existing code for ipv4 aliases. I'll prepare a new patch and update the PR when I have it working. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
I finally remembered to remove the .it phk :-). On Wed, 19 Dec 2012, Luigi Rizzo wrote: On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote: ... As I said in my previous email: typedef dur_t int64_t;/* signed for bug catching */ #define DURSEC ((dur_t)1 << 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 1000) #define DURNSEC (DURSEC / 100) (Bikeshed the names at your convenience) Then you can say callout_foo(34 * DURSEC) callout_foo(2400 * DURMSEC) or callout_foo(500 * DURNSEC) only thing, we must be careful with the parentheses For instance, in your macro, DURNSEC evaluates to 0 and so does any multiple of it. We should define them as #define DURNSEC DURSEC / 100 ... so DURNSEC is still 0 and 500*DURNSEC gives 214 I am curious that Bruce did not mention this :) Er, he was careful. DURNSEC gives 4, not 0. This is not very accurate, but probably good enough. Your version without parentheses is not so careful and depends on a magic order of operations and no overflow from this. E.g.: 500*DURNSEC = 500*DURSEC / 10 = 500*((dur_t)1 << 32) / 10 This is very accurate and happens not to overflow. But 5 seconds represented a little strangely in nanoseconds would overflow: 50*DURNSEC = 50*((dur_t)1 << 32) / 10 So would 5 billion times DURSEC, but 5 billion seconds is more unreasobable than 5 billion nanoseconds and the format just can't represent that. (btw the typedef is swapped, should be "typedef int64_t dur_t") Didn't notice this. Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <50d1e0d8.9070...@freebsd.org>, Alexander Motin writes: >It would be late to change this after committing. I would definitely >like it to be done earlier to not redo all the tests, but I think we >could convert callout and eventtimers code to 32.32 format in several >days. The only two questions are: do we really want it (won't there be >any reasons to regret about it) and how do we want it to look? As much as it pains me to raise this point, we would regret it if we did not use 32.32, because Linux already went that way. As much as there is to be said for doing things right, we should also try to avoid pointless incompatibilities which will make it needlessly hard for people to move code, particular device drivers forth and back. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message <20121220005706.i1...@besplex.bde.org>, Bruce Evans writes:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
Except that for absolute timescales, we're running out of the 32 bits
integer part.
Except 32 bit time_t works until 2106 if it is unsigned.
That's sort of not an option.
I think it is. It is just probably not necessary since 32-bit systems
will go away before 2038.
The real problem was that time_t was not defined as a floating
point number.
That would be convenient too, but bad for efficiency on some systems.
Kernels might not be able to use it, and then would have to use an
alternative representation, which they should have done all along.
[1] A good addition to C would be a general multi-word integer type
where you could ask for any int%d_t or uint%d_t you cared for, and
have the compiler DTRT. In difference from using a multiword-library,
this would still give these types their natural integer behaviour.
That would be convenient, but bad for efficiency if it were actually
used much.
You can say that about anything but CPU-native operations, and I doubt
it would be as inefficient as struct bintime, which does not have access
to the carry bit.
Yes, I would say that about non-native. It goes against the spirit of C.
OTOH, compilers are getting closer to giving full access to the carry
bit. I just checked what clang does in a home-made 128-bit add function:
% static void __noinline
% uadd(struct u *xup, struct u *yup)
% {
% unsigned long long t;
%
% t = xup->w[0] + yup->w[0];
% if (t < xup->w[0])
% xup->w[1]++;
% xup->w[0] = t;
% xup->w[1] += yup->w[1];
% }
%
% .align 16, 0x90
% .type uadd,@function
% uadd: # @uadd
% .cfi_startproc
% # BB#0: # %entry
% movq(%rdi), %rcx
% movq8(%rdi), %rax
% addq(%rsi), %rcx
gcc generates an additional cmpq instruction here.
% jae .LBB2_2
clang uses the carry bit set by the first addition to avoid the comparison,
but still branches.
% # BB#1: # %if.then
% incq%rax
% movq%rax, 8(%rdi)
This adds 1 explicitly instead of using adcq, but this is the slow path.
% .LBB2_2:# %if.end
% movq%rcx, (%rdi)
% addq8(%rsi), %rax
This is as efficient as possible except for the extra branch, and the
branch is almost perfectly predictable.
% movq%rax, 8(%rdi)
% ret
% .Ltmp22:
% .size uadd, .Ltmp22-uadd
% .cfi_endproc
Bruce
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, 19 Dec 2012, Davide Italiano wrote: On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: I would have tried a 32 bit format with a variable named 'ticks'. Something like: - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use this. The tick period would be constant but for virtual ticks and not too small. hz = 1000 now makes the period too small, and not a power of 2. So make the period 1/128 second. This gives a 1.24.7 binary format. 2**24 seconds is 194 days. - ticks < 0. The 31 value bits are now a cookie (descriptor) referring to a bintime or whatever. This case should rarely be used. I don't like it that a tickless kernel, which is needed mainly for power saving, has expanded into complications to support short timeouts which should rarely be used. Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. In the old API, it is an error to pass ticks < 0, so only broken old callers are affected. Of course, if there are any then it would be hard to detect their garbage cookies. Anywy, it's too later to change to this, and maybe also to a 32.32 format. [32.32 format] This would make a better general format than timevals, timespecs and of course bintimes :-). It is a bit wasteful for timeouts since its extremes are rarely used. Malicious and broken callers can still cause overflow at 68 years, so you have to check for it and handle it. The limit of 194 days is just as good for timeouts. I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. It's very easy for applications to cause kernel overflow using valid syscall args like tv_sec = TIME_T_MAX for a relative time in nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow for all current times except for the first second after the Epoch. There is no difference between the overflow for 32-bit and 64-bit time_t's for this. This is now mostly handled so that the behaviour is harmless although wrong. E.g., the timeout might become negative, and then since it is not a cookie it is silently replaced by a timeout of 1 tick. In nanosleep(), IIRC there are further overflows that result in returning early instead of retrying the 1-tick timeouts endlessly. Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] permit fib to be set on interface
schrieb Alexander V. Chernikov am 08.05.2011 15:09 (localtime): > At the moment the only possible way to set packet fib from userland is > ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows > with every fib. > Additionally, there is no way to set packet fib before netgraph > processing: L2 ipfw hook is called after ng_ether_input() > > Those reasons (not mentioning kern/134931) makes it hard to use multiple > routing tables. > > The following path: > * adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib > * adds IFF_CUSTOMFIB interface flags > * adds ifi_fib field to if_data structure > * adds 'fib' keyword for ifconfig(8) > > Example: > 16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15 > vlan 2 vlandev em0 > 16:42 [0] zfscurr0# ifconfig vlan2 > vlan2: flags=808843 > metric 0 mtu 1500 fib 15 > options=3 > ether 08:00:27:c5:29:d4 > inet 10.11.12.13 netmask 0xfffc broadcast 10.11.12.15 > inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 2 parent interface: em0 > > > Interface fib is applied on inbound only (for forwarded packets fib > decision should be done on inbound, for locally-originated packets there > is setfib(1)) Could you please help me understanding the design? If I have a multihomed machine, with fib0 defaultrouter via nic0 and fib1 defaultrouter via nic1, and nic1 has fib1 assigned. What should happen if I connect to any service, by default assigned to fib0, but passing nic1? The incoming packet will be tagged with "FIB1", right? But does that affect the answer-path of services not assigned to fib1? If not, why would I want incoming packates tagged? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 7:37 AM, Poul-Henning Kamp wrote: > > In message <20121219150809.ga98...@onelab2.iet.unipi.it>, Luigi Rizzo > writes: > > >> typedef dur_t int64_t;/* signed for bug catching */ > >> #define DURSEC ((dur_t)1 << 32) > >> #define DURMIN (DURSEC * 60) > >> #define DURMSEC (DURSEC / 1000) > >> #define DURUSEC (DURSEC / 1000) > >> #define DURNSEC (DURSEC / 100) > > >only thing, we must be careful with the parentheses > > Actually, it's more impportant to be careful with zeros, if you > adjust the above to the correct number of zeros, DURNSEC is 4, > which is within seven percent of the correct value. > counting digits is impossible for people over 45. But i have a solution for that #define DURNSEC (DURSEC / 1003006009) which is within 0.5% of the desired value. (and of course (1000*1000*1000) might do the job too) cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
dropping phk _AT_ onelab2 _DOT_ something from CC as long as it doesn't seem a valid mail address and I'm annoyed mails bounce back. On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > > >>> I would have tried a 32 bit format with a variable named 'ticks'. >>> Something like: >>> - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use >>> this. The tick period would be constant but for virtual ticks and >>> not too small. hz = 1000 now makes the period too small, and not a >>> power of 2. So make the period 1/128 second. This gives a 1.24.7 >>> binary format. 2**24 seconds is 194 days. >>> - ticks < 0. The 31 value bits are now a cookie (descriptor) referring >>> to a bintime or whatever. This case should rarely be used. I don't >>> like it that a tickless kernel, which is needed mainly for power >>> saving, has expanded into complications to support short timeouts >>> which should rarely be used. >> >> >> Bruce, I don't really agree with this. >> The data addressed by cookie should be still stored somewhere, and KBI >> will result broken. This, indeed, is not real problem as long as >> current calloutng code heavily breaks KBI, but if that was your point, >> I don't see how your proposed change could help. > > > In the old API, it is an error to pass ticks < 0, so only broken old > callers are affected. Of course, if there are any then it would be > hard to detect their garbage cookies. > > Anywy, it's too later to change to this, and maybe also to a 32.32 > format. > > [32.32 format] It's not too late. What I'd like to do, right now people got interested in the problem is agreeing on the interface used. Following this thread, as I've already discussed to mav@, we would like to decide what of the two is better: - specify precision as additional argument (as we're doing right now) - use 'flags' argument If we allow time argument to be relative and not absolute, as suggested by luigi@, we can easily use relative precision where we had to use ffl() before. >>> >>> This would make a better general format than timevals, timespecs and >>> of course bintimes :-). It is a bit wasteful for timeouts since >>> its extremes are rarely used. Malicious and broken callers can >>> still cause overflow at 68 years, so you have to check for it and >>> handle it. The limit of 194 days is just as good for timeouts. >> >> >> I think the phk's proposal is better. About your overflow objection, >> I think is really unlikely to happen, but better safe than sorry. > > > It's very easy for applications to cause kernel overflow using valid > syscall args like tv_sec = TIME_T_MAX for a relative time in > nanosleep(). Adding TIME_T_MAX to the current time in seconds overflow > for all current times except for the first second after the Epoch. > There is no difference between the overflow for 32-bit and 64-bit > time_t's for this. This is now mostly handled so that the behaviour is > harmless although wrong. E.g., the timeout might become negative, > and then since it is not a cookie it is silently replaced by a timeout > of 1 tick. In nanosleep(), IIRC there are further overflows that result > in returning early instead of retrying the 1-tick timeouts endlessly. > > Bruce Thanks, Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On 19.12.2012 16:20, Bruce Evans wrote:
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans
wrote:
I would have tried a 32 bit format with a variable named 'ticks'.
Something like:
- ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use
this. The tick period would be constant but for virtual ticks and
not too small. hz = 1000 now makes the period too small, and not a
power of 2. So make the period 1/128 second. This gives a 1.24.7
binary format. 2**24 seconds is 194 days.
- ticks < 0. The 31 value bits are now a cookie (descriptor) referring
to a bintime or whatever. This case should rarely be used. I don't
like it that a tickless kernel, which is needed mainly for power
saving, has expanded into complications to support short timeouts
which should rarely be used.
Bruce, I don't really agree with this.
The data addressed by cookie should be still stored somewhere, and KBI
will result broken. This, indeed, is not real problem as long as
current calloutng code heavily breaks KBI, but if that was your point,
I don't see how your proposed change could help.
In the old API, it is an error to pass ticks < 0, so only broken old
callers are affected. Of course, if there are any then it would be
hard to detect their garbage cookies.
Anywy, it's too later to change to this, and maybe also to a 32.32
format.
It would be late to change this after committing. I would definitely
like it to be done earlier to not redo all the tests, but I think we
could convert callout and eventtimers code to 32.32 format in several
days. The only two questions are: do we really want it (won't there be
any reasons to regret about it) and how do we want it to look?
For the first question my personal showstopper since eventtimers
creation always was the wish to keep consistency. But benefits of 32.32
format are clear, and if there are more votes for it, let's consider. If
now it will be decided that full range will never be useful for callout
subsystem, then it is obviously not needed for eventtimers also.
About the second question, what do you think about such prototypes:
typedef int64_t sbintime_t
static __inline sbintime_t
bintime_shrink(struct bintime *bt)
{}
static __inline struct bintime
bintime_expand(sbintime_t sbt)
{}
...
int
callout_reset_bt(struct callout *, sbintime_t sbt, sbintime_t pr,
void (*fn)(void *), void *arg, int flags);
, where pr used only for absolute precision, and flags includes: direct
execution, absolute/relative time in argument, relative precision in
case of relative sbt, flag for aligning to hardclock() to emulate legacy
behavior, and potentially flags for reaction on suspend/resume.
Another option is to move absolute precision also to flags, using log2()
representation, as we tried and as was proposed before. With possibility
to use precise relative time there will be few cases requiring absolute
value of precision, that should depend on period. Then there will be no
extra arguments in the most usual cases.
Wrapper for existing API compatibility will look just like this:
#define callout_reset(c, ticks, fn, arg)\
callout_reset_bt(c, ticks2sbintime(ticks), -1, \
(fn), (arg), C_HARDCLOCK)
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <20121219150809.ga98...@onelab2.iet.unipi.it>, Luigi Rizzo writes: >> typedef dur_t int64_t;/* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 1000) >> #define DURNSEC (DURSEC / 100) >only thing, we must be careful with the parentheses Actually, it's more impportant to be careful with zeros, if you adjust the above to the correct number of zeros, DURNSEC is 4, which is within seven percent of the correct value. >(btw the typedef is swapped, should be "typedef int64_t dur_t") Yes, I'm trying to find out of people even listen to me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote: > > In message > > , Davide Italiano writes: > > >Right now -- the precision is specified in 'bintime', which is a binary > >number. > >It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in > >the specific platform. > > And that is way overkill for specifying a callout, at best your clock > has short term stabilities approaching 1e-8, but likely as bad as 1e-6. > > (The reason why bintime is important for timekeeping is that we > accumulate timeintervals approx 1e3 times a second, so the rounding > error has to be much smaller than the short term stability in order > to not dominate) > > >I do not really think it worth to create another structure for > >handling time (e.g. struct bintime32), as it will lead to code > > No, that was exactly my point: It should be an integer so that > comparisons and arithmetic is trivial. A 32.32 format fits > nicely into a int64_t which is readily available in the language. > > As I said in my previous email: > > > typedef dur_t int64_t;/* signed for bug catching */ > #define DURSEC ((dur_t)1 << 32) > #define DURMIN (DURSEC * 60) > #define DURMSEC (DURSEC / 1000) > #define DURUSEC (DURSEC / 1000) > #define DURNSEC (DURSEC / 100) > > (Bikeshed the names at your convenience) > > Then you can say > > callout_foo(34 * DURSEC) > callout_foo(2400 * DURMSEC) > or > callout_foo(500 * DURNSEC) only thing, we must be careful with the parentheses For instance, in your macro, DURNSEC evaluates to 0 and so does any multiple of it. We should define them as #define DURNSEC DURSEC / 100 ... so DURNSEC is still 0 and 500*DURNSEC gives 214 I am curious that Bruce did not mention this :) (btw the typedef is swapped, should be "typedef int64_t dur_t") cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nfsd won't start on post r243965 kernels without INET6
Oops, I did my usual brain fart again and forgot to attach the
patch. Here it is, rick
- Original Message -
> Just fyi, r243965 introduced a minor pola violation where the
> nfsd daemon won't start for kernels built without "options INET6".
>
> The attached patch, which I will commit to head later to-day, fixes
> the problem. (Or you can add "options INET6" to your kernel config.)
>
> Reported and tested by avg@.
>
> rick
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
--- usr.sbin/nfsd/nfsd.c.sav 2012-12-18 08:32:14.0 -0500
+++ usr.sbin/nfsd/nfsd.c 2012-12-18 08:33:19.0 -0500
@@ -264,7 +264,7 @@ main(int argc, char **argv)
ip6flag = 1;
s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
if (s == -1) {
- if (errno != EPROTONOSUPPORT)
+ if (errno != EPROTONOSUPPORT && errno != EAFNOSUPPORT)
err(1, "socket");
ip6flag = 0;
} else if (getnetconfigent("udp6") == NULL ||
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nfsd won't start on post r243965 kernels without INET6
Just fyi, r243965 introduced a minor pola violation where the nfsd daemon won't start for kernels built without "options INET6". The attached patch, which I will commit to head later to-day, fixes the problem. (Or you can add "options INET6" to your kernel config.) Reported and tested by avg@. rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: In message <20121219221518.e1...@besplex.bde.org>, Bruce Evans writes: With this format you can specify callouts 68 years into the future with quarter nanosecond resolution, and you can trivially and efficiently compare dur_t's with if (d1 < d2) This would make a better general format than timevals, timespecs and of course bintimes :-). Except that for absolute timescales, we're running out of the 32 bits integer part. Except 32 bit time_t works until 2106 if it is unsigned. Bintimes is a necessary superset of the 32.32 which tries to work around the necessary but missing int96_t or int128_t[1]. [1] A good addition to C would be a general multi-word integer type where you could ask for any int%d_t or uint%d_t you cared for, and have the compiler DTRT. In difference from using a multiword-library, this would still give these types their natural integer behaviour. That would be convenient, but bad for efficiency if it were actually used much. Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <20121220005706.i1...@besplex.bde.org>, Bruce Evans writes: >On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: >> Except that for absolute timescales, we're running out of the 32 bits >> integer part. > >Except 32 bit time_t works until 2106 if it is unsigned. That's sort of not an option. The real problem was that time_t was not defined as a floating point number. >> [1] A good addition to C would be a general multi-word integer type >> where you could ask for any int%d_t or uint%d_t you cared for, and >> have the compiler DTRT. In difference from using a multiword-library, >> this would still give these types their natural integer behaviour. > >That would be convenient, but bad for efficiency if it were actually >used much. You can say that about anything but CPU-native operations, and I doubt it would be as inefficient as struct bintime, which does not have access to the carry bit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: >> I wrote a small patch for /etc/network.subr to add support for >> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >> aliases can be written like: [...] > Did anyone try my patch? I thought it would be nice to have the > ipv6_addrs_IF syntax supported to complement the existing > ipv4_addrs_IF alias syntax. Can I use range syntax in it like in ipv4? I mean something like: ipv4_addrs_lagg0="x.x.x.10-30/22" That feature would be very nice to have for ipv6. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >> >> In message >> >> , Davide Italiano writes: >> >>> Right now -- the precision is specified in 'bintime', which is a binary >>> number. >>> It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >>> the specific platform. >> >> >> And that is way overkill for specifying a callout, at best your clock >> has short term stabilities approaching 1e-8, but likely as bad as 1e-6. > > > So you always agreed with me that bintimes are unsuitable for almost > everything, and especially unsuitable for timeouts? :-) > > >> (The reason why bintime is important for timekeeping is that we >> accumulate timeintervals approx 1e3 times a second, so the rounding >> error has to be much smaller than the short term stability in order >> to not dominate) > > > bintimes are not unsuitable for timekeeping, but they a painful to use > for other APIs. You have to either put bintimes in layers in the other > APIs, or convert them to a more suitable format, and there is a problem > placing the conversion at points where it is efficient. This thread > seems to be mostly about putting the conversion in wrong places. My > original objection was about using bintimes for almost everything at > the implementation level. > > >>> I do not really think it worth to create another structure for >>> handling time (e.g. struct bintime32), as it will lead to code >> >> >> No, that was exactly my point: It should be an integer so that >> comparisons and arithmetic is trivial. A 32.32 format fits >> nicely into a int64_t which is readily available in the language. > > > I would have tried a 32 bit format with a variable named 'ticks'. > Something like: > - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use > this. The tick period would be constant but for virtual ticks and > not too small. hz = 1000 now makes the period too small, and not a > power of 2. So make the period 1/128 second. This gives a 1.24.7 > binary format. 2**24 seconds is 194 days. > - ticks < 0. The 31 value bits are now a cookie (descriptor) referring > to a bintime or whatever. This case should rarely be used. I don't > like it that a tickless kernel, which is needed mainly for power > saving, has expanded into complications to support short timeouts > which should rarely be used. > Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. > >> As I said in my previous email: >> >>typedef dur_t int64_t;/* signed for bug catching */ >>#define DURSEC ((dur_t)1 << 32) >>#define DURMIN (DURSEC * 60) >>#define DURMSEC (DURSEC / 1000) >>#define DURUSEC (DURSEC / 1000) >>#define DURNSEC (DURSEC / 100) >> >> (Bikeshed the names at your convenience) >> >> Then you can say >> >> callout_foo(34 * DURSEC) >> callout_foo(2400 * DURMSEC) >> or >> callout_foo(500 * DURNSEC) > > > Constructing the cookie for my special case would not be so easy. > > >> With this format you can specify callouts 68 years into the future >> with quarter nanosecond resolution, and you can trivially and >> efficiently compare dur_t's with >> if (d1 < d2) > > > This would make a better general format than timevals, timespecs and > of course bintimes :-). It is a bit wasteful for timeouts since > its extremes are rarely used. Malicious and broken callers can > still cause overflow at 68 years, so you have to check for it and > handle it. The limit of 194 days is just as good for timeouts. > > Bruce I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. Thanks Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <20121219221518.e1...@besplex.bde.org>, Bruce Evans writes: >> With this format you can specify callouts 68 years into the future >> with quarter nanosecond resolution, and you can trivially and >> efficiently compare dur_t's with >> if (d1 < d2) > >This would make a better general format than timevals, timespecs and >of course bintimes :-). Except that for absolute timescales, we're running out of the 32 bits integer part. Bintimes is a necessary superset of the 32.32 which tries to work around the necessary but missing int96_t or int128_t[1]. Poul-Henning [1] A good addition to C would be a general multi-word integer type where you could ask for any int%d_t or uint%d_t you cared for, and have the compiler DTRT. In difference from using a multiword-library, this would still give these types their natural integer behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: In message , Davide Italiano writes: Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. And that is way overkill for specifying a callout, at best your clock has short term stabilities approaching 1e-8, but likely as bad as 1e-6. So you always agreed with me that bintimes are unsuitable for almost everything, and especially unsuitable for timeouts? :-) (The reason why bintime is important for timekeeping is that we accumulate timeintervals approx 1e3 times a second, so the rounding error has to be much smaller than the short term stability in order to not dominate) bintimes are not unsuitable for timekeeping, but they a painful to use for other APIs. You have to either put bintimes in layers in the other APIs, or convert them to a more suitable format, and there is a problem placing the conversion at points where it is efficient. This thread seems to be mostly about putting the conversion in wrong places. My original objection was about using bintimes for almost everything at the implementation level. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code No, that was exactly my point: It should be an integer so that comparisons and arithmetic is trivial. A 32.32 format fits nicely into a int64_t which is readily available in the language. I would have tried a 32 bit format with a variable named 'ticks'. Something like: - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use this. The tick period would be constant but for virtual ticks and not too small. hz = 1000 now makes the period too small, and not a power of 2. So make the period 1/128 second. This gives a 1.24.7 binary format. 2**24 seconds is 194 days. - ticks < 0. The 31 value bits are now a cookie (descriptor) referring to a bintime or whatever. This case should rarely be used. I don't like it that a tickless kernel, which is needed mainly for power saving, has expanded into complications to support short timeouts which should rarely be used. As I said in my previous email: typedef dur_t int64_t;/* signed for bug catching */ #define DURSEC ((dur_t)1 << 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 1000) #define DURNSEC (DURSEC / 100) (Bikeshed the names at your convenience) Then you can say callout_foo(34 * DURSEC) callout_foo(2400 * DURMSEC) or callout_foo(500 * DURNSEC) Constructing the cookie for my special case would not be so easy. With this format you can specify callouts 68 years into the future with quarter nanosecond resolution, and you can trivially and efficiently compare dur_t's with if (d1 < d2) This would make a better general format than timevals, timespecs and of course bintimes :-). It is a bit wasteful for timeouts since its extremes are rarely used. Malicious and broken callers can still cause overflow at 68 years, so you have to check for it and handle it. The limit of 194 days is just as good for timeouts. Bruce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <50d192e8.3020...@freebsd.org>, Alexander Motin writes:
>Linux uses 32.32 format in their eventtimers code.
(And that is no accident, I know who they got the number from :-)
>But if at some point we want to be able to
>handle absolute wall time, [...]
Then you have other problems, including but not limited to clock
being stepped, leap-seconds, suspend/resume and frequency stability.
If you want to support callouts of the type ("At 14:00 UTC tomorrow")
(disregarding the time-zone issue), you need to catch all significant
changes to our UTC estimate and recalibrate your callout based on
that.
It is not obvious that we have applications for such an API that
warrant the complexity.
Either way, such a facility should be layered on top of the callout
facility, which should always run in "elapsed time"[1] with no attention
paid to what NTPD might do to the UTC estimate.
So summary: 32.32 is the right format.
Poul-Henning
[1] Notice that "elapsed time" needs a firm definition with respect
to suspend/resume, and that this decision has big implications
for the API use and code duplication.
I think it prudent to specify a flag to callouts, to tell what
should happen on suspend/resume, something like:
SR_CANCEL /* Cancel the callout on S/R */
/* no flag* /* Toll this callout only when system is running */
SR_IGNORE /* Toll suspended time from callout */
If you get this right, callouts from device drivers will just "DTRT",
if you get it wrong, all device drivers will need boilerplate code
to handle S/R
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message , Davide Italiano writes: >Right now -- the precision is specified in 'bintime', which is a binary number. >It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >the specific platform. And that is way overkill for specifying a callout, at best your clock has short term stabilities approaching 1e-8, but likely as bad as 1e-6. (The reason why bintime is important for timekeeping is that we accumulate timeintervals approx 1e3 times a second, so the rounding error has to be much smaller than the short term stability in order to not dominate) >I do not really think it worth to create another structure for >handling time (e.g. struct bintime32), as it will lead to code No, that was exactly my point: It should be an integer so that comparisons and arithmetic is trivial. A 32.32 format fits nicely into a int64_t which is readily available in the language. As I said in my previous email: typedef dur_t int64_t;/* signed for bug catching */ #define DURSEC ((dur_t)1 << 32) #define DURMIN (DURSEC * 60) #define DURMSEC (DURSEC / 1000) #define DURUSEC (DURSEC / 1000) #define DURNSEC (DURSEC / 100) (Bikeshed the names at your convenience) Then you can say callout_foo(34 * DURSEC) callout_foo(2400 * DURMSEC) or callout_foo(500 * DURNSEC) With this format you can specify callouts 68 years into the future with quarter nanosecond resolution, and you can trivially and efficiently compare dur_t's with if (d1 < d2) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD daily snapshot build in allbsd.org temporarily down
Hiroki Sato wrote in <20121207.101917.103513550140980591@allbsd.org>: hr> Hi all, hr> hr> I received many emails asking why hr> https://pub.allbsd.org/FreeBSD-snapshots/ is stopped working and when hr> it will recover, so I just wanted to let you know that FreeBSD daily hr> snapshot build in allbsd.org is temporarily down. The reason why it hr> is down is some local network issue and CVS->SVN migration of the hr> build system. The latter was solved already. However, the former hr> was unexpected and needed some time than I thought originally. The service has almost recovered. Snapshots for i386, amd64, and pc98/i386 are being rebuilt now, and then ia64, sparc64, and powerpc will also be connected to the build queue soon. For stable/9 and later, Subversion repository is used and the build results are sorted by the revision numbers on each day. For 8.X it still uses CVS via the make release target but will be switched to use Subversion shortly. Note that some local network performance issue still remains. It seems due to traffic congestion around the border router which I do not have control of. The transfer rate can become less than 100KB/s especially in 12:00-18:00 in JST. I will planning to add a custom build functionality by using the source trees under projects/ or user/ branch to this service. -- Hiroki pgpl3sZPjPZ17.pgp Description: PGP signature
Re: API explosion (Re: [RFC/RFT] calloutng)
On 19.12.2012 12:03, Davide Italiano wrote: On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp wrote: In message <1355873265.1198.183.ca...@revolution.hippie.lan>, Ian Lepore writes : On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It is a bad idea, and it is physically pointless, given the stabilities of the timebases available for computers in general. Please just take my word as a time-nut, and use a 32.32 binary format in seconds (see previous email) and be done with it. Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code duplication for all the basic conversion/math operation. On the other hand, 32.32 may not be enough in the long future. What do you think about that? Linux uses 32.32 format in their eventtimers code. Respecting that now we have no any timer hardware with frequency about 4GHz, that precision is probably sufficient. But if at some point we want to be able to handle absolute wall time, then 32bit integer part may be not enough. Then we return to the question: "how many different data types do we want to see in one subsystem"? Sure, using single 64bit value would be much easier then struct bintime from many perspectives, but what's about the edge cases? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp wrote: > > In message <1355873265.1198.183.ca...@revolution.hippie.lan>, Ian Lepore > writes > : >>On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: > >>I'm not so sure about the 2^k precision. You speak of seconds, but I >>would be worrying about sub-second precision in my work. > > It is a bad idea, and it is physically pointless, given the stabilities > of the timebases available for computers in general. > > Please just take my word as a time-nut, and use a 32.32 binary format > in seconds (see previous email) and be done with it. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. Right now -- the precision is specified in 'bintime', which is a binary number. It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in the specific platform. I do not really think it worth to create another structure for handling time (e.g. struct bintime32), as it will lead to code duplication for all the basic conversion/math operation. On the other hand, 32.32 may not be enough in the long future. What do you think about that? Thanks, Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
In message <1355873265.1198.183.ca...@revolution.hippie.lan>, Ian Lepore writes : >On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >I'm not so sure about the 2^k precision. You speak of seconds, but I >would be worrying about sub-second precision in my work. It is a bad idea, and it is physically pointless, given the stabilities of the timebases available for computers in general. Please just take my word as a time-nut, and use a 32.32 binary format in seconds (see previous email) and be done with it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: API explosion (Re: [RFC/RFT] calloutng)
On 19.12.2012 01:37, Ian Lepore wrote: On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. ... I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if i said k is signed so negative values represent fractions of a second. 2^-128 is pretty short :) Ahh, I missed that. Good enough then! Hmmm, if that ideas survives further review, then could precision be encoded in 8 bits of the flags, eliminating another parm? Those who tracked the branch could see that actually was our first approach to handle precision. Unfortunately, it appeared not very convenient when you need to convert relative precision in percents or fraction of interval to the absolute precision in power of 2. We were worried that using some ffsll() for it can be inconvenient or expensive. But since we are now talking about passing relative bintime as an argument, that may be more viable option. I'll make another try. Thanks for the input. Pity it didn't happen couple of months ago. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
