RE: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 26.02.2011 15:26, Marin Atanasov Nikolov wrote: After a reboot I get this right before the FreeBSD bootloader starts: gptboot: invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? No. Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. I also get this answer: Maybe the boot process was made to be more standard-compliant :) That is not the way it should work, well we make the boot process more standard compliant, bad luck for those who thougt it worked. I also convert back to normal partitioning and gmirror. Regards Johan ___ 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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 28.02.2011 11:54, Johan Hendriks wrote: I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. So, my guess is when all is properly configured all should work as expected. You should get some non-fatal messages, but not a kernel panic. I'll try to get some free machines to test, but it will be no so fast. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
2011/2/28 Andrey V. Elsukov bu7c...@yandex.ru: On 28.02.2011 11:54, Johan Hendriks wrote: I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk And that's where I got kernel panic. gpart'ing the disk and the mirroring the partitions works just as fine, but not when you mirror the whole disk. Regards, Marin So, my guess is when all is properly configured all should work as expected. You should get some non-fatal messages, but not a kernel panic. I'll try to get some free machines to test, but it will be no so fast. -- WBR, Andrey V. Elsukov -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ 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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On Mon, Feb 28, 2011 at 06:23:10PM +0200, Marin Atanasov Nikolov wrote: 2011/2/28 Andrey V. Elsukov bu7c...@yandex.ru: On 28.02.2011 11:54, Johan Hendriks wrote: I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk And that's where I got kernel panic. gpart'ing the disk and the mirroring the partitions works just as fine, but not when you mirror the whole disk. I think this only ever worked accidentally at best. It would work fine with the older fdisk-style disk partition because that doesn't touch the end of the disk, but any time you tell two different programs that they both have absolute control over the last sector on the disk and can write critical data there - which is what this is doing - that's begging for trouble. Something cleaner than a kernel panic would be *nice* however... And your point about warnings in the documentation is a good one. -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ 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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On Mon, Feb 28, 2011 at 8:23 AM, Marin Atanasov Nikolov dna...@gmail.com wrote: 2011/2/28 Andrey V. Elsukov bu7c...@yandex.ru: On 28.02.2011 11:54, Johan Hendriks wrote: I opened a discussion on this before the release. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061184.ht ml On my 8.1 system, i get this message about the corrupt headers, but it booted on the 8.2 system it panics... I think a lot of people are going to get bit by this. As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk The above process is operator error, as both your gpart and gmirror commands are working on the same GEOM (ad0). You need to stack / layer your GEOMs (ie, do one operation on the disk, the other operations on the sub-parts). Either: 1) gmirror the disk (ad0), and then gpart the mirror device (/dev/mirror/whatever), or 2) gpart the disk (ad0), and the mirror the partititons (/dev/gpt/whatever) The process you list above is the same as partitioning a disk (ad0), and then newfs-ing the disk (ad0), and wondering where your partitions went. :) (I believe option 1 above is what's causing issues in this thread.) -- Freddie Cash fjwc...@gmail.com ___ 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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 28.02.2011 19:23, Marin Atanasov Nikolov wrote: I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk And that's where I got kernel panic. gpart'ing the disk and the mirroring the partitions works just as fine, but not when you mirror the whole disk. What do you mean when you said 'gpart the first disk'? gpart(8) is the default tool to make any type of partitions and partition tables. The list of exact commands and at least a photo of screen with the panic message will be good. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Change in behavior to stat(1)
I had a little script that would remove broken links. I used to do it
like this:
if ! stat -L $link /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records) stat
was changed so that stat -L would use lstat(2) if the link is broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
Stephen
___
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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
@Johan Hendriks As far as i know there is no warning anywhere that you can not use gpart and gmirror the whole disk. Well, there is actually :) From gpart(8): NOTE: The GEOM class PART can detect the same partition table on differ- ent GEOM providers and some of them will marked as corrupt. Be careful when choising a provider for recovering. If you did incorrect choise you can destroy metadata of another GEOM class, e.g. GEOM MIRROR or GEOM LABEL. @Cliffton Royston I think this only ever worked accidentally at best. It would work fine with the older fdisk-style disk partition because that doesn't touch the end of the disk, but any time you tell two different programs that they both have absolute control over the last sector on the disk and can write critical data there - which is what this is doing - that's begging for trouble. I think I've tried this with bsdlabel(8) and gmirror(8) some time ago, and didn't have any issues, but that of course should be because bsdlabel does not touch the last sectors, so gmirror would work. @Freddie Cash The above process is operator error, as both your gpart and gmirror commands are working on the same GEOM (ad0). You need to stack / layer your GEOMs (ie, do one operation on the disk, the other operations on the sub-parts). You are right. Typo mistake I made in my previous mail :) What you describe is what I actually did. gmirror'ed the disk, and then gpart'ed it. See my very first mail, for exact steps I made to do this. @Andrey V. Elsukov What do you mean when you said 'gpart the first disk'? gpart(8) is the default tool to make any type of partitions and partition tables. The list of exact commands and at least a photo of screen with the panic message will be good. Please check my first mail for all the details. I'm currently running the system with mirrored partitions, instead of disks. I'll setup a test system as well in the following days and give you all the details of the steps, commands and output of them.. screenshot will be made as well :) Regards, Marin 2011/2/28 Andrey V. Elsukov bu7c...@yandex.ru: On 28.02.2011 19:23, Marin Atanasov Nikolov wrote: I can confirm as well that I get kernel panic if I gpart and then gmirror a disk on 8.2-RELEASE. To reproduce it, I just did the following: 1) Boot a system with a Fixit image 2) Remove all gpart partitions 3) gpart the first disk (ad0) 4) Restored my data to the partitions from backups 5) Reboot 6) gmirror the ad0 disk And that's where I got kernel panic. gpart'ing the disk and the mirroring the partitions works just as fine, but not when you mirror the whole disk. What do you mean when you said 'gpart the first disk'? gpart(8) is the default tool to make any type of partitions and partition tables. The list of exact commands and at least a photo of screen with the panic message will be good. -- WBR, Andrey V. Elsukov -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ 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: FreeBSD 8.1 regression in x86bios.c
On Friday 25 February 2011 11:59 pm, Craig Boston wrote:
Hi all,
My laptop (Toshiba Portege R100) stopped working with an early boot
hang at some point between 8.0 and 8.1. After it broke last year I
had ended up just reverting to an earlier kernel, but finally found
the time to do a binary search and narrow it down.
The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt
handlers within the VBE interrupt handler. Unfortunately it was
causing real mode page faults because we were fetching instructions
from bogus addresses. Pass me the pointyhat, please.
PR: kern/144654
MFC after:3 days
With this commit in place, the system hangs almost immediately on
boot, right after probing kdbmux. With debug.x86bios.{call,int}
enabled from the loader, the final lines before the hang are:
avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200
di=0x)
Then a hard hang. With the 2 lines in x86bios.c reverted, the
system boots fine (even on a fresh 8.2 build with just that commit
backed out). The debug output from a successful boot looks like
this:
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x es=0x9e00
di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x es=0x0200
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023 es=0x0200
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x es=0x9c00
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023 es=0x9c00
di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x es=0x0200
di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023 es=0x0200
di=0x0028)
(many more lines)
In any event, I'm not sure if this is a true bug, or just a broken
BIOS, but either way I thought you might want to know about it.
See the exit status of the working cases. Bogus status (%ax ==
0xb13e) was returned, which means the VBE calls failed and aborted.
So, yes, I guess it is one of those broken VESA BIOSes. :-(
Jung-uk Kim
___
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: 8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 28.02.2011 17:23, Joan Picanyol i Puig wrote: http://lists.freebsd.org/pipermail/freebsd-geom/2010-July/004278.html 1. glabeled discs 2. two of this previous discs are gmirrored 3. this mirror is gparted We got distracted by side issues, but I believe this issue is still present, even though I have been unable to investigate further (it might well be that GPT specification is incompatible with gmirror'ed disks). For your convinience the interesting bits from that thread are: GEOM: da1: the secondary GPT table is corrupt or invalid. GEOM: da1: using the primary only -- recovery suggested. So, what explains the messages? gpart probes the disk before gmirror (or at least it prints later on dmesg), but since the offset is in the header, it should not even know about the gmirror + glabel part. When you create gmirror on the whole disk you have got: whole disk da0 +++ | mirror/gm0 | MD | +++ MD - gmirror's metadata in the last sector of da0. Now when you create GPT on the mirror/gm0: mirror/gm0 +-+-+--+-+ | | GPT | | GPT | +-+-+--+-+ When mirror/gm0 provider is tasted all is good. You got mirror with GPT without any warnings. But when da0 provider is tasted you got this: da0 +-+-+--+-++ | | GPT | | GPT || +-+-+--+-++ This provider has one sector in the end of the disk with unknown data, but there should be secondary GPT header. First of you got a message from gptboot about corrupt GPT. The second message is from GEOM_PART that it does not like that secondary GPT located not in the end of disk. This message GEOM: da1: the secondary GPT table is corrupt or invalid. GEOM: da1: using the primary only -- recovery suggested. does mean that your secondary GPT header or table is lost, or it is in disagree with primary one. AFAIR, it may mean different things in 8.1 and 8.2. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD 8.1 regression in x86bios.c
On Monday 28 February 2011 12:33 pm, Jung-uk Kim wrote:
On Friday 25 February 2011 11:59 pm, Craig Boston wrote:
Hi all,
My laptop (Toshiba Portege R100) stopped working with an early
boot hang at some point between 8.0 and 8.1. After it broke last
year I had ended up just reverting to an earlier kernel, but
finally found the time to do a binary search and narrow it down.
The offending commit is:
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
http://svn.freebsd.org/viewvc/base?view=revisionrevision=205647
Fix stupid typos. Some VESA BIOSes directly call BIOS interrupt
handlers within the VBE interrupt handler. Unfortunately it was
causing real mode page faults because we were fetching
instructions from bogus addresses. Pass me the pointyhat, please.
PR: kern/144654
MFC after: 3 days
With this commit in place, the system hangs almost immediately on
boot, right after probing kdbmux. With debug.x86bios.{call,int}
enabled from the loader, the final lines before the hang are:
avail memory = 1299705856 (1239 MB)
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x
es=0x0200 di=0x)
Then a hard hang. With the 2 lines in x86bios.c reverted, the
system boots fine (even on a fresh 8.2 build with just that
commit backed out). The debug output from a successful boot looks
like this:
kbd1 at kbdmux0
Calling int 0x10 (ax=0x4f00 bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Exiting int 0x10 (ax=0x004f bx=0x cx=0x dx=0x
es=0x9e00 di=0x)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0144 dx=0x
es=0x0200 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x2065 cx=0x9e32 dx=0x1023
es=0x0200 di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0143 dx=0x
es=0x9c00 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x1065 cx=0x9e32 dx=0x1023
es=0x9c00 di=0x0028)
Calling int 0x10 (ax=0x4f01 bx=0x cx=0x0141 dx=0x
es=0x0200 di=0x)
Exiting int 0x10 (ax=0xb13e bx=0x0865 cx=0x9e32 dx=0x1023
es=0x0200 di=0x0028)
(many more lines)
In any event, I'm not sure if this is a true bug, or just a
broken BIOS, but either way I thought you might want to know
about it.
See the exit status of the working cases. Bogus status (%ax ==
0xb13e) was returned, which means the VBE calls failed and aborted.
So, yes, I guess it is one of those broken VESA BIOSes. :-(
Please try the attached patch and let me know if it makes any
difference.
Thanks,
Jung-uk Kim
Index: sys/compat/x86bios/x86bios.c
===
--- sys/compat/x86bios/x86bios.c(revision 219101)
+++ sys/compat/x86bios/x86bios.c(working copy)
@@ -291,25 +291,6 @@ x86bios_emu_outl(struct x86emu *emu, uint16_t port
outl(port, val);
}
-static void
-x86bios_emu_get_intr(struct x86emu *emu, int intno)
-{
- uint16_t *sp;
- uint32_t iv;
-
- emu-x86.R_SP -= 6;
-
- sp = (uint16_t *)((vm_offset_t)x86bios_seg + emu-x86.R_SP);
- sp[0] = htole16(emu-x86.R_IP);
- sp[1] = htole16(emu-x86.R_CS);
- sp[2] = htole16(emu-x86.R_FLG);
-
- iv = x86bios_get_intr(intno);
- emu-x86.R_IP = iv 0x;
- emu-x86.R_CS = (iv 16) 0x;
- emu-x86.R_FLG = ~(F_IF | F_TF);
-}
-
void *
x86bios_alloc(uint32_t *offset, size_t size)
{
@@ -567,7 +548,6 @@ x86bios_unmap_mem(void)
static void
x86bios_init(void *arg __unused)
{
- int i;
mtx_init(x86bios_lock, x86bios lock, NULL, MTX_SPIN);
@@ -598,9 +578,6 @@ x86bios_init(void *arg __unused)
x86bios_emu.emu_outb = x86bios_emu_outb;
x86bios_emu.emu_outw = x86bios_emu_outw;
x86bios_emu.emu_outl = x86bios_emu_outl;
-
- for (i = 0; i 256; i++)
- x86bios_emu._x86emu_intrTab[i] = x86bios_emu_get_intr;
}
static void
___
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 - abysmal performance with samba since upgrade to 8.2-RELEASE
W dniu 2011-02-24 08:55, Jeremy Chadwick pisze: (...snip...) Samba === Rebuild the port (ports/net/samba35) with AIO_SUPPORT enabled. To use AIO you will need to load the aio.ko kernel module (kldload aio) first. Relevant smb.conf tunings: [global] socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072 use sendfile = no min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes ZFS pools === pool: backups state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM backups ONLINE 0 0 0 ada2 ONLINE 0 0 0 errors: No known data errors pool: data state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM dataONLINE 0 0 0 ada1 ONLINE 0 0 0 errors: No known data errors ZFS tunings === Your tunings here are wild (meaning all over the place). Your use of vfs.zfs.txg.synctime=1 is probably hurting you quite badly, in addition to your choice to enable prefetching (every ZFS FreeBSD system I've used has benefit tremendously from having prefetching disabled, even on systems with 8GB RAM and more). You do not need to specify vm.kmem_size_max, so please remove that. Keeping vm.kmem_size is fine. Also get rid of your vdev tunings, I'm not sure why you have those. My relevant /boot/loader.conf tunings for 8.2-RELEASE (note to readers: the version of FreeBSD you're running, and build date, matters greatly here so do not just blindly apply these without thinking first): # We use Samba built with AIO support; we need this module! aio_load=yes # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. vm.kmem_size=8192M vfs.zfs.arc_max=6144M # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: Systems with 8GB of RAM or more have prefetch enabled by # default. vfs.zfs.prefetch_disable=1 # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the bursty stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout=5 sysctl tunings === Please note that the below kern.maxvnodes tuning is based on my system usage, and yours may vary, so you can remove or comment out this option if you wish. The same goes for vfs.ufs.dirhash_maxmem. As for vfs.zfs.txg.write_limit_override, I strongly suggest you keep this commented out for starters; it effectively rate limits ZFS I/O, and this smooths out overall performance (otherwise I was seeing what appeared to be incredible network transfer speed, then the system would churn hard for quite some time on physical I/O, then fast network speed, physical I/O, etc... very bursty, which I didn't want). # Increase send/receive buffer maximums from 256KB to 16MB. # FreeBSD 7.x and later will auto-tune the size, but only up to the max. net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 # Double send/receive TCP datagram memory allocation. This defines the # amount of memory taken up by default *per socket*. net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=131072 # dirhash_maxmem defaults to 2097152 (2048KB). dirhash_mem has reached # this limit a few times, so we should increase dirhash_maxmem to # something like 16MB (16384*1024). vfs.ufs.dirhash_maxmem=16777216 # # ZFS tuning parameters # NOTE: Be sure to see /boot/loader.conf for additional tunings # # Increase number of vnodes; we've seen vfs.numvnodes reach 115,000 # at times. Default max is a little over 200,000. Playing it safe... kern.maxvnodes=25 # Set TXG write limit to a lower threshold. This helps level out # the throughput rate (see zpool iostat). A value of 256MB works well # for systems with 4GB of RAM, while 1GB works well for us w/ 8GB on # disks which have 64MB cache. vfs.zfs.txg.write_limit_override=1073741824 Good luck. Jeremy, you're just invaluable! :) In short - I applied tips suggested above (only difference was vfs.zfs.txg.write_limit_override set to 128MB, and sendfile, which I still have enabled) and it's first time _ever_ I see samba performing so fast on FreeBSD (on 100Mb link)! long story: I'm using old, crappy, low memory desktop PC as home router/test server/(very little) storage: FreeBSD 9.0-CURRENT #2 r219090: Mon Feb 28 03:06:13 CET 2011 CPU: mobile AMD Athlon(tm) XP 2200+
Possible dri issue on the Kernel side
I am an avid Linux user and recent BSD convert. I have a Lenovo Thinkpad L412 with an Intel i3 370M ATI HD 5145(rebadged HD4570) graphics. I recently tried Fedora 14 and had the same problem that I have had with PC-BSD, the underside of the laptop got HOT! When I was running on the radeon driver it was ridiculously hot, then when i switched to the catalyst it was managable. I found out that the following link worked in Fedora 14: http://forums.fedoraforum.org/showthread.php?t=155503. In PC-BSD I was using the radeon driver with DynamicPM, Clockgating, and ForceLowPowerMode all on and it was still hot. After careful consideration and diagnosis, with thanks to Dru and Martin, we believe that this might be a dri problem on the kernel side, possibly linked to the Intel Core i3. I am willing to do testing for you on PC-BSD 8.2 if you would like to help everyone. Let me know what I can do to help! Thought I would list the repo link: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/14/i386/repoview/index.html * pciconf -lv:* hostb0@pci0:0:0:0: class=0x06 card=0x218317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x218417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x216417aa chip=0x3b468086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x216417aa chip=0x3b488086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:0:28:5: class=0x060400 card=0x216417aa chip=0x3b4c8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib8@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b098086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b298086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'IBEX AHCI Controller(4Port)' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x03 card=0x21bb17aa chip=0x95531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4570 Series (M92)' class = display subclass = VGA hdac1@pci0:1:0:1: class=0x040300 card=0x21bb17aa chip=0xaa381002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA none2@pci0:2:0:0: class=0x088000 card=0x212e17aa chip=0x2382197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X SD/MMC Host Controller (JMB38X)' class = base peripheral sdhci0@pci0:2:0:2: class=0x080501 card=0x212d17aa chip=0x2381197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' class = base peripheral subclass = SD host controller none3@pci0:2:0:3: class=0x088000 card=0x212f17aa chip=0x2383197b rev=0x00 hdr=0x00 vendor = 'JMicron
Possible dri kernel issue
To whom it may concern: I am an avid Linux user and recent BSD convert. I have a Lenovo Thinkpad L412 with an Intel i3 370M ATI HD 5145(rebadged HD4570) graphics. I recently tried Fedora 14 and had the same problem that I have had with PC-BSD, the underside of the laptop got HOT! When I was running on the radeon driver it was ridiculously hot, then when i switched to the catalyst it was managable. I found out that the following link worked in Fedora 14: http://forums.fedoraforum.org/showthread.php?t=155503. In PC-BSD I was using the radeon driver with DynamicPM, Clockgating, and ForceLowPowerMode all on and it was still hot. After careful consideration and diagnosis, with thanks to Dru and Martin, we believe that this might be a dri problem on the kernel side, possibly linked to the Intel Core i3. I am willing to do testing for you on PC-BSD 8.2 if you would like to help everyone. Let me know what I can do to help! Thought I would list the repo link: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/14/i386/repoview/index.html BEFORE SENDING FINISH THIS! pciconf -lv: hostb0@pci0:0:0:0: class=0x06 card=0x218317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x218417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB hdac0@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:2: class=0x060400 card=0x216417aa chip=0x3b468086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:0:28:3: class=0x060400 card=0x216417aa chip=0x3b488086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:0:28:5: class=0x060400 card=0x216417aa chip=0x3b4c8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = USB pcib8@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b098086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b298086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'IBEX AHCI Controller(4Port)' class = mass storage subclass = SATA none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = serial bus subclass = SMBus vgapci0@pci0:1:0:0: class=0x03 card=0x21bb17aa chip=0x95531002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI Mobility Radeon HD 4570 Series (M92)' class = display subclass = VGA hdac1@pci0:1:0:1: class=0x040300 card=0x21bb17aa chip=0xaa381002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA none2@pci0:2:0:0: class=0x088000 card=0x212e17aa chip=0x2382197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' device = 'JMB38X SD/MMC Host Controller (JMB38X)' class = base peripheral sdhci0@pci0:2:0:2: class=0x080501 card=0x212d17aa chip=0x2381197b rev=0x00 hdr=0x00 vendor = 'JMicron Technology Corp.' class = base peripheral subclass = SD host controller none3@pci0:2:0:3: class=0x088000 card=0x212f17aa chip=0x2383197b
Re: Change in behavior to stat(1)
On Mon, 28 Feb 2011 12:15, stephen@ wrote:
I had a little script that would remove broken links. I used to do it like
this:
if ! stat -L $link /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records) stat was
changed so that stat -L would use lstat(2) if the link is broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
Stephen
You might find sysutils/symlinks interesting. I have been using it a long
time and have not had to consider adjusting much in the way of shell
scripting to remove dirty links.
-c == change absolute/messy links to relative
-d == delete dangling links
-o == warn about links across file systems
-r == recurse into subdirs
-s == shorten lengthy links
-t == show what would be done by -c
-v == verbose (show all symlinks)
Quite interesting though how such a little tweak has caused a massive
expansion of your command line and required utils.
Good luck,
--
jhell
___
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: Change in behavior to stat(1)
On Mon, 28 Feb 2011 23:39:10 +0100, jhell jh...@dataix.net wrote:
On Mon, 28 Feb 2011 12:15, stephen@ wrote:
I had a little script that would remove broken links. I used to do it
like this:
if ! stat -L $link /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records) stat
was changed so that stat -L would use lstat(2) if the link is broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
Stephen
You might find sysutils/symlinks interesting. I have been using it a
long time and have not had to consider adjusting much in the way of
shell scripting to remove dirty links.
-c == change absolute/messy links to relative
-d == delete dangling links
-o == warn about links across file systems
-r == recurse into subdirs
-s == shorten lengthy links
-t == show what would be done by -c
-v == verbose (show all symlinks)
Quite interesting though how such a little tweak has caused a massive
expansion of your command line and required utils.
Good luck,
Find has some voodoo for handling links also.
Ronald.
___
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: Change in behavior to stat(1)
On Mon, Feb 28, 2011 at 11:15:39AM -0600, Stephen Montgomery-Smith wrote:
I had a little script that would remove broken links. I used to do
it like this:
if ! stat -L $link /dev/null; then rm $link; fi
But recently (some time in February according to the CVS records)
stat was changed so that stat -L would use lstat(2) if the link is
broken.
So I had to change it to
if stat -L $link | awk '{print $3}' | grep l /dev/null;
then rm $link; fi
but it is a lot less elegant.
What is the proper accepted way to remove broken links?
If your complaint is the literal length of the line, you should be
able to change your one-liner to:
if stat -L -f %Sp $link | grep l /dev/null; then rm $link; fi
Though I agree this is less elegant. Unrelated (but worth noting), be
aware your one-liner will break horribly with files that contains
spaces; use $link instead.
Possibly you could use the example from the find(1) man page:
find -L /usr/ports/packages -type l -exec rm -- {} +
Delete all broken symbolic links in /usr/ports/packages.
(Note that the + on the end is not a typo, see the man page)
Otherwise, possibly someone should add a flag to stat(1) that inhibits
falling back on lstat(2).
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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
FYI: Userspace DTrace MFC to stable/8
Dear all:
Just an FYI that I've gone ahead and merged userspace DTrace support to
FreeBSD 8.x from 9.x. While it appeared to pass build tests locally, boot and
run, etc, this is a non-trivial merge, and it's possible I've messed up. If
so, apologies in advance, and I'll try to resolve any problems as quickly as I
can!
And of course, many thanks go to Rui Paulo, who did the port of userspace
DTrace to FreeBSD 9.x with support from the FreeBSD Foundation!
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
-- Forwarded message --
Date: Mon, 28 Feb 2011 23:28:35 + (UTC)
From: Robert Watson rwat...@freebsd.org
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-sta...@freebsd.org, svn-src-stabl...@freebsd.org
Subject: svn commit: r219107 - in stable/8/sys: amd64/amd64 amd64/include
boot/common cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys
cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensol...
Author: rwatson
Date: Mon Feb 28 23:28:35 2011
New Revision: 219107
URL: http://svn.freebsd.org/changeset/base/219107
Log:
Merge userspace DTrace support from head to stable/8:
r209721:
Merge from vendor-sys/opensolaris:
* add fasttrap files
r209731:
Introduce USD_{SET,GET}{BASE,LIMIT}. These help setting up the user
segment descriptor hi and lo values. Idea from Solaris.
Reviewed by: kib
r209763:
Fix style issues with the previous commit, namely
use-tab-instead-of-space and don't use underscores in macro variables.
Pointed out by: bde
r210292:
Fix typo in comment.
r210357:
MFamd64:
Add USD_GETBASE(), USD_SETBASE(), USD_GETLIMIT() and USD_SETLIMIT().
r210611:
Bump the witness pendlist to 768 to accomodate the increased number of
spinlocks.
r211553:
Add sysname to struct opensolaris_utsname. This is needed by one DTrace
test.
r211566:
Add a sysname char * to struct opensolaris_utsname.
r211606:
Add the FreeBSD definition for the fasttrap ioctls.
r211607:
Add a function compatibility function dtrace_instr_size_isa() that on
FreeBSD does the same as dtrace_dis_isize().
r211608:
Kernel DTrace support for:
o uregs (sson@)
o ustack (sson@)
o /dev/dtrace/helper device (needed for USDT probes)
r211610:
Add more compatibility structure members needed by the upcoming fasttrap
DTrace device.
r211611:
Destroy the helper device when unloading.
r211613:
Fix style issues.
r211614:
Bump KDTRACE_THREAD_ZERO and use M_ZERO as a malloc flag instead of
calling bzero.
r211615:
Remove an elif and add an or-clause.
r211616:
Add an extra comment to the SDT probes definition. This allows us to get
use '-' in probe names, matching the probe names in Solaris.
Add userland SDT probes definitions to sys/sdt.h.
r211617:
Call the systrace_probe_func() when the error value.
r211618:
Port this to FreeBSD. We miss some suword functions, so we use copyout.
r211738:
Port the fasttrap provider to FreeBSD. This provider is responsible for
injecting debugging probes in the userland programs and is the basis for
the pid provider and the usdt provider.
r211744:
MD fasttrap implementation.
r211745:
Replace a pksignal() call with tdksignal().
Pointed out by: kib
r211746:
Update for the recent location of the fasttrap code.
r211747:
Replace structure assignments with explicity memcpy calls. This allows
Clang to compile this file: it was using the builtin memcpy and we want
to use the memcpy defined in gptboot.c. (Clang can't compile boot2 yet).
Submitted by: Dimitry Andric dimitry at andric.com
Reviewed by: jhb
r211751:
Add a trap code for DTrace induced traps.
r211752:
Add two DTrace trap type values. Used by fasttrap.
r211753:
Enable fasttrap and make dtraceall depend on fasttrap when building i386
or amd64.
r211804:
Call the necessary DTrace function pointers when we have different kinds
of traps.
r211813:
Add the necessary DTrace function pointers.
r211839:
Sync DTrace bits with amd64 and fix the build.
r211924:
Register an interrupt vector for DTrace return probes. There is some
code missing in lapic to make sure that we don't overwrite this entry,
but this will be done on a sequent commit.
r211925:
Replace a memory barrier with a mutex barrier.
r211926:
Add the path necessary to find fasttrap_isa.h to CFLAGS.
r211929:
Remove debugging.
r212004:
When DTrace is enabled, make sure we don't overwrite the IDT_DTRACE_RET
entry with an IRQ for some hardware component.
Reviewed by: jhb
r212093:
Make the /dev/dtrace/helper node have the mode 0660. This allows
programs that refuse to run as root (pgsql) to install probes when their
user
Re: Change in behavior to stat(1)
Jeremy Chadwick wrote:
Possibly you could use the example from the find(1) man page:
find -L /usr/ports/packages -type l -exec rm -- {} +
Delete all broken symbolic links in /usr/ports/packages.
(Note that the + on the end is not a typo, see the man page)
Brilliant!
Since this is *precisely* the purpose of my script, I think I will use
this code instead,
___
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: statd/lockd startup failure
On 02/17/11 22:06, Andrea Venturoli wrote: I seem to remember a similar problem I had a long time ago. I opted to use a consistent, not-used port and haven't seen the problem since (this was years ago, so I can't remember if the error you're seeing was identical to mine). /etc/rc.conf: rpc_statd_flags=-p 898 rpc_lockd_flags=-p 4045 I have: rpc_statd_flags=-p 918 rpc_lockd_flags=-p 868 Still statd occasionally fails to start. It might be that something else has already bound to port 918, though I don't know what. I'll check as soon as I have the chance. It happened this morning: lockd could not start and I verified it was an NFS mount which used port 868 as a client. Now I'm trying the noresvport to mount_nfs... bye av. ___ 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
FreeBSD supported branches update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 7.1. The new list of supported branches is below and at http://security.freebsd.org/ . Users of FreeBSD 7.1 are advised to upgrade promptly to a newer release (most likely the recently announced FreeBSD 7.4) either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the relevant release announcement. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_7 |n/a |n/a |n/a |February 28, 2013| |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_7_4 |7.4-RELEASE |Extended|February 24, 2011|February 28, 2013| |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| |---+++-+-| |RELENG_8_2 |8.2-RELEASE |Normal |February 24, 2011|February 29, 2012| +-+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1sorYACgkQFdaIBMps37IgAgCePHsPcwZ/3mvoBzB3yvvo5txo bDcAn0ze3I/h6fz90GVCEYm0cqBMFeOL =DopZ -END PGP SIGNATURE- ___ 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
