Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Nathan Whitehorn]

On 10/09/13 18:55, Teske, Devin wrote:
> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>
>> On 10/09/13 01:13, Allan Jude wrote:
>>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
 On 10/07/13 21:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
> sector gnop trick, and optional GELI encryption. We would like to commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>
 Thanks for doing this! I had a few comments:
 1. ZFS is not bootable on all architectures. Could you adjust that menu
 item to only display for i386, amd64, and (I think?) sparc64. Use uname
 -m, not -p, for this.
>>> I had not considered that, I'll make that change
>>>
 1a. The script is broken on sparc64 in any case, which uses VTOC8
 instead of GPT.
>>> I'll disable sparc64 as well
>>>
 2. Why are you using camcontrol? That is guaranteed not to work on
 non-CAM systems. You should use the GEOM ident string if you need an ID.
>>> The GEOM ident string doesn't do enough to help the user identify which
>>> drive is which.
>>> More data is not exposed anywhere that I could find
>>>
>>> What we really need, is dev.ada.0.desc% like we have for network
>>> interfaces and a slew of other devices. GEOM data is great, but it is
>>> not exposed in a shell friendly way any place that I could find, other
>>> than the sysctl with DOT and XML data.
>> This is one of the reasons the partition editor is written in C. There
>> are a few other odd corner-cases where C is much more powerful than the
>> command-line for the GEOM operations that partedit needs to do. I'm not
>> sure how to usefully get it just from the shell. You can see how to do
>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>
 3. Any plans to integrate this into the regular partition editor? ZFS
 support is important enough that I will definitely not get in the way,
 even as a bolt-on, but it would be a shame for it to stay that way. The
 editor is also designed for ZFS to be added.
>>> I am a sysadmin, not a programmer. I can't write C. Most people
>>> deploying servers can't write C. I agree with Devin Teske, if everything
>>> was in shell it would be a lot more usable for non-developers, who
>>> probably make up the majority of people who deploy FreeBSD.
>> There are some cases the other way too. Devin is probably the most
>> shell-proficient FreeBSD committer.
> Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself).
>
>
>> I certainly can't write shell
>> scripts at that level, which means that for me bsdconfig, for example,
>> is effectively read-only (and quite hard to read as well).
> In the past few days of working on the bsdinstall_zfs patch-set with Allan
> Jude, I learned something new actually.
>
> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>
> Imagine you're starting a new C project on an operating system that has
> all new syscalls and all new APIs that you've never seen. Would be pretty
> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
> and hey, now you're slinging code in MinGW on Windows when you don't
> know a lick of M$ syscalls or APIs.
>
> In a similar manner, I've witnessed functionality be added that is truly
> functional *without* using any of the API calls. Then I come in and do
> a round of optimizations to leverage the existing API.
>
> Shell is kinda like that...
>
> I'm noticing Allan Jude doesn't k

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Teske, Devin]

On Oct 10, 2013, at 12:00 AM, Nathan Whitehorn wrote:

> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>> 
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 
>> 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>> 
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>> 
>> 
>> We look forward to your feedback
>> 
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.
 I had not considered that, I'll make that change
 
> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well
 
> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find
 
 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>> 
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.
 I am a sysadmin, not a programmer. I can't write C. Most people
 deploying servers can't write C. I agree with Devin Teske, if everything
 was in shell it would be a lot more usable for non-developers, who
 probably make up the majority of people who deploy FreeBSD.
>>> There are some cases the other way too. Devin is probably the most
>>> shell-proficient FreeBSD committer.
>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>> itself).
>> 
>> 
>>> I certainly can't write shell
>>> scripts at that level, which means that for me bsdconfig, for example,
>>> is effectively read-only (and quite hard to read as well).
>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>> Jude, I learned something new actually.
>> 
>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>> 
>> Imagine you're starting a new C project on an operating system that has
>> all new syscalls and all new APIs that you've never seen. Would be pretty
>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>> and hey, now you're slinging code in MinGW on Windows when you don't
>> know a lick of M$ syscalls or APIs.
>> 
>> In a similar manner, I've witnessed functionality be added that is truly
>> functional 

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Allan Jude]

On 2013-10-10 03:00, Nathan Whitehorn wrote:
> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>>
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>> sector gnop trick, and optional GELI encryption. We would like to commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>>
>> It includes a single configuration menu that allows you to select all of
>> the required details, including which drives to use (gets details from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>
>>
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with just 
>> 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' dialog
>> and enabled by default
>>
>>
>> You can browse the patches here:
>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>
>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>
>>
>> We look forward to your feedback
>>
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that menu
> item to only display for i386, amd64, and (I think?) sparc64. Use uname
> -m, not -p, for this.
 I had not considered that, I'll make that change

> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well

> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find

 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>>
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay that way. The
> editor is also designed for ZFS to be added.
 I am a sysadmin, not a programmer. I can't write C. Most people
 deploying servers can't write C. I agree with Devin Teske, if everything
 was in shell it would be a lot more usable for non-developers, who
 probably make up the majority of people who deploy FreeBSD.
>>> There are some cases the other way too. Devin is probably the most
>>> shell-proficient FreeBSD committer.
>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>> itself).
>>
>>
>>> I certainly can't write shell
>>> scripts at that level, which means that for me bsdconfig, for example,
>>> is effectively read-only (and quite hard to read as well).
>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>> Jude, I learned something new actually.
>>
>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>>
>> Imagine you're starting a new C project on an operating system that has
>> all new syscalls and all new APIs that you've never seen. Would be pretty
>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>> and hey, now you're slinging code in MinGW on Windows when you don't
>> know a lick of M$ syscalls or APIs.
>>
>> In a similar manner, I've witnessed functionality be added that is truly
>> functional *without* using any of the API c

Re: claws-mail deadlocking in iconv

[O. Hartmann]

On Wed, 9 Oct 2013 18:34:46 +0200
Fabian Keil  wrote:

> After the iconv import claws-mail started to deadlock in iconv every
> now and then on my system, which prevented claws-mail from rendering
> windows or reacting to input.
> 
> So far I haven't been able to reproduce this intentionally and various
> rebuilds of ports, kernel and userland (mainly for other reasons) had
> no effect.
> 
> When the problem occurs, trying to attach to the process causes
> gdb and gdb76 to crash which also crashes claws-mail, but sending
> SIGABRT causes a proper core dump that can be analysed with gdb.
> 
> The backtraces always show that there is only one thread running and
> it's trying to lock cm_lock in _citrus_mapper_close(), which
> apparently is already locked due to a _citrus_mapper_close()
> recursion. Examples:
> 
> #0  _umtx_op_err ()
> at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37
> RSYSCALL_ERR(_umtx_op) [New Thread 80a806400 (LWP 100487/claws-mail)]
> (gdb) where
> #0  _umtx_op_err ()
> at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1
> 0x0008084861a6 in __thr_rwlock_wrlock (rwlock=0x80a8a47c0,
> tsp=)
> at /usr/src/lib/libthr/thread/thr_umtx.c:296 #2  0x000808489b1d
> in rwlock_wrlock_common (rwlock=, abstime=0x0)
> at /usr/src/lib/libthr/thread/thr_rwlock.c:267 #3  0x000808489a8b
> in _pthread_rwlock_wrlock (rwlock=0x80a8a47c0)
> at /usr/src/lib/libthr/thread/thr_rwlock.c:289 #4  0x00080911e848
> in _citrus_mapper_close (cm=0x80b5a2d80)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:375 #5  0x00080d205d18
> in _citrus_mapper_serial_mapper_uninit (cm=0x80b5a2d40)
> at 
> /usr/src/lib/libiconv_modules/mapper_parallel/../mapper_serial/citrus_mapper_serial.c:110
> #6  0x00080911e8d7 in mapper_close (cm=0x80b5a2d40)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:188 #7  0x00080911e88c
> in _citrus_mapper_close (cm=)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:384 #8  0x00080c4e83f3
> in close_srcs (sl=0x80b591140)
> at /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:206 #9
> 0x00080c4e7dc9 in _citrus_iconv_std_iconv_uninit_shared
> (ci=)
> at /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:415 #10
> 0x0008090f3f95 in release_shared (ci=0x80a8ee630)
> at /usr/src/lib/libc/iconv/citrus_iconv.c:99 #11 0x0008090f4002
> in _citrus_iconv_close (cv=0x80d88d5d0)
> at /usr/src/lib/libc/iconv/citrus_iconv.c:335 #12 0x0008090f1ca6
> in iconv_close (handle=0x80a8a47c0)
> at /usr/src/lib/libc/iconv/iconv.c:131 #13 0x0046376d in
> conv_iconv_strdup (inbuf=0x7fff58b0 "\n", src_code=0x80b5b4db0
> "Windows-1252", dest_code=0x6f03d0 "UTF-8") at codeconv.c:895 #14
> 0x00463d13 in conv_convert (conv=0x80b5a4e80,
> outbuf=0x7fff3720 "", outlen=8192, inbuf=0x7fff58b0 "\n") at
> codeconv.c:734 #15 0x005e22ac in textview_write_line
> (textview=0x80a959cc0, str=0x7fff58b0 "\n", conv=0x80b5a4e80,
> do_quote_folding=1) at textview.c:1573 #16 0x005df8e4 in
> textview_write_body (textview=0x80a959cc0, mimeinfo=0x80aad2d00) at
> textview.c:1177 #17 0x005e5363 in textview_add_part
> (textview=0x80a959cc0, mimeinfo=0x80aad2d00) at textview.c:826 #18
> 0x005e4053 in recursive_add_parts (textview=0x80a959cc0,
> node=0x80a826190) at textview.c:839 #19 0x005e4302 in
> recursive_add_parts (textview=0x80a959cc0, node=0x80aa81d20) at
> textview.c:888 #20 0x005e4302 in recursive_add_parts
> (textview=0x80a959cc0, node=0x80a828890) at textview.c:888 #21
> 0x005defa1 in textview_add_parts (textview=0x80a959cc0,
> mimeinfo=0x80b610700) at textview.c:898 #22 0x005deb85 in
> textview_show_part (textview=0x80a959cc0, mimeinfo=0x80b610700,
> fp=0x8094319a0) at textview.c:645 [...]
> 
> #0  0x000808491b9c in __error () from /lib/libthr.so.3
> #1  0x00080848bb1d in rwlock_wrlock_common (rwlock= optimized out>, abstime=0x0)
> at /usr/src/lib/libthr/thread/thr_rwlock.c:267 #2  0x00080848ba8b
> in _pthread_rwlock_wrlock (rwlock=0x80a8ede20)
> at /usr/src/lib/libthr/thread/thr_rwlock.c:289 #3  0x00080911f848
> in _citrus_mapper_close (cm=0x80a8bfc40)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:375 #4  0x00080ce02d18
> in _citrus_mapper_serial_mapper_uninit (cm=0x80a8bfc00)
> at 
> /usr/src/lib/libiconv_modules/mapper_parallel/../mapper_serial/citrus_mapper_serial.c:110
> #5  0x00080911f8d7 in mapper_close (cm=0x80a8bfc00)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:188 #6  0x00080911f88c
> in _citrus_mapper_close (cm=)
> at /usr/src/lib/libc/iconv/citrus_mapper.c:384 #7  0x00080c5893f3
> in close_srcs (sl=0x80a8edda0)
> at /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:206 #8
> 0x00080c588dc9 in _citrus_iconv_std_iconv_uninit_shared
> (ci=)
> at /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:415 #9
> 0x0008090f4f95 in release_shared (ci=0x80b408890)
> at /usr/src/lib/libc/iconv/citrus_iconv.c:99 #10 0x000809

Re: /usr/src/lib/msun errors

[Joe Nosay]

Yes, I did. To what extent did I screw up?

# added by use.perl 2013-03-03 23:39:20
PERL_VERSION=5.16.2
RUBY_DEFAULT_VER=1.9
ALLOW_SHARED_TEXTREL=1

CFLAGS+= -mssse3 -Wall
CXXFLAGS+= -mssse3




On Wed, Oct 9, 2013 at 9:33 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Wed, Oct 09, 2013 at 09:00:11PM -0400, Joe Nosay wrote:
> > Src is from 10/7/13 on i386. Base is from April.
>
> > cc  -O2 -pipe -mssse3 -Wall  -I/usr/src/lib/msun/x86
> -I/usr/src/lib/msun/ld80 -I/usr/src/lib/msun/src
> -I/usr/src/lib/msun/../libc/include  -I/usr/src/lib/msun/../libc/i386
> -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses -c
> /usr/src/lib/msun/src/e_j0.c -o e_j0.o
> > /usr/src/lib/msun/src/e_j0.c:281:10: error: variable 'p' is used
> uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
>
> Are you setting CFLAGS in make.conf?
>
> --
> Steve
>
___
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: /usr/src/lib/msun errors

[Andreas Nilsson]

Since there is -Wall in your CFALGS there will be quite a few warnings,
which combined with -Werror which promotes warnings to errors makes it fail.

Try removing -Wall and see if it works. Also -mssse3 can trigger more
subtle stuff.

Best regards
Andreas


On Thu, Oct 10, 2013 at 9:49 AM, Joe Nosay  wrote:

> Yes, I did. To what extent did I screw up?
>
> # added by use.perl 2013-03-03 23:39:20
> PERL_VERSION=5.16.2
> RUBY_DEFAULT_VER=1.9
> ALLOW_SHARED_TEXTREL=1
>
> CFLAGS+= -mssse3 -Wall
> CXXFLAGS+= -mssse3
>
>
>
>
> On Wed, Oct 9, 2013 at 9:33 PM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Wed, Oct 09, 2013 at 09:00:11PM -0400, Joe Nosay wrote:
> > > Src is from 10/7/13 on i386. Base is from April.
> >
> > > cc  -O2 -pipe -mssse3 -Wall  -I/usr/src/lib/msun/x86
> > -I/usr/src/lib/msun/ld80 -I/usr/src/lib/msun/src
> > -I/usr/src/lib/msun/../libc/include  -I/usr/src/lib/msun/../libc/i386
> > -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror
> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> > -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum
> > -Wno-knr-promoted-parameter -Wno-parentheses -c
> > /usr/src/lib/msun/src/e_j0.c -o e_j0.o
> > > /usr/src/lib/msun/src/e_j0.c:281:10: error: variable 'p' is used
> > uninitialized whenever 'if' condition is false
> > [-Werror,-Wsometimes-uninitialized]
> >
> > Are you setting CFLAGS in make.conf?
> >
> > --
> > Steve
> >
> ___
> 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"
>
___
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"

(bsd)patch vs file removal

[Andriy Gapon]

The following is from patch -C -p1:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/sys/cddl/compat/opensolaris/sys/taskq.h
b/sys/cddl/compat/opensolaris/sys/taskq.h
|deleted file mode 100644
|index ffe70ca..000
|--- a/sys/cddl/compat/opensolaris/sys/taskq.h
|+++ /dev/null
--
Patching file sys/cddl/compat/opensolaris/sys/taskq.h using Plan A...
Empty context always matches.
Hunk #1 failed at 0.
1 out of 1 hunks failed while patching sys/cddl/compat/opensolaris/sys/taskq.h

-- 
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"

Re: ZFS L2ARC - incorrect size and abnormal system load on r255173

[Vitalij Satanivskij]

Same situation hapend yesterday again :( 

What's confuse me while trying to understend where I'm wrong


Firt some info.

We have zfs pool  "POOL" and one more zfs on it "POOL/zfs"

POOL - have only primarycache enabled "ALL" 
POOL/zfs - have both primay and secondary for "ALL"

POOL have compression=lz4

POOL/zfs have none


POOL - have around 9TB data

POOL/zfs - have 1TB

Secondary cache have configuration - 

cache
  gpt/cache0ONLINE   0 0 0
  gpt/cache1ONLINE   0 0 0
  gpt/cache2ONLINE   0 0 0

gpt/cache0-2 it's intel sdd SSDSC2BW180A4 180gb 

So full real size  for l2 is 540GB (realy 489gb)

First question  - data on l2arc will be compressed on not?

Second in stats we see 

L2 ARC Size: (Adaptive) 2.08TiB

eary it was 1.1 1.4 ...

So a) how cache can be biger than zfs it self
   b) in case it's not compressed (answer for first question) how it an be 
biger than real ssd size?


one more coment if l2 arc size grove above phisical sizes I se  next stats 

kstat.zfs.misc.arcstats.l2_cksum_bad: 50907344
kstat.zfs.misc.arcstats.l2_io_error: 4547377

and growing.


System is r255173 with patch from rr255173


At last maybe somebody have any ideas what's realy hapend...





Vitalij Satanivskij wrote:
VS> 
VS> One more question - 
VS> 
VS> we have two counter - 
VS> 
VS> kstat.zfs.misc.arcstats.l2_size: 1256609410560
VS> kstat.zfs.misc.arcstats.l2_asize: 1149007667712
VS> 
VS> can anybody explain how to understand them i.e.  l2_asize - real used space 
on l2arc an l2_size - uncompressed size,
VS> 
VS> or maybe something else ?
VS> 
VS> 
VS> 
VS> Vitalij Satanivskij wrote:
VS> VS> 
VS> VS> Data on pool have compressratio around 1.4 
VS> VS> 
VS> VS> On diferent servers with same data type and load L2 ARC Size: 
(Adaptive) can be diferent 
VS> VS> 
VS> VS> for example 1.04TiB vs  1.45TiB
VS> VS> 
VS> VS> But it's all have same porblem  - grow in time.
VS> VS> 
VS> VS> 
VS> VS> More stange for us - 
VS> VS> 
VS> VS> ARC: 80G Total, 4412M MFU, 5040M MRU, 76M Anon, 78G Header, 2195M Other
VS> VS> 
VS> VS> 78G header size and ubnormal - 
VS> VS> 
VS> VS> kstat.zfs.misc.arcstats.l2_cksum_bad: 210920592
VS> VS> kstat.zfs.misc.arcstats.l2_io_error: 7362414
VS> VS> 
VS> VS> sysctl's growing avery second.
VS> VS> 
VS> VS> All part's of server (as hardware part's) in in normal state.
VS> VS> 
VS> VS> After reboot no problem's for some period untile cache size grow to 
some limit.
VS> VS> 
VS> VS> 
VS> VS> 
VS> VS> Mark Felder wrote:
VS> VS> MF> On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote:
VS> VS> MF> > 
VS> VS> MF> > How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total 
physical size
VS> VS> MF> > of L2ARC devices 490GB?
VS> VS> MF> > 
VS> VS> MF> 
VS> VS> MF> http://svnweb.freebsd.org/base?view=revision&revision=251478
VS> VS> MF> 
VS> VS> MF> L2ARC compression perhaps?
VS> VS> MF> ___
VS> VS> MF> freebsd-current@freebsd.org mailing list
VS> VS> MF> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> VS> MF> To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"
VS> VS> ___
VS> VS> freebsd-current@freebsd.org mailing list
VS> VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> VS> To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"
VS> ___
VS> freebsd-current@freebsd.org mailing list
VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
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: Assertion in zdb?

[Vitalij Satanivskij]

Hello.

Yes, load on machine (on fs) is very extensive.

Ok  thank you for usefull information




Richard Todd wrote:
RT> Vitalij Satanivskij  writes:
RT> 
RT> > Hello. 
RT> >
RT> > System - 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r255173
RT> >
RT> > While trying to get some statistics from zdb 
RT> >
RT> >  zdb -dd disk1 > stat.log
RT> >
RT> > get some assertion: 
RT> >
RT> > Assertion failed: object_count == usedobjs (0x85727 == 0x3aa93d), file 
/usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c, 
line 1767.
RT> > zsh: abort (core dumped)  zdb -dd disk1 > stat.log
RT> >
RT> > Maybe somebody have any idea about what's it's can be and how big problem 
it's (or not a problem at all)?
RT> 
RT> Probably not a problem unless it happens reliably when you try it multiple
RT> times.  Since zdb looks at the raw disks, if the filesystem/zpool is 
active, 
RT> zdb can easily read bits of the zpool metadata off the disks at different
RT> times and thus see an inconsistent state.  Hence trying to get stats out of 
RT> zdb always carries a certain risk of not working.  
RT> 
RT> ___
RT> freebsd-current@freebsd.org mailing list
RT> http://lists.freebsd.org/mailman/listinfo/freebsd-current
RT> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
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: ZFS L2ARC - incorrect size and abnormal system load on r255173

[Vitalij Satanivskij]

Hm, another strange thing's on another server -

zfs-stats -L


ZFS Subsystem ReportThu Oct 10 12:56:54 2013


L2 ARC Summary: (DEGRADED)
Passed Headroom:8.34m
Tried Lock Failures:145.66m
IO In Progress: 9.76m
Low Memory Aborts:  526
Free on Write:  1.70m
Writes While Full:  29.28k
R/W Clashes:341.30k
Bad Checksums:  865.91k
IO Errors:  44.19k
SPA Mismatch:   32.03m

L2 ARC Size: (Adaptive) 189.28  GiB
Header Size:4.88%   9.24GiB

Looks like size have nothing similar with IO errors.

So question is - when error's like Bad Checksums and IO Errors can hapend?

Look's like no hardware problem's.

All ssd atached to onboard intel sata controler (Motherboard  is Supermicro 
X9SRL-F) 
 

Vitalij Satanivskij wrote:
VS> Same situation hapend yesterday again :( 
VS> 
VS> What's confuse me while trying to understend where I'm wrong
VS> 
VS> 
VS> Firt some info.
VS> 
VS> We have zfs pool  "POOL" and one more zfs on it "POOL/zfs"
VS> 
VS> POOL - have only primarycache enabled "ALL" 
VS> POOL/zfs - have both primay and secondary for "ALL"
VS> 
VS> POOL have compression=lz4
VS> 
VS> POOL/zfs have none
VS> 
VS> 
VS> POOL - have around 9TB data
VS> 
VS> POOL/zfs - have 1TB
VS> 
VS> Secondary cache have configuration - 
VS> 
VS> cache
VS>   gpt/cache0ONLINE   0 0 0
VS>   gpt/cache1ONLINE   0 0 0
VS>   gpt/cache2ONLINE   0 0 0
VS> 
VS> gpt/cache0-2 it's intel sdd SSDSC2BW180A4 180gb 
VS> 
VS> So full real size  for l2 is 540GB (realy 489gb)
VS> 
VS> First question  - data on l2arc will be compressed on not?
VS> 
VS> Second in stats we see 
VS> 
VS> L2 ARC Size: (Adaptive) 2.08TiB
VS> 
VS> eary it was 1.1 1.4 ...
VS> 
VS> So a) how cache can be biger than zfs it self
VS>b) in case it's not compressed (answer for first question) how it an be 
biger than real ssd size?
VS> 
VS> 
VS> one more coment if l2 arc size grove above phisical sizes I se  next stats 
VS> 
VS> kstat.zfs.misc.arcstats.l2_cksum_bad: 50907344
VS> kstat.zfs.misc.arcstats.l2_io_error: 4547377
VS> 
VS> and growing.
VS> 
VS> 
VS> System is r255173 with patch from rr255173
VS> 
VS> 
VS> At last maybe somebody have any ideas what's realy hapend...
VS> 
VS> 
VS> 
VS> 
VS> 
VS> Vitalij Satanivskij wrote:
VS> VS> 
VS> VS> One more question - 
VS> VS> 
VS> VS> we have two counter - 
VS> VS> 
VS> VS> kstat.zfs.misc.arcstats.l2_size: 1256609410560
VS> VS> kstat.zfs.misc.arcstats.l2_asize: 1149007667712
VS> VS> 
VS> VS> can anybody explain how to understand them i.e.  l2_asize - real used 
space on l2arc an l2_size - uncompressed size,
VS> VS> 
VS> VS> or maybe something else ?
VS> VS> 
VS> VS> 
VS> VS> 
VS> VS> Vitalij Satanivskij wrote:
VS> VS> VS> 
VS> VS> VS> Data on pool have compressratio around 1.4 
VS> VS> VS> 
VS> VS> VS> On diferent servers with same data type and load L2 ARC Size: 
(Adaptive) can be diferent 
VS> VS> VS> 
VS> VS> VS> for example 1.04TiB vs  1.45TiB
VS> VS> VS> 
VS> VS> VS> But it's all have same porblem  - grow in time.
VS> VS> VS> 
VS> VS> VS> 
VS> VS> VS> More stange for us - 
VS> VS> VS> 
VS> VS> VS> ARC: 80G Total, 4412M MFU, 5040M MRU, 76M Anon, 78G Header, 2195M 
Other
VS> VS> VS> 
VS> VS> VS> 78G header size and ubnormal - 
VS> VS> VS> 
VS> VS> VS> kstat.zfs.misc.arcstats.l2_cksum_bad: 210920592
VS> VS> VS> kstat.zfs.misc.arcstats.l2_io_error: 7362414
VS> VS> VS> 
VS> VS> VS> sysctl's growing avery second.
VS> VS> VS> 
VS> VS> VS> All part's of server (as hardware part's) in in normal state.
VS> VS> VS> 
VS> VS> VS> After reboot no problem's for some period untile cache size grow to 
some limit.
VS> VS> VS> 
VS> VS> VS> 
VS> VS> VS> 
VS> VS> VS> Mark Felder wrote:
VS> VS> VS> MF> On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote:
VS> VS> VS> MF> > 
VS> VS> VS> MF> > How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total 
physical size
VS> VS> VS> MF> > of L2ARC devices 490GB?
VS> VS> VS> MF> > 
VS> VS> VS> MF> 
VS> VS> VS> MF> http://svnweb.freebsd.org/base?view=revision&revision=251478
VS> VS> VS> MF> 
VS> VS> VS> MF> L2ARC compression perhaps?
VS> VS> VS> MF> ___
VS> VS> VS> MF> freebsd-current@freebsd.org mailing list
VS> VS> VS> MF> http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS> VS> VS> MF> To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"
VS> VS> VS> _

Re: rcs

[C. P. Ghost]

On Tue, Oct 8, 2013 at 4:31 AM, Lyndon Nerenberg  wrote:

> Okay folks, can we make a call about keeping the RCS tools in the base?
>
> The proponents wanting to remove RCS need to speak up and make their
> technical case.
>

Still using RCS here and there, esp. managing /etc. Having to install
it separately on machines that are not or seldom connected would be a
pain.

On a more general note: *if* you absolutely have to kill functionality
and move it into ports, please do create a ports/freebsd category, and
move to it stuff like net/freebsd-uucp etc... This way, all code that was
previously in /usr/src would be availabel at one place.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: BE Loader Menu (was Re: rcs)

[Kris Moore]

On 10/10/2013 00:47, Thomas Mueller wrote:
> Sorry for previous typo in From: line, missing right angle bracket at end.
> Then, in a finger error, I resent that message just before finding the error 
> and making the needed correction.
>
> from Devin Teske:
>
>> I'm late to the party again ;D (didn't realize the rcs thread had turned BE)
>> Both problems can be solved.
>> The loading of the kernel *after* choosing your boot device is trivial.
>> We've been doing it at $work for *years* (almost a decade?)
>> I can put that in, whenever. Probably at the same time as implementing
>> the live/dynamic BE menus for selecting the root device.
> I'd like to know how to boot FreeBSD >= 9.1 with grub2.
>
> Following the instructions under $PORTSDIR/sysutils/grub2
>
> insmod ufs2
> set root=(hd0,gpt3)
> kfreebsd /boot/loader
> boot
>
> stopped working around FreeBSD 9.1-stable.
>
> I used Super Grub2 Disk image on the System Rescue CD written to USB stick.
>
> Recently, I built sysutils/grub2, ran mkrescue, wrote that image to the 
> System Rescue USB stick and made the entry in /syslinux/syslinux.cfg, but 
> haven't tested that yet.
>
> What is the method you or PC-BSD uses?
>
> I want to use it on FreeBSD 9.2 and 10-current.
>
> I tried visiting pcbsd.org website but couldn't find any details.
>
> Tom
>
> ___
> 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"

We use the same port, but have some custom grub.d/ scripts which builds
our /boot/grub/grub.cfg files.

https://github.com/pcbsd/pcbsd/tree/master/src-sh/pc-extractoverlay/ports-overlay/usr/local/etc/grub.d

The scripts do basic stuff like parsing output of "beadm" and creating a
list of Boot-Environment menus to build. Along with parsing
/boot/loader.conf, /boot/device.hints and friends. Lastly it even has
code to mount each of your BEs and copy the resulting grub.cfg file into
each, so that you have a unified menu regardless of which BE you are
currently booting.

One thing that I really want to fix is detecting which kernel modules
have what depends. Currently I have to ensure that /boot/loader.conf has
both the target module + depends in order for GRUB to load them properly.

If anybody wants to help hack on these and make them more "FreeBSD
generic" I think it could eventually go into the ports tree for everybody.

When grub-mkconfig is run, it generates a ZFS / BE specific boot-script,
with entries that look like this:


---

submenu "PC-BSD (default) - 2013-08-27 14:23" {
  menuentry "Normal Bootup" {
insmod zfs
search -s -l tank1
kfreebsd /ROOT/default/@/boot/kernel/kernel
kfreebsd_module /ROOT/default/@/boot/zfs/zpool.cache
type=/boot/zfs/zpool.cache
set kFreeBSD.vfs.root.mountfrom=zfs:tank1/ROOT/default
kfreebsd_module_elf /ROOT/default/@/boot/kernel/siis.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/sdhci.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_journal.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_mirror.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/geom_eli.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/aesni.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/zfs.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/tmpfs.ko
kfreebsd_module_elf /ROOT/default/@/boot/modules/nvidia.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/dummynet.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/ipfw_nat.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/ipdivert.ko
kfreebsd_module_elf /ROOT/default/@/boot/modules/vboxdrv.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/zlib.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/opensolaris.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/linux.ko
kfreebsd_module_elf /ROOT/default/@/boot/kernel/crypto.ko
set kFreeBSD.hint.fdc.0.at=isa
set kFreeBSD.hint.fdc.0.port=0x3F0
set kFreeBSD.hint.fdc.0.irq=6
set kFreeBSD.hint.fdc.0.drq=2
set kFreeBSD.hint.fd.0.at=fdc0
set kFreeBSD.hint.fd.0.drive=0
set kFreeBSD.hint.fd.1.at=fdc0
set kFreeBSD.hint.fd.1.drive=1
set kFreeBSD.hint.atkbdc.0.at=isa
set kFreeBSD.hint.atkbdc.0.port=0x060
set kFreeBSD.hint.atkbd.0.at=atkbdc
set kFreeBSD.hint.atkbd.0.irq=1
set kFreeBSD.hint.psm.0.at=atkbdc
set kFreeBSD.hint.psm.0.irq=12
set kFreeBSD.hint.sc.0.at=isa
set kFreeBSD.hint.sc.0.flags=0x100
set kFreeBSD.hint.uart.0.at=isa
set kFreeBSD.hint.uart.0.port=0x3F8
set kFreeBSD.hint.uart.0.flags=0x10
set kFreeBSD.hint.uart.0.irq=4
set kFreeBSD.hint.uart.1.at=isa
set kFreeBSD.hint.uart.1.port=0x2F8
set kFreeBSD.hint.uart.1.irq=3
set kFreeBSD.hint.ppc.0.at=isa
set kFreeBSD.hint.ppc.0.irq=7
set kFreeBSD.hint.atrtc.0.at=isa
set kFreeBS

FreeBSD 10 and zfsd

[Johan Hendriks]

When i started using ZFS on FreeBSD I quickly found out that hot spares 
are not possible on FreeBSD.
I was told that with zfsd it should be possible and that it would be 
included in FreeBSD 10.


Is there some info about the zfsd function and how it could be used?

regards
Johan Hendriks

___
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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Nathan Whitehorn]

On 10/10/13 09:20, Allan Jude wrote:
> On 2013-10-10 03:00, Nathan Whitehorn wrote:
>> On 10/09/13 18:55, Teske, Devin wrote:
>>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>>>
 On 10/09/13 01:13, Allan Jude wrote:
> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>> On 10/07/13 21:59, Allan Jude wrote:
>>> Devin Teske and I have been working on a big patch to bsdinstall to
>>> implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
>>> sector gnop trick, and optional GELI encryption. We would like to commit
>>> this in time for 10.0-BETA1 so it needs some testing to work out any
>>> obvious bugs before we send it off to re@ to get it committed.
>>>
>>> It includes a single configuration menu that allows you to select all of
>>> the required details, including which drives to use (gets details from
>>> camcontrol, also includes an inspection utility that presents the
>>> detailed output of camcontrol inquiry/identify, and gpart show), what
>>> ZFS RAID level to use (taking in to consideration the selected number of
>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>>>
>>>
>>> Additional, it includes some other changes to bsdinstall:
>>> 1. Change the default to the 'non-standard keyboard mapping' prompt to 
>>> no
>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
>>> just 1
>>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>>> feature has been combined into the regular 'services to enable' dialog
>>> and enabled by default
>>>
>>>
>>> You can browse the patches here:
>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>>>
>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>>> available compressed (48 MB) or uncompressed (211 MB):
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>>>
>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>>>
>>>
>>> We look forward to your feedback
>>>
>> Thanks for doing this! I had a few comments:
>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>> -m, not -p, for this.
> I had not considered that, I'll make that change
>
>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>> instead of GPT.
> I'll disable sparc64 as well
>
>> 2. Why are you using camcontrol? That is guaranteed not to work on
>> non-CAM systems. You should use the GEOM ident string if you need an ID.
> The GEOM ident string doesn't do enough to help the user identify which
> drive is which.
> More data is not exposed anywhere that I could find
>
> What we really need, is dev.ada.0.desc% like we have for network
> interfaces and a slew of other devices. GEOM data is great, but it is
> not exposed in a shell friendly way any place that I could find, other
> than the sysctl with DOT and XML data.
 This is one of the reasons the partition editor is written in C. There
 are a few other odd corner-cases where C is much more powerful than the
 command-line for the GEOM operations that partedit needs to do. I'm not
 sure how to usefully get it just from the shell. You can see how to do
 it in C in the boot_disk() routine of partedit/auto_part.c.

>> 3. Any plans to integrate this into the regular partition editor? ZFS
>> support is important enough that I will definitely not get in the way,
>> even as a bolt-on, but it would be a shame for it to stay that way. The
>> editor is also designed for ZFS to be added.
> I am a sysadmin, not a programmer. I can't write C. Most people
> deploying servers can't write C. I agree with Devin Teske, if everything
> was in shell it would be a lot more usable for non-developers, who
> probably make up the majority of people who deploy FreeBSD.
 There are some cases the other way too. Devin is probably the most
 shell-proficient FreeBSD committer.
>>> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
>>> itself).
>>>
>>>
 I certainly can't write shell
 scripts at that level, which means that for me bsdconfig, for example,
 is effectively read-only (and quite hard to read as well).
>>> In the past few days of working on the bsdinstall_zfs patch-set with Allan
>>> Jude, I learned something new actually.
>>>
>>> It seems that sh(1) doesn't suffer so much from this "read only" concept.
>>>
>>> Imagine you're starting a new C project on an operating system that has
>>> all new syscalls and all new APIs that you've never seen. Would be pretty
>>> hard, no doubt. Now imagine that you're thrown a life-line called POSIX
>>> and hey, now you're slinging code in MinGW on Windows when you don't
>>> know a lick of M$ 

Re: FreeBSD 10 and zfsd

[Alan Somers]

On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks  wrote:
> When i started using ZFS on FreeBSD I quickly found out that hot spares are
> not possible on FreeBSD.
> I was told that with zfsd it should be possible and that it would be
> included in FreeBSD 10.
>
> Is there some info about the zfsd function and how it could be used?

zfsd is currently not in FreeBSD/head and won't make it into 10, but
you can still get the source code from its project branch.  It's being
used in production by at least two companies.

http://svnweb.freebsd.org/base/projects/zfsd/head/

>
> regards
> Johan Hendriks
>
> ___
> 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"
___
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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Teske, Devin]

On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:

> On 10/10/13 09:20, Allan Jude wrote:
>> On 2013-10-10 03:00, Nathan Whitehorn wrote:
>>> On 10/09/13 18:55, Teske, Devin wrote:
 On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
 
> On 10/09/13 01:13, Allan Jude wrote:
>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
>>> On 10/07/13 21:59, Allan Jude wrote:
 Devin Teske and I have been working on a big patch to bsdinstall to
 implement installing on a ZFS pool. It supports both GPT and MBR, the 
 4k
 sector gnop trick, and optional GELI encryption. We would like to 
 commit
 this in time for 10.0-BETA1 so it needs some testing to work out any
 obvious bugs before we send it off to re@ to get it committed.
 
 It includes a single configuration menu that allows you to select all 
 of
 the required details, including which drives to use (gets details from
 camcontrol, also includes an inspection utility that presents the
 detailed output of camcontrol inquiry/identify, and gpart show), what
 ZFS RAID level to use (taking in to consideration the selected number 
 of
 drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
 
 
 Additional, it includes some other changes to bsdinstall:
 1. Change the default to the 'non-standard keyboard mapping' prompt to 
 no
 2. Replace the 3 separate dialogs to configure an ipv4 address with 
 just 1
 3. Remove the dialog asking if you wish to enable crash dumps, this
 feature has been combined into the regular 'services to enable' dialog
 and enabled by default
 
 
 You can browse the patches here:
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
 
 I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
 available compressed (48 MB) or uncompressed (211 MB):
 
 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
 
 http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
 
 
 We look forward to your feedback
 
>>> Thanks for doing this! I had a few comments:
>>> 1. ZFS is not bootable on all architectures. Could you adjust that menu
>>> item to only display for i386, amd64, and (I think?) sparc64. Use uname
>>> -m, not -p, for this.
>> I had not considered that, I'll make that change
>> 
>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8
>>> instead of GPT.
>> I'll disable sparc64 as well
>> 
>>> 2. Why are you using camcontrol? That is guaranteed not to work on
>>> non-CAM systems. You should use the GEOM ident string if you need an ID.
>> The GEOM ident string doesn't do enough to help the user identify which
>> drive is which.
>> More data is not exposed anywhere that I could find
>> 
>> What we really need, is dev.ada.0.desc% like we have for network
>> interfaces and a slew of other devices. GEOM data is great, but it is
>> not exposed in a shell friendly way any place that I could find, other
>> than the sysctl with DOT and XML data.
> This is one of the reasons the partition editor is written in C. There
> are a few other odd corner-cases where C is much more powerful than the
> command-line for the GEOM operations that partedit needs to do. I'm not
> sure how to usefully get it just from the shell. You can see how to do
> it in C in the boot_disk() routine of partedit/auto_part.c.
> 
>>> 3. Any plans to integrate this into the regular partition editor? ZFS
>>> support is important enough that I will definitely not get in the way,
>>> even as a bolt-on, but it would be a shame for it to stay that way. The
>>> editor is also designed for ZFS to be added.
>> I am a sysadmin, not a programmer. I can't write C. Most people
>> deploying servers can't write C. I agree with Devin Teske, if everything
>> was in shell it would be a lot more usable for non-developers, who
>> probably make up the majority of people who deploy FreeBSD.
> There are some cases the other way too. Devin is probably the most
> shell-proficient FreeBSD committer.
 Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
 itself).
 
 
> I certainly can't write shell
> scripts at that level, which means that for me bsdconfig, for example,
> is effectively read-only (and quite hard to read as well).
 In the past few days of working on the bsdinstall_zfs patch-set with Allan
 Jude, I learned something new actually.
 
 It seems that sh(1) doesn't suffer so much from this "read only" concept.
 
 Imagine you're starting a new C project on an operating system that has
 all new syscalls and all new APIs 

Re: FreeBSD 10 and zfsd

[Outback Dingo]

On Thu, Oct 10, 2013 at 11:24 AM, Alan Somers  wrote:

> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
> wrote:
> > When i started using ZFS on FreeBSD I quickly found out that hot spares
> are
> > not possible on FreeBSD.
> > I was told that with zfsd it should be possible and that it would be
> > included in FreeBSD 10.
> >
> > Is there some info about the zfsd function and how it could be used?
>
> zfsd is currently not in FreeBSD/head and won't make it into 10, but
> you can still get the source code from its project branch.  It's being
> used in production by at least two companies.
>
> http://svnweb.freebsd.org/base/projects/zfsd/head/
>
>
might be easier to just cut a diff of it, as it 2+ months behind CURRENT as
it is in this branch, be
nice to review and do some testing on, but getting a diff from that to
CURRENT might prove a bit difficult
unless the branch was updated


> >
> > regards
> > Johan Hendriks
> >
> > ___
> > 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"
> ___
> 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"
>
___
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: BE Loader Menu (was Re: rcs)

[Julian Elischer]

On 10/10/13 1:05 AM, Teske, Devin wrote:


I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.


yeah it always pisses me of when the menu comes up after the kernel is 
loaded because 99% of the time, I'm in the menu because I want to boot 
a DIFFERENT kernel..








___
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: rcs

[Julian Elischer]

On 10/9/13 11:59 PM, Jos Backus wrote:

On Oct 9, 2013 5:39 AM, "Kimmo Paasiala"  wrote:

On Wed, Oct 9, 2013 at 2:03 PM, George Mitchell 

wrote:

On 10/09/13 03:20, Hans Ottevanger wrote:

On 10/08/13 04:31, Lyndon Nerenberg wrote:

Okay folks, can we make a call about keeping the RCS tools in the

base?

The proponents wanting to remove RCS need to speak up and make their
technical case.


Technically it is quite simple: I need RCS to start versioning config
files, even before starting any customization. I know about several
others who do the same (and have not yet defected to Linux).

I would like to see RCS to be put back into the tree for 10.0. If it
really -has- to be victimized by the current anti-GPL crusade, it could
be replaced by OpenRCS in 11.

And as a long time hard-core user I would appreciate if this kind of
changes were  performed only after at least -some- public discussion.
The way this change was sneaked in (though apparently with approval of
core@),  reminds me more of a Secret Society than of an Open Source
project.

Regards,

Hans

___
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"

+1, enthusiastically. -- George


+1 also to OpenRCS allthough I hate anything related to RCS/CVS with a
passion. I do however recognize the need for a simple revision control
system in the base, svnlite would fill the need maybe but it's good to
have other options too.

-Kimmo

OK, but please, can we replace RCS with Fossil in 11 then? That adds a real
improvement to FreeBSD while giving people plenty of time to prepare.

can fossil read rcs files? and how big is it compared to RCS?


Jos
___
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"




___
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 10 and zfsd

[Mark Felder]

On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
> wrote:
> > When i started using ZFS on FreeBSD I quickly found out that hot spares are
> > not possible on FreeBSD.
> > I was told that with zfsd it should be possible and that it would be
> > included in FreeBSD 10.
> >
> > Is there some info about the zfsd function and how it could be used?
> 
> zfsd is currently not in FreeBSD/head and won't make it into 10, but
> you can still get the source code from its project branch.  It's being
> used in production by at least two companies.
> 

So FreeBSD is going to have inferior ZFS management compared to
Solaris/Illumos/etc for another 2+ years? Why are things like this
allowed to miss releases?
___
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: rcs

[Julian Elischer]

On 10/11/13 12:34 AM, Jos Backus wrote:
On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer > wrote:


On 10/9/13 11:59 PM, Jos Backus wrote:

[snip]

OK, but please, can we replace RCS with Fossil in 11 then?
That adds a real
improvement to FreeBSD while giving people plenty of time to
prepare.

can fossil read rcs files? and how big is it compared to RCS?


It seems there's some thought on importing CVS repos but according 
to 'fossil help import', only the git fast-export format is supported.
In practice this means you'd loose history, yes. But it's not hard 
to keep the old RCS files somewhere else in case that history is needed.


http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories

I just built devel/fossil and it yields a single binary, 
/usr/local/bin/fossil which clocks in at 1.8M. Given all the 
functionality it provides (plus it is in a similar class as git, see 
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), 
I think that's a steal.


It was started by the author of SQlite. If we require some kind of 
version control system in the base that's powerful, well-maintained 
and BSD-licensed, this really seems like a no-brainer.


well since people expect RCS.. it is not a no brainer.
you are asking people to learn  a whole new tool  for functionality 
that is currently very simple..

edit file
ci -l file
add comment.




Jos
--
Jos Backus
jos at catnook.com 


___
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: BE Loader Menu (was Re: rcs)

[Teske, Devin]

On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:

> On 10/10/13 1:05 AM, Teske, Devin wrote:
>> 
>> I'm late to the party again ;D (didn't realize the rcs thread had turned BE)
>> 
>> Both problems can be solved.
>> The loading of the kernel *after* choosing your boot device is trivial.
>> We've been doing it at $work for *years* (almost a decade?)
>> 
>> I can put that in, whenever. Probably at the same time as implementing
>> the live/dynamic BE menus for selecting the root device.
> 
> yeah it always pisses me of when the menu comes up after the kernel is loaded 
> because 99% of the time, I'm in the menu because I want to boot a DIFFERENT 
> kernel..
> 

Same thought I had about 7 years ago. After hearing that others
(especially you, Julian) think the same thoughts...

I'm happily ready to merge a patch from VICOR to achieve this.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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: BE Loader Menu (was Re: rcs)

[Julian Elischer]

On 10/11/13 12:39 AM, Teske, Devin wrote:

On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote:


On 10/10/13 1:05 AM, Teske, Devin wrote:

I'm late to the party again ;D (didn't realize the rcs thread had turned BE)

Both problems can be solved.
The loading of the kernel *after* choosing your boot device is trivial.
We've been doing it at $work for *years* (almost a decade?)

I can put that in, whenever. Probably at the same time as implementing
the live/dynamic BE menus for selecting the root device.

yeah it always pisses me of when the menu comes up after the kernel is loaded 
because 99% of the time, I'm in the menu because I want to boot a DIFFERENT 
kernel..


Same thought I had about 7 years ago. After hearing that others
(especially you, Julian) think the same thoughts...

I'm happily ready to merge a patch from VICOR to achieve this.

PLEASE!..   put it up for review somewhere...

I wonder if we can we get a reviewboard instance for the project some 
time?


___
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: ZFS L2ARC - incorrect size and abnormal system load on r255173

[Allan Jude]

On 2013-10-10 05:22, Vitalij Satanivskij wrote:
> Same situation hapend yesterday again :( 
>
> What's confuse me while trying to understend where I'm wrong
>
>
> Firt some info.
>
> We have zfs pool  "POOL" and one more zfs on it "POOL/zfs"
>
> POOL - have only primarycache enabled "ALL" 
> POOL/zfs - have both primay and secondary for "ALL"
>
> POOL have compression=lz4
>
> POOL/zfs have none
>
>
> POOL - have around 9TB data
>
> POOL/zfs - have 1TB
>
> Secondary cache have configuration - 
>
> cache
>   gpt/cache0ONLINE   0 0 0
>   gpt/cache1ONLINE   0 0 0
>   gpt/cache2ONLINE   0 0 0
>
> gpt/cache0-2 it's intel sdd SSDSC2BW180A4 180gb 
>
> So full real size  for l2 is 540GB (realy 489gb)
>
> First question  - data on l2arc will be compressed on not?
>
> Second in stats we see 
>
> L2 ARC Size: (Adaptive) 2.08TiB
>
> eary it was 1.1 1.4 ...
>
> So a) how cache can be biger than zfs it self
>b) in case it's not compressed (answer for first question) how it an be 
> biger than real ssd size?
>
>
> one more coment if l2 arc size grove above phisical sizes I se  next stats 
>
> kstat.zfs.misc.arcstats.l2_cksum_bad: 50907344
> kstat.zfs.misc.arcstats.l2_io_error: 4547377
>
> and growing.
>
>
> System is r255173 with patch from rr255173
>
>
> At last maybe somebody have any ideas what's realy hapend...
>
>
>
>
>
> Vitalij Satanivskij wrote:
> VS> 
> VS> One more question - 
> VS> 
> VS> we have two counter - 
> VS> 
> VS> kstat.zfs.misc.arcstats.l2_size: 1256609410560
> VS> kstat.zfs.misc.arcstats.l2_asize: 1149007667712
> VS> 
> VS> can anybody explain how to understand them i.e.  l2_asize - real used 
> space on l2arc an l2_size - uncompressed size,
> VS> 
> VS> or maybe something else ?
> VS> 
> VS> 
> VS> 
> VS> Vitalij Satanivskij wrote:
> VS> VS> 
> VS> VS> Data on pool have compressratio around 1.4 
> VS> VS> 
> VS> VS> On diferent servers with same data type and load L2 ARC Size: 
> (Adaptive) can be diferent 
> VS> VS> 
> VS> VS> for example 1.04TiB vs  1.45TiB
> VS> VS> 
> VS> VS> But it's all have same porblem  - grow in time.
> VS> VS> 
> VS> VS> 
> VS> VS> More stange for us - 
> VS> VS> 
> VS> VS> ARC: 80G Total, 4412M MFU, 5040M MRU, 76M Anon, 78G Header, 2195M 
> Other
> VS> VS> 
> VS> VS> 78G header size and ubnormal - 
> VS> VS> 
> VS> VS> kstat.zfs.misc.arcstats.l2_cksum_bad: 210920592
> VS> VS> kstat.zfs.misc.arcstats.l2_io_error: 7362414
> VS> VS> 
> VS> VS> sysctl's growing avery second.
> VS> VS> 
> VS> VS> All part's of server (as hardware part's) in in normal state.
> VS> VS> 
> VS> VS> After reboot no problem's for some period untile cache size grow to 
> some limit.
> VS> VS> 
> VS> VS> 
> VS> VS> 
> VS> VS> Mark Felder wrote:
> VS> VS> MF> On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote:
> VS> VS> MF> > 
> VS> VS> MF> > How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total 
> physical size
> VS> VS> MF> > of L2ARC devices 490GB?
> VS> VS> MF> > 
> VS> VS> MF> 
> VS> VS> MF> http://svnweb.freebsd.org/base?view=revision&revision=251478
> VS> VS> MF> 
> VS> VS> MF> L2ARC compression perhaps?
> VS> VS> MF> ___
> VS> VS> MF> freebsd-current@freebsd.org mailing list
> VS> VS> MF> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> VS> VS> MF> To unsubscribe, send any mail to 
> "freebsd-current-unsubscr...@freebsd.org"
> VS> VS> ___
> VS> VS> freebsd-current@freebsd.org mailing list
> VS> VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> VS> VS> To unsubscribe, send any mail to 
> "freebsd-current-unsubscr...@freebsd.org"
> VS> ___
> VS> freebsd-current@freebsd.org mailing list
> VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> VS> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> 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"
Some background on L2ARC compression for you:

http://wiki.illumos.org/display/illumos/L2ARC+Compression

http://svnweb.freebsd.org/base?view=revision&revision=251478

Are you sure that compression on pool/zfs is off? it would normally
inherit from the parent, so double check with: zfs get compression pool/zfs

Is the data on pool/zfs related to the data on the root pool? if
pool/zfs were a clone, and the data is actually used in both places, the
newer 'single copy ARC' feature may come in to play:
https://www.illumos.org/issues/3145




-- 
Allan Jude

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.

Re: rcs

[Jos Backus]

On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer  wrote:

> On 10/9/13 11:59 PM, Jos Backus wrote:

[snip]

> OK, but please, can we replace RCS with Fossil in 11 then? That adds a real
>> improvement to FreeBSD while giving people plenty of time to prepare.
>>
> can fossil read rcs files? and how big is it compared to RCS?
>
>>
It seems there's some thought on importing CVS repos but according to
'fossil help import', only the git fast-export format is supported.
In practice this means you'd loose history, yes. But it's not hard to keep
the old RCS files somewhere else in case that history is needed.

http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories

I just built devel/fossil and it yields a single binary,
/usr/local/bin/fossil which clocks in at 1.8M. Given all the functionality
it provides (plus it is in a similar class as git, see
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), I
think that's a steal.

It was started by the author of SQlite. If we require some kind of version
control system in the base that's powerful, well-maintained and
BSD-licensed, this really seems like a no-brainer.

Jos
-- 
Jos Backus
jos at catnook.com
___
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: ZFS L2ARC - incorrect size and abnormal system load on r255173

[Vitalij Satanivskij]

AJ> Some background on L2ARC compression for you:
AJ> 
AJ> http://wiki.illumos.org/display/illumos/L2ARC+Compression

I'm alredy see it.


 
AJ> http://svnweb.freebsd.org/base?view=revision&revision=251478
AJ> 
AJ> Are you sure that compression on pool/zfs is off? it would normally
AJ> inherit from the parent, so double check with: zfs get compression pool/zfs

Yes, compression turned off on pool/zfs, it's was may time rechecked.



AJ> Is the data on pool/zfs related to the data on the root pool? if
AJ> pool/zfs were a clone, and the data is actually used in both places, the
AJ> newer 'single copy ARC' feature may come in to play:
AJ> https://www.illumos.org/issues/3145

No, both pool and pool/zfs have diferent type of data, pool/zfs was created as 
new empty zfs (zfs create pool/zfs)

and data was writed to it from another server. 


Right now one machine work fine with l2arc. This machine without patch for 
corecting ashift on cache devices.

At last 3 day's working with zero errors. Another servers with same config 
similar data, load and so on after 2 day 
work began report abouy errors.


AJ> 
AJ> 
AJ> 
AJ> -- 
AJ> Allan Jude
AJ> 
AJ> ___
AJ> freebsd-current@freebsd.org mailing list
AJ> http://lists.freebsd.org/mailman/listinfo/freebsd-current
AJ> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
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"

make universe fails, apparently in lib/clang/include (all)

[Eric van Gyzen]

"make universe" is consistently failing in the following way. 
"_.amd64.amd64.buildworld" contains:



===> lib/clang/libllvmx86desc (all)
===> lib/clang/libllvmx86disassembler (all)
===> lib/clang/libllvmx86info (all)
===> lib/clang/libllvmx86instprinter (all)
===> lib/clang/libllvmx86utils (all)
===> lib/clang/include (all)
1 error

make[3]: stopped in /home/freebsd
*** [everything] Error code 2

make[2]: stopped in /home/freebsd
1 error

make[2]: stopped in /home/freebsd
*** [buildworld] Error code 2

make[1]: stopped in /home/freebsd
1 error

make[1]: stopped in /home/freebsd



I'm running it from bash with:

nice -n 20 make JFLAG=-j4 MAKEOBJDIRPREFIX=/home/obj universe >
/tmp/universe.log 2>&1 < /dev/null &

"/tmp/universe.log" contains:

--
>>> make universe started on Thu Oct 10 07:59:02 CDT 2013
--
>> amd64 started on Thu Oct 10 07:59:02 CDT 2013
>> amd64.amd64 buildworld started on Thu Oct 10 07:59:02 CDT 2013
amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details

/home/freebsd is a git repo, cloned from github, tracking the master
branch, at commit 0b5457bf, corresponding to Subversion head r256251.  I
have no local changes.

Am I doing something wrong?  Is this working for everyone else?

Thanks in advance,

Eric

-- 
*Eric van Gyzen*
Senior Software Development Engineer
*Dell* | Compellent
*office* +1 952 562 3197
Cube J-732, 7615 Smetana Lane
Eden Prairie, MN 55344
eric_van_gy...@dell.com 
___
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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Allan Jude]

On 2013-10-10 11:30, Teske, Devin wrote:
> On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:
>
>> On 10/10/13 09:20, Allan Jude wrote:
>>> On 2013-10-10 03:00, Nathan Whitehorn wrote:
 On 10/09/13 18:55, Teske, Devin wrote:
> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>
>> On 10/09/13 01:13, Allan Jude wrote:
>>> On 2013-10-08 16:17, Nathan Whitehorn wrote:
 On 10/07/13 21:59, Allan Jude wrote:
> Devin Teske and I have been working on a big patch to bsdinstall to
> implement installing on a ZFS pool. It supports both GPT and MBR, the 
> 4k
> sector gnop trick, and optional GELI encryption. We would like to 
> commit
> this in time for 10.0-BETA1 so it needs some testing to work out any
> obvious bugs before we send it off to re@ to get it committed.
>
> It includes a single configuration menu that allows you to select all 
> of
> the required details, including which drives to use (gets details from
> camcontrol, also includes an inspection utility that presents the
> detailed output of camcontrol inquiry/identify, and gpart show), what
> ZFS RAID level to use (taking in to consideration the selected number 
> of
> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>
>
> Additional, it includes some other changes to bsdinstall:
> 1. Change the default to the 'non-standard keyboard mapping' prompt 
> to no
> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
> just 1
> 3. Remove the dialog asking if you wish to enable crash dumps, this
> feature has been combined into the regular 'services to enable' dialog
> and enabled by default
>
>
> You can browse the patches here:
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
>
> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
> available compressed (48 MB) or uncompressed (211 MB):
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz
>
> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso
>
>
> We look forward to your feedback
>
 Thanks for doing this! I had a few comments:
 1. ZFS is not bootable on all architectures. Could you adjust that menu
 item to only display for i386, amd64, and (I think?) sparc64. Use uname
 -m, not -p, for this.
>>> I had not considered that, I'll make that change
>>>
 1a. The script is broken on sparc64 in any case, which uses VTOC8
 instead of GPT.
>>> I'll disable sparc64 as well
>>>
 2. Why are you using camcontrol? That is guaranteed not to work on
 non-CAM systems. You should use the GEOM ident string if you need an 
 ID.
>>> The GEOM ident string doesn't do enough to help the user identify which
>>> drive is which.
>>> More data is not exposed anywhere that I could find
>>>
>>> What we really need, is dev.ada.0.desc% like we have for network
>>> interfaces and a slew of other devices. GEOM data is great, but it is
>>> not exposed in a shell friendly way any place that I could find, other
>>> than the sysctl with DOT and XML data.
>> This is one of the reasons the partition editor is written in C. There
>> are a few other odd corner-cases where C is much more powerful than the
>> command-line for the GEOM operations that partedit needs to do. I'm not
>> sure how to usefully get it just from the shell. You can see how to do
>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>
 3. Any plans to integrate this into the regular partition editor? ZFS
 support is important enough that I will definitely not get in the way,
 even as a bolt-on, but it would be a shame for it to stay that way. The
 editor is also designed for ZFS to be added.
>>> I am a sysadmin, not a programmer. I can't write C. Most people
>>> deploying servers can't write C. I agree with Devin Teske, if everything
>>> was in shell it would be a lot more usable for non-developers, who
>>> probably make up the majority of people who deploy FreeBSD.
>> There are some cases the other way too. Devin is probably the most
>> shell-proficient FreeBSD committer.
> Well, there's jilles ;D (he writes/maintains the sh(1) implementation 
> itself).
>
>
>> I certainly can't write shell
>> scripts at that level, which means that for me bsdconfig, for example,
>> is effectively read-only (and quite hard to read as well).
> In the past few days of working on the bsdinstall_zfs patch-set with Allan
> Jude, I learned something new actually.
>
> It seems that sh(1) doesn't suffer so much from this "read only" c

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Teske, Devin]

On Oct 10, 2013, at 10:18 AM, Allan Jude wrote:

> On 2013-10-10 11:30, Teske, Devin wrote:
>> On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote:
>> 
>>> On 10/10/13 09:20, Allan Jude wrote:
 On 2013-10-10 03:00, Nathan Whitehorn wrote:
> On 10/09/13 18:55, Teske, Devin wrote:
>> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote:
>> 
>>> On 10/09/13 01:13, Allan Jude wrote:
 On 2013-10-08 16:17, Nathan Whitehorn wrote:
> On 10/07/13 21:59, Allan Jude wrote:
>> Devin Teske and I have been working on a big patch to bsdinstall to
>> implement installing on a ZFS pool. It supports both GPT and MBR, 
>> the 4k
>> sector gnop trick, and optional GELI encryption. We would like to 
>> commit
>> this in time for 10.0-BETA1 so it needs some testing to work out any
>> obvious bugs before we send it off to re@ to get it committed.
>> 
>> It includes a single configuration menu that allows you to select 
>> all of
>> the required details, including which drives to use (gets details 
>> from
>> camcontrol, also includes an inspection utility that presents the
>> detailed output of camcontrol inquiry/identify, and gpart show), what
>> ZFS RAID level to use (taking in to consideration the selected 
>> number of
>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.
>> 
>> 
>> Additional, it includes some other changes to bsdinstall:
>> 1. Change the default to the 'non-standard keyboard mapping' prompt 
>> to no
>> 2. Replace the 3 separate dialogs to configure an ipv4 address with 
>> just 1
>> 3. Remove the dialog asking if you wish to enable crash dumps, this
>> feature has been combined into the regular 'services to enable' 
>> dialog
>> and enabled by default
>> 
>> 
>> You can browse the patches here:
>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=6361ad5ccc04a6d8401158a3ee1b3d8df9fcd2ef47ff6ad6365a57b907cceaec
>> 
>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
>> available compressed (48 MB) or uncompressed (211 MB):
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=570daea25d9e629788c76c2b5a6eae19d32050363986a1004a6434c3466965c2
>> 
>> https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=ckXs2H5TEcKdiN%2F9l%2FClInsMys9LmTwEbElzzrBchMU%3D%0A&s=f52d604a2503a48b409f92f8376bb773de4dbc469d1e74b16d051a20ad894820
>> 
>> 
>> We look forward to your feedback
>> 
> Thanks for doing this! I had a few comments:
> 1. ZFS is not bootable on all architectures. Could you adjust that 
> menu
> item to only display for i386, amd64, and (I think?) sparc64. Use 
> uname
> -m, not -p, for this.
 I had not considered that, I'll make that change
 
> 1a. The script is broken on sparc64 in any case, which uses VTOC8
> instead of GPT.
 I'll disable sparc64 as well
 
> 2. Why are you using camcontrol? That is guaranteed not to work on
> non-CAM systems. You should use the GEOM ident string if you need an 
> ID.
 The GEOM ident string doesn't do enough to help the user identify which
 drive is which.
 More data is not exposed anywhere that I could find
 
 What we really need, is dev.ada.0.desc% like we have for network
 interfaces and a slew of other devices. GEOM data is great, but it is
 not exposed in a shell friendly way any place that I could find, other
 than the sysctl with DOT and XML data.
>>> This is one of the reasons the partition editor is written in C. There
>>> are a few other odd corner-cases where C is much more powerful than the
>>> command-line for the GEOM operations that partedit needs to do. I'm not
>>> sure how to usefully get it just from the shell. You can see how to do
>>> it in C in the boot_disk() routine of partedit/auto_part.c.
>>> 
> 3. Any plans to integrate this into the regular partition editor? ZFS
> support is important enough that I will definitely not get in the way,
> even as a bolt-on, but it would be a shame for it to stay t

Re: FreeBSD 10 and zfsd

[Allan Jude]

On 2013-10-10 12:13, Mark Felder wrote:
> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
>> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
>> wrote:
>>> When i started using ZFS on FreeBSD I quickly found out that hot spares are
>>> not possible on FreeBSD.
>>> I was told that with zfsd it should be possible and that it would be
>>> included in FreeBSD 10.
>>>
>>> Is there some info about the zfsd function and how it could be used?
>> zfsd is currently not in FreeBSD/head and won't make it into 10, but
>> you can still get the source code from its project branch.  It's being
>> used in production by at least two companies.
>>
> So FreeBSD is going to have inferior ZFS management compared to
> Solaris/Illumos/etc for another 2+ years? Why are things like this
> allowed to miss releases?
> ___
> 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"
ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3
weeks ago). There is a lot of collaboration going on, to bring in some
work done by vendors like SpectraLogics. This is the type of feature
that can be assed in 10.1, it won't have to wait for 11.

You can see Robert Watsons talk "How FreeBSD Works" to see why releases
are based on date, rather than on feature completion (because things are
never "finished")



-- 
Allan Jude

___
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 10 and zfsd

[Alan Somers]

On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude  wrote:
> On 2013-10-10 12:13, Mark Felder wrote:
>> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
>>> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
>>> wrote:
 When i started using ZFS on FreeBSD I quickly found out that hot spares are
 not possible on FreeBSD.
 I was told that with zfsd it should be possible and that it would be
 included in FreeBSD 10.

 Is there some info about the zfsd function and how it could be used?
>>> zfsd is currently not in FreeBSD/head and won't make it into 10, but
>>> you can still get the source code from its project branch.  It's being
>>> used in production by at least two companies.
>>>
>> So FreeBSD is going to have inferior ZFS management compared to
>> Solaris/Illumos/etc for another 2+ years? Why are things like this
>> allowed to miss releases?
>> ___
>> 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"
> ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3
> weeks ago). There is a lot of collaboration going on, to bring in some
> work done by vendors like SpectraLogics. This is the type of feature
> that can be assed in 10.1, it won't have to wait for 11.
>
> You can see Robert Watsons talk "How FreeBSD Works" to see why releases
> are based on date, rather than on feature completion (because things are
> never "finished")
>
>
>
> --
> Allan Jude
>
> ___
> 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"

Due to popular demand, I have located a round toit.  I'm currently
working on rebasing the zfsd project branch to head, after which I'll
push SpectraLogic's recent changes.
___
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 10 and zfsd

[Allan Jude]

On 2013-10-10 13:26, Alan Somers wrote:
> On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude  wrote:
>> On 2013-10-10 12:13, Mark Felder wrote:
>>> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
 On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
 wrote:
> When i started using ZFS on FreeBSD I quickly found out that hot spares 
> are
> not possible on FreeBSD.
> I was told that with zfsd it should be possible and that it would be
> included in FreeBSD 10.
>
> Is there some info about the zfsd function and how it could be used?
 zfsd is currently not in FreeBSD/head and won't make it into 10, but
 you can still get the source code from its project branch.  It's being
 used in production by at least two companies.

>>> So FreeBSD is going to have inferior ZFS management compared to
>>> Solaris/Illumos/etc for another 2+ years? Why are things like this
>>> allowed to miss releases?
>>> ___
>>> 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"
>> ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3
>> weeks ago). There is a lot of collaboration going on, to bring in some
>> work done by vendors like SpectraLogics. This is the type of feature
>> that can be assed in 10.1, it won't have to wait for 11.
>>
>> You can see Robert Watsons talk "How FreeBSD Works" to see why releases
>> are based on date, rather than on feature completion (because things are
>> never "finished")
>>
>>
>>
>> --
>> Allan Jude
>>
>> ___
>> 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"
> Due to popular demand, I have located a round toit.  I'm currently
> working on rebasing the zfsd project branch to head, after which I'll
> push SpectraLogic's recent changes.
See, all you have to do is complain loudly enough :p

-- 
Allan Jude

___
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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Allan Jude]

On 2013-10-10 13:21, Warren Block wrote:
> [off-list reply]
>
> I have not tested the new version yet.  Is there any chance it
> supports setting up a gmirror?
>
> Something I've been meaning to discuss with Devin is the concept of
> presets.  The user would be able to choose from a list of presets:
>
>   Filesystem Layout
>   -
>   Merged / filesystem
>   Split /, /var, /tmp, /usr filesystems
>
> then
>
>   Filesystem Type
>   ---
>   UFS
>   ZFS
>
> then
>
>   Disk Layout
>   ---
>   Plain disk
>   Mirror
>   RAID
>
> Those choices might change depending on earlier ones, like if they had
> chosen ZFS earlier they would get a choice of Mirror, RAID-Z1,
> RAID-Z2, and so on.
>
> All this would build up a configuration, and at the end the user can
> edit it (filesystem sizes, for instance), then pick Go and walk away.

All of the UFS stuff is in C, so is read-only for me.

It is something I'd like to do, but it is really iffy if that can be
done in time for 10.0

In general, gmirror support could be added to the ZFS section (renamed
to something else). So in our current 'zfs' menu, would become the 'new
partition manager' menu. Add an extra option for ZFS or UFS, and then
the vdev menu would context switch between zfs vdevs and ufs options
like gmirror and gstripe or something

Adding an extra option for / or / /var /tmp /usr is not a bad idea
either, maybe even for ZFS, offering a simpler set of datasets that
might be some people's preference (especially if I can't do the
following in time:)

In a future revision of the zfsboot stuff, I'd like to offer a dialog
where users can actually adjust the ZFS datasets. provide a menu listing
the created dataset, with option to add more, and when you select a
dataset, you can adjust its options or delete it (some really scary
validation needs to happen here so you can't delete /usr if you have
/usr/local)

If the UFS stuff took the form of the current ZFS stuff (give me the
entire disk, and i'll run with it), it would be fairly easy to
implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2

The more powerful features of the current partedit code, where it
actually shows what is on your disk already, and allows you to just
adjust it, and in general manage dual booting etc, that is a lot more
complicated.


-- 
Allan Jude

___
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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Teske, Devin]

On Oct 10, 2013, at 10:54 AM, Allan Jude wrote:

> On 2013-10-10 13:21, Warren Block wrote:
>> [off-list reply]
>> 
>> I have not tested the new version yet.  Is there any chance it
>> supports setting up a gmirror?
>> 
>> Something I've been meaning to discuss with Devin is the concept of
>> presets.  The user would be able to choose from a list of presets:
>> 
>>  Filesystem Layout
>>  -
>>  Merged / filesystem
>>  Split /, /var, /tmp, /usr filesystems
>> 
>> then
>> 
>>  Filesystem Type
>>  ---
>>  UFS
>>  ZFS
>> 
>> then
>> 
>>  Disk Layout
>>  ---
>>  Plain disk
>>  Mirror
>>  RAID
>> 
>> Those choices might change depending on earlier ones, like if they had
>> chosen ZFS earlier they would get a choice of Mirror, RAID-Z1,
>> RAID-Z2, and so on.
>> 
>> All this would build up a configuration, and at the end the user can
>> edit it (filesystem sizes, for instance), then pick Go and walk away.
> 
> All of the UFS stuff is in C, so is read-only for me.
> 
> It is something I'd like to do, but it is really iffy if that can be
> done in time for 10.0
> 
> In general, gmirror support could be added to the ZFS section (renamed
> to something else). So in our current 'zfs' menu, would become the 'new
> partition manager' menu. Add an extra option for ZFS or UFS, and then
> the vdev menu would context switch between zfs vdevs and ufs options
> like gmirror and gstripe or something
> 
> Adding an extra option for / or / /var /tmp /usr is not a bad idea
> either, maybe even for ZFS, offering a simpler set of datasets that
> might be some people's preference (especially if I can't do the
> following in time:)
> 
> In a future revision of the zfsboot stuff, I'd like to offer a dialog
> where users can actually adjust the ZFS datasets. provide a menu listing
> the created dataset, with option to add more, and when you select a
> dataset, you can adjust its options or delete it (some really scary
> validation needs to happen here so you can't delete /usr if you have
> /usr/local)
> 
> If the UFS stuff took the form of the current ZFS stuff (give me the
> entire disk, and i'll run with it), it would be fairly easy to
> implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2
> 
> The more powerful features of the current partedit code, where it
> actually shows what is on your disk already, and allows you to just
> adjust it, and in general manage dual booting etc, that is a lot more
> complicated.
> 

But the API exists (and we get a taste of the API in zfsboot). Specifically, a 
script
would mangle a disk and then call f_device_rescan to get the menus to populate
new entries.

That aside, one of my plans for diskmgmt was to essentially let the user perform
free-wheeling adhoc configurations.

Here's an extreme example of what I mean**:

1. Boot a box with naked disks
2. Create some gmultipath labels
3. Put a GPT scheme on the disk with one BSD partition
4. Put some UFS labels in the partition
5. Build a zpool out of a secondary label of each multipath'd disk

** Because afterall, FreeBSD shouldn't prevent you from doing something like 
that.

I think that if we try to tackle scenarios like that, then we'll really come up 
with a
winning diskmgmt module (because right now I can't go do some UFS setup and
then shove the products into a zpool).

_When_ the ZFS management stuff is all integrated (which I plan on integrating
bits from pjd's zfsconf too), I think it should be agnostic about what you give 
it as
a device *and* allow you to configure many types of things without being forced
into an "either-or" situation (because often it can be a "I want both" 
situation).

(tuppence)
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
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: rcs

[Jos Backus]

On Oct 10, 2013 9:38 AM, "Julian Elischer"  wrote:
>
> On 10/11/13 12:34 AM, Jos Backus wrote:
>>
>> On Thu, Oct 10, 2013 at 9:10 AM, Julian Elischer 
wrote:
>>>
>>> On 10/9/13 11:59 PM, Jos Backus wrote:
>>
>> [snip]

 OK, but please, can we replace RCS with Fossil in 11 then? That adds a
real
 improvement to FreeBSD while giving people plenty of time to prepare.
>>>
>>> can fossil read rcs files? and how big is it compared to RCS?
>>
>>
>> It seems there's some thought on importing CVS repos but according to
'fossil help import', only the git fast-export format is supported.
>> In practice this means you'd loose history, yes. But it's not hard to
keep the old RCS files somewhere else in case that history is needed.
>>
>> http://www.fossil-scm.org/fossil/wiki?name=Import+CVS+Repositories
>>
>> I just built devel/fossil and it yields a single binary,
/usr/local/bin/fossil which clocks in at 1.8M. Given all the functionality
it provides (plus it is in a similar class as git, see
http://www.fossil-scm.org/index.html/doc/tip/www/fossil-v-git.wiki), I
think that's a steal.
>>
>> It was started by the author of SQlite. If we require some kind of
version control system in the base that's powerful, well-maintained and
BSD-licensed, this really seems like a no-brainer.
>
>
> well since people expect RCS.. it is not a no brainer.
> you are asking people to learn  a whole new tool  for functionality that
is currently very simple..
> edit file
> ci -l file
> add comment.

Such is the price of progress. I envy people who don't have to learn
anything new in order to stay employed  :-)

Jos

>
>
>
>>
>> Jos
>> --
>> Jos Backus
>> jos at catnook.com
>
>
___
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 10 and zfsd

[Mark Felder]

On Thu, Oct 10, 2013, at 12:40, Allan Jude wrote:
> On 2013-10-10 13:26, Alan Somers wrote:
> > On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude  wrote:
> >> On 2013-10-10 12:13, Mark Felder wrote:
> >>> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
>  On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
>  wrote:
> > When i started using ZFS on FreeBSD I quickly found out that hot spares 
> > are
> > not possible on FreeBSD.
> > I was told that with zfsd it should be possible and that it would be
> > included in FreeBSD 10.
> >
> > Is there some info about the zfsd function and how it could be used?
>  zfsd is currently not in FreeBSD/head and won't make it into 10, but
>  you can still get the source code from its project branch.  It's being
>  used in production by at least two companies.
> 
> >>> So FreeBSD is going to have inferior ZFS management compared to
> >>> Solaris/Illumos/etc for another 2+ years? Why are things like this
> >>> allowed to miss releases?
> >>> ___
> >>> 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"
> >> ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3
> >> weeks ago). There is a lot of collaboration going on, to bring in some
> >> work done by vendors like SpectraLogics. This is the type of feature
> >> that can be assed in 10.1, it won't have to wait for 11.
> >>
> >> You can see Robert Watsons talk "How FreeBSD Works" to see why releases
> >> are based on date, rather than on feature completion (because things are
> >> never "finished")
> >>
> >>
> >>
> >> --
> >> Allan Jude
> >>
> >> ___
> >> 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"
> > Due to popular demand, I have located a round toit.  I'm currently
> > working on rebasing the zfsd project branch to head, after which I'll
> > push SpectraLogic's recent changes.
> See, all you have to do is complain loudly enough :p
> 

I was sad more than anything. I'd been waiting for zfsd since the
project was announced. :-) I'm glad to know we won't have to wait until
11.0.
___
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"

undefined reference to xenpci_alloc_space

[Michael Schmiedgen]

Hi List,

is it intended that kernel does not build if

device xenpci

is omitted in the kernel config? I get the following error:

linking kernel
gnttab.o: In function `gnttab_resume':
/usr/src/sys/xen/gnttab.c:(.text+0xe47): undefined reference to 
`xenpci_alloc_space'


Thanks,
  Michael
___
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: rcs

[Diane Bruce]

...
>  OK, but please, can we replace RCS with Fossil in 11 then? That adds a
> real
>  improvement to FreeBSD while giving people plenty of time to prepare.

Fossil was showing promise the last time I tried it. Quite frankly

> > well since people expect RCS.. it is not a no brainer.
> > you are asking people to learn  a whole new tool  for functionality that
> is currently very simple..
> > edit file
> > ci -l file
> > add comment.

pfft as long as any SCS can read my old rcs files this old fart does
not mind.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: rcs

[Igor Mozolevsky]

On 10 October 2013 19:15, Jos Backus  wrote:

> On Oct 10, 2013 9:38 AM, "Julian Elischer"  wrote:
>

[snip]


> > well since people expect RCS.. it is not a no brainer.
>  > you are asking people to learn  a whole new tool  for functionality that
> is currently very simple..
> > edit file
> > ci -l file
> > add comment.
>
> Such is the price of progress. I envy people who don't have to learn
> anything new in order to stay employed  :-)
>

So your definition of progress is "doing more work to achieve the same
result"?..

-- 
Igor M.
___
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: make universe fails, apparently in lib/clang/include (all)

[Dimitry Andric]

On Oct 10, 2013, at 18:45, Eric van Gyzen  wrote:
> "make universe" is consistently failing in the following way. 
> "_.amd64.amd64.buildworld" contains:
> 
> 
> 
> ===> lib/clang/libllvmx86desc (all)
> ===> lib/clang/libllvmx86disassembler (all)
> ===> lib/clang/libllvmx86info (all)
> ===> lib/clang/libllvmx86instprinter (all)
> ===> lib/clang/libllvmx86utils (all)
> ===> lib/clang/include (all)
> 1 error
> 
> make[3]: stopped in /home/freebsd
> *** [everything] Error code 2

Hi Eric,

Can you please upload the full _.amd64.amd64.buildworld file somewhere?
The actual error will have occurred earlier in the build, and it is not
directly visible in the last few lines.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make universe fails, apparently in lib/clang/include (all)

[Eric van Gyzen]

On 10/10/2013 14:02, Dimitry Andric wrote:
> On Oct 10, 2013, at 18:45, Eric van Gyzen  wrote:
>> "make universe" is consistently failing in the following way. 
>> "_.amd64.amd64.buildworld" contains:
>>
>> 
>>
>> ===> lib/clang/libllvmx86desc (all)
>> ===> lib/clang/libllvmx86disassembler (all)
>> ===> lib/clang/libllvmx86info (all)
>> ===> lib/clang/libllvmx86instprinter (all)
>> ===> lib/clang/libllvmx86utils (all)
>> ===> lib/clang/include (all)
>> 1 error
>>
>> make[3]: stopped in /home/freebsd
>> *** [everything] Error code 2
> Hi Eric,
>
> Can you please upload the full _.amd64.amd64.buildworld file somewhere?
> The actual error will have occurred earlier in the build, and it is not
> directly visible in the last few lines.

Dimitry,

Will do.  I looked back many lines, and didn't see any errors.  Maybe
another pair of eyes will help.

Eric
___
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: claws-mail deadlocking in iconv

[Maciej Suszko]

Fabian Keil  wrote:
> After the iconv import claws-mail started to deadlock in iconv every
> now and then on my system, which prevented claws-mail from rendering
> windows or reacting to input.
> 
> So far I haven't been able to reproduce this intentionally and various
> rebuilds of ports, kernel and userland (mainly for other reasons) had
> no effect.
> 
> When the problem occurs, trying to attach to the process causes
> gdb and gdb76 to crash which also crashes claws-mail, but sending
> SIGABRT causes a proper core dump that can be analysed with gdb.
> 
> The backtraces always show that there is only one thread running and
> it's trying to lock cm_lock in _citrus_mapper_close(), which
> apparently is already locked due to a _citrus_mapper_close()
> recursion. Examples:

[...]

> This patch:
> http://www.fabiankeil.de/sourcecode/freebsd/iconv-Let-_citrus_mapper_close-unlock-cm_lock-before-calli.diff
> seems to prevent the deadlock, but I'm not 100% sure that it's
> correct and I'm also a bit surprised by the lack of reports from
> other claws-mail users.
> 
> Did anyone else run into this or can comment on the patch or
> the backtraces?


In my case Claws Mail was hanging everytime I tried to access one of
my bigger IMAP folders (50k+ messages). It was 100% reproducible.

The patch seems to solve the problem for me - Claws is running now
smooth, without any locks.
-- 
regards, Maciej Suszko.


signature.asc
Description: PGP signature

Re: rcs

[Jos Backus]

On Oct 10, 2013 11:54 AM, "Igor Mozolevsky"  wrote:
>
>
>
>
> On 10 October 2013 19:15, Jos Backus  wrote:
>>
>> On Oct 10, 2013 9:38 AM, "Julian Elischer"  wrote:
>
>
> [snip]
>
>>
>> > well since people expect RCS.. it is not a no brainer.
>> > you are asking people to learn  a whole new tool  for functionality
that
>> is currently very simple..
>> > edit file
>> > ci -l file
>> > add comment.
>>
>> Such is the price of progress. I envy people who don't have to learn
>> anything new in order to stay employed  :-)
>
>
> So your definition of progress is "doing more work to achieve the same
result"?..

That would only be true if they were equivalent, and we didn't care about
the extra features. You may not, but many people do, as the popularity of
git and other distributed version control systems proves.

Jos

>
> --
> Igor M.
___
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: claws-mail deadlocking in iconv

[Tijl Coosemans]

On Wed, 9 Oct 2013 18:34:46 +0200 Fabian Keil wrote:
> After the iconv import claws-mail started to deadlock in iconv every now
> and then on my system, which prevented claws-mail from rendering windows
> or reacting to input.
> 
> So far I haven't been able to reproduce this intentionally and various
> rebuilds of ports, kernel and userland (mainly for other reasons) had
> no effect.
> 
> When the problem occurs, trying to attach to the process causes
> gdb and gdb76 to crash which also crashes claws-mail, but sending
> SIGABRT causes a proper core dump that can be analysed with gdb.
> 
> The backtraces always show that there is only one thread running and
> it's trying to lock cm_lock in _citrus_mapper_close(), which apparently
> is already locked due to a _citrus_mapper_close() recursion. Examples:
> 
> #0  _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> 37RSYSCALL_ERR(_umtx_op)
> [New Thread 80a806400 (LWP 100487/claws-mail)]
> (gdb) where
> #0  _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> #1  0x0008084861a6 in __thr_rwlock_wrlock (rwlock=0x80a8a47c0, tsp= optimized out>) at /usr/src/lib/libthr/thread/thr_umtx.c:296
> #2  0x000808489b1d in rwlock_wrlock_common (rwlock=, 
> abstime=0x0) at /usr/src/lib/libthr/thread/thr_rwlock.c:267
> #3  0x000808489a8b in _pthread_rwlock_wrlock (rwlock=0x80a8a47c0) at 
> /usr/src/lib/libthr/thread/thr_rwlock.c:289
> #4  0x00080911e848 in _citrus_mapper_close (cm=0x80b5a2d80) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:375
> #5  0x00080d205d18 in _citrus_mapper_serial_mapper_uninit 
> (cm=0x80b5a2d40) at 
> /usr/src/lib/libiconv_modules/mapper_parallel/../mapper_serial/citrus_mapper_serial.c:110
> #6  0x00080911e8d7 in mapper_close (cm=0x80b5a2d40) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:188
> #7  0x00080911e88c in _citrus_mapper_close (cm=) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:384
> #8  0x00080c4e83f3 in close_srcs (sl=0x80b591140) at 
> /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:206
> #9  0x00080c4e7dc9 in _citrus_iconv_std_iconv_uninit_shared (ci= optimized out>) at 
> /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:415
> #10 0x0008090f3f95 in release_shared (ci=0x80a8ee630) at 
> /usr/src/lib/libc/iconv/citrus_iconv.c:99
> #11 0x0008090f4002 in _citrus_iconv_close (cv=0x80d88d5d0) at 
> /usr/src/lib/libc/iconv/citrus_iconv.c:335
> #12 0x0008090f1ca6 in iconv_close (handle=0x80a8a47c0) at 
> /usr/src/lib/libc/iconv/iconv.c:131
> #13 0x0046376d in conv_iconv_strdup (inbuf=0x7fff58b0 "\n", 
> src_code=0x80b5b4db0 "Windows-1252", dest_code=0x6f03d0 "UTF-8") at 
> codeconv.c:895
> #14 0x00463d13 in conv_convert (conv=0x80b5a4e80, 
> outbuf=0x7fff3720 "", outlen=8192, inbuf=0x7fff58b0 "\n") at 
> codeconv.c:734
> #15 0x005e22ac in textview_write_line (textview=0x80a959cc0, 
> str=0x7fff58b0 "\n", conv=0x80b5a4e80, do_quote_folding=1) at 
> textview.c:1573
> #16 0x005df8e4 in textview_write_body (textview=0x80a959cc0, 
> mimeinfo=0x80aad2d00) at textview.c:1177
> #17 0x005e5363 in textview_add_part (textview=0x80a959cc0, 
> mimeinfo=0x80aad2d00) at textview.c:826
> #18 0x005e4053 in recursive_add_parts (textview=0x80a959cc0, 
> node=0x80a826190) at textview.c:839
> #19 0x005e4302 in recursive_add_parts (textview=0x80a959cc0, 
> node=0x80aa81d20) at textview.c:888
> #20 0x005e4302 in recursive_add_parts (textview=0x80a959cc0, 
> node=0x80a828890) at textview.c:888
> #21 0x005defa1 in textview_add_parts (textview=0x80a959cc0, 
> mimeinfo=0x80b610700) at textview.c:898
> #22 0x005deb85 in textview_show_part (textview=0x80a959cc0, 
> mimeinfo=0x80b610700, fp=0x8094319a0) at textview.c:645
> [...]
> 
> #0  0x000808491b9c in __error () from /lib/libthr.so.3
> #1  0x00080848bb1d in rwlock_wrlock_common (rwlock=, 
> abstime=0x0) at /usr/src/lib/libthr/thread/thr_rwlock.c:267
> #2  0x00080848ba8b in _pthread_rwlock_wrlock (rwlock=0x80a8ede20) at 
> /usr/src/lib/libthr/thread/thr_rwlock.c:289
> #3  0x00080911f848 in _citrus_mapper_close (cm=0x80a8bfc40) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:375
> #4  0x00080ce02d18 in _citrus_mapper_serial_mapper_uninit 
> (cm=0x80a8bfc00) at 
> /usr/src/lib/libiconv_modules/mapper_parallel/../mapper_serial/citrus_mapper_serial.c:110
> #5  0x00080911f8d7 in mapper_close (cm=0x80a8bfc00) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:188
> #6  0x00080911f88c in _citrus_mapper_close (cm=) at 
> /usr/src/lib/libc/iconv/citrus_mapper.c:384
> #7  0x00080c5893f3 in close_srcs (sl=0x80a8edda0) at 
> /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:206
> #8  0x00080c588dc9 in _citrus_iconv_std_iconv_uninit_shared (ci= optimized out>) at 
> /usr/src/lib/libiconv_modules/iconv_std/citrus_iconv_std.c:415
> #9  0x0008090f4f95 in release_shared (ci=0x80b408890

Re: FreeBSD 10 and zfsd

[O. Hartmann]

On Thu, 10 Oct 2013 13:41:06 -0500
Mark Felder  wrote:

> 
> 
> On Thu, Oct 10, 2013, at 12:40, Allan Jude wrote:
> > On 2013-10-10 13:26, Alan Somers wrote:
> > > On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude
> > >  wrote:
> > >> On 2013-10-10 12:13, Mark Felder wrote:
> > >>> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
> >  On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks
> >   wrote:
> > > When i started using ZFS on FreeBSD I quickly found out that
> > > hot spares are not possible on FreeBSD.
> > > I was told that with zfsd it should be possible and that it
> > > would be included in FreeBSD 10.
> > >
> > > Is there some info about the zfsd function and how it could
> > > be used?
> >  zfsd is currently not in FreeBSD/head and won't make it into
> >  10, but you can still get the source code from its project
> >  branch.  It's being used in production by at least two
> >  companies.
> > 
> > >>> So FreeBSD is going to have inferior ZFS management compared to
> > >>> Solaris/Illumos/etc for another 2+ years? Why are things like
> > >>> this allowed to miss releases?
> > >>> ___
> > >>> 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"
> > >> ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev
> > >> summit (3 weeks ago). There is a lot of collaboration going on,
> > >> to bring in some work done by vendors like SpectraLogics. This
> > >> is the type of feature that can be assed in 10.1, it won't have
> > >> to wait for 11.
> > >>
> > >> You can see Robert Watsons talk "How FreeBSD Works" to see why
> > >> releases are based on date, rather than on feature completion
> > >> (because things are never "finished")
> > >>
> > >>
> > >>
> > >> --
> > >> Allan Jude
> > >>
> > >> ___
> > >> 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"
> > > Due to popular demand, I have located a round toit.  I'm currently
> > > working on rebasing the zfsd project branch to head, after which
> > > I'll push SpectraLogic's recent changes.
> > See, all you have to do is complain loudly enough :p
> > 
> 
> I was sad more than anything. I'd been waiting for zfsd since the
> project was announced. :-) I'm glad to know we won't have to wait
> until 11.0.
> ___
> 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"

Ha!

Very funny. I created a RAIDZ1 pool and by reading the man page for
zpool, which states precisely how to create a hot spare for a given
pool. I wasn't aware until now that this action was useless, and even
dangerous. Well, bravo, I must admit, the man page does not give any
kind of warning that one can not rely on a hot spare.

oh


signature.asc
Description: PGP signature

Re: rcs

[Igor Mozolevsky]

On 10 October 2013 20:36, Jos Backus  wrote:

>
> On Oct 10, 2013 11:54 AM, "Igor Mozolevsky"  wrote:
> >
> > On 10 October 2013 19:15, Jos Backus  wrote:
> >>
> >> On Oct 10, 2013 9:38 AM, "Julian Elischer"  wrote:
> >
> >
> > [snip]
> >
> >>
> >> > well since people expect RCS.. it is not a no brainer.
> >> > you are asking people to learn  a whole new tool  for functionality
> that
> >> is currently very simple..
> >> > edit file
> >> > ci -l file
> >> > add comment.
> >>
> >> Such is the price of progress. I envy people who don't have to learn
> >> anything new in order to stay employed  :-)
> >
> >
> > So your definition of progress is "doing more work to achieve the same
> result"?..
>
> That would only be true if they were equivalent, and we didn't care about
> the extra features. You may not, but many people do, as the popularity of
> git and other distributed version control systems proves.
>

You're missing the point- the requirement is "provide a way to keep track
of changes for file X" not "have many fancy and unnecessary features"...


-- 
Igor M.
___
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: rcs

[Jos Backus]

On Oct 10, 2013 1:07 PM, "Igor Mozolevsky"  wrote:
>
>
>
>
> On 10 October 2013 20:36, Jos Backus  wrote:
>>
>>
>> On Oct 10, 2013 11:54 AM, "Igor Mozolevsky" 
wrote:
>> >
>> > On 10 October 2013 19:15, Jos Backus  wrote:
>> >>
>> >> On Oct 10, 2013 9:38 AM, "Julian Elischer"  wrote:
>> >
>> >
>> > [snip]
>> >
>> >>
>> >> > well since people expect RCS.. it is not a no brainer.
>> >> > you are asking people to learn  a whole new tool  for functionality
that
>> >> is currently very simple..
>> >> > edit file
>> >> > ci -l file
>> >> > add comment.
>> >>
>> >> Such is the price of progress. I envy people who don't have to learn
>> >> anything new in order to stay employed  :-)
>> >
>> >
>> > So your definition of progress is "doing more work to achieve the same
result"?..
>>
>> That would only be true if they were equivalent, and we didn't care
about the extra features. You may not, but many people do, as the
popularity of git and other distributed version control systems proves.
>
>
> You're missing the point- the requirement is "provide a way to keep track
of changes for file X" not "have many fancy and unnecessary features"...

That may have been the requirement at the time of the RCS import but the
world has changed in my view. Feel free to use the old tools though, nobody
is saying you can't.

Anyway, why not change this for 11? Do we feel RCS is superior simply
because we are familiar with it? What about all the extra features modern
version control offers? Sounds like people think it's all a step backwards,
all we need is manage separate files. No need for changesets or any other
modern features.

I don't really understand the resistance. We're okay with importing
Subversion which has less functionally and more dependencies but a single
Fossil binary is too intrusive?

Jos

>
> --
> Igor M.
___
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: rcs

[C. P. Ghost]

On Thu, Oct 10, 2013 at 8:51 PM, Diane Bruce  wrote:

> ...
> >  OK, but please, can we replace RCS with Fossil in 11 then? That
> adds a
> > real
> >  improvement to FreeBSD while giving people plenty of time to
> prepare.
>
> Fossil was showing promise the last time I tried it. Quite frankly
>
> > > well since people expect RCS.. it is not a no brainer.
> > > you are asking people to learn  a whole new tool  for functionality
> that
> > is currently very simple..
> > > edit file
> > > ci -l file
> > > add comment.
>
> pfft as long as any SCS can read my old rcs files this old fart does
> not mind.
>

Same here. Don't care about the tool, as long as it can provide backward
compatibility to the RCS format, and provides the familiar command interface
(ci, co, ...) somehow.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
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: rcs

[Lyndon Nerenberg]

On 2013-10-10, at 1:06 PM, Igor Mozolevsky  wrote:

> You're missing the point- the requirement is "provide a way to keep track
> of changes for file X" not "have many fancy and unnecessary features"...

The point is to put back the specific RCS commands that were recently removed.

Those of us using RCS do so because it's in the base system.  If we 
wanted/needed another SCM, we would install it from ports.  But many of us use 
RCS specifically because installing a port is not an option.  *Why* it's not an 
option is not relevant.

RCS is not broken, and is very low maintenance code. /usr/src/gnu/usr.bin/rcs 
has been modified four times in the last decade.  Two of those changes were 
sweeping Makefile updates that affected much more than RCS.  Of the other two, 
only one update touched the actual code, and that was a one line change to a .h.

--lyndon

___
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: make universe fails, apparently in lib/clang/include (all)

[Eric van Gyzen]

On 10/10/2013 14:02, Dimitry Andric wrote:
> On Oct 10, 2013, at 18:45, Eric van Gyzen  wrote:
>> "make universe" is consistently failing in the following way. 
>> "_.amd64.amd64.buildworld" contains:
>>
>> 
>>
>> ===> lib/clang/libllvmx86desc (all)
>> ===> lib/clang/libllvmx86disassembler (all)
>> ===> lib/clang/libllvmx86info (all)
>> ===> lib/clang/libllvmx86instprinter (all)
>> ===> lib/clang/libllvmx86utils (all)
>> ===> lib/clang/include (all)
>> 1 error
>>
>> make[3]: stopped in /home/freebsd
>> *** [everything] Error code 2
> Hi Eric,
>
> Can you please upload the full _.amd64.amd64.buildworld file somewhere?
> The actual error will have occurred earlier in the build, and it is not
> directly visible in the last few lines.

http://www.vangyzen.net/FreeBSD/tmp/_.amd64.amd64.buildworld.xz

Now I see the error around line 114311.  Any ideas?

I failed to mention, /etc/make.conf only has a PERL_VERSION, and I have
no /etc/src.conf.

Eric
___
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: rcs

[Glen Barber]

On Thu, Oct 10, 2013 at 01:35:33PM -0700, Lyndon Nerenberg wrote:
> 
> On 2013-10-10, at 1:06 PM, Igor Mozolevsky  wrote:
> 
> > You're missing the point- the requirement is "provide a way to keep track
> > of changes for file X" not "have many fancy and unnecessary features"...
> 
> The point is to put back the specific RCS commands that were recently removed.
> 

http://lists.freebsd.org/pipermail/svn-src-head/2013-October/052106.html

Glen



pgpwrgyRT0jiY.pgp
Description: PGP signature

Re: Prompt Live-CD/DVD with support for ZFS v.5000

[Vladislav V. Prodan]

04.10.2013 16:56, Ollivier Robert wrote:
> According to Vladislav V. Prodan on Fri, Oct 04, 2013 at 01:48:16AM +0300:
>> You want to add such a liveCD for automatic loading on PXE.
>> MfsBSD built with ZFS v.28 :(
> 
> mfsbsd will be updated soon I guess but in the meantime it is very easy to 
> generate your own.  Just get the code from github, modify a few config files 
> if needed and make.
> 

Thanks.

In the latest build no libiconv.so.3

root@mfsbsd:/tmp/oldpool/var/db/mysql # rsync -a
/tmp/oldpool/var/db/mysql/ /tmp/newpool/var/db/mysql/
Shared object "libiconv.so.3" not found, required by "rsync"




-- 
Vladislav V. Prodan
System & Network Administrator
http://support.od.ua
+380 67 4584408, +380 99 4060508
VVP88-RIPE
___
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: rcs

[Igor Mozolevsky]

On 10 October 2013 21:18, Jos Backus  wrote:

>
> On Oct 10, 2013 1:07 PM, "Igor Mozolevsky"  wrote:
> >
>
[snip]

> > You're missing the point- the requirement is "provide a way to keep
> track of changes for file X" not "have many fancy and unnecessary
> features"...
>
> That may have been the requirement at the time of the RCS import but the
> world has changed in my view. Feel free to use the old tools though, nobody
> is saying you can't.
>
> Anyway, why not change this for 11? Do we feel RCS is superior simply
> because we are familiar with it? What about all the extra features modern
> version control offers? Sounds like people think it's all a step backwards,
> all we need is manage separate files. No need for changesets or any other
> modern features.
>

RCS is a tool that does it's job. It's been in base since time immemoriam,
and is more likely than not to be found in other flavours of Unix(TM).
Moreover, RCS commands are integrated into a lot of scripts that sysadmins
use (it'd be naive to think otherwise), so in terms of $$$ not having RCS
in base (yup, I know the change's been reverted) has a real cost to
business!

I don't really understand the resistance. We're okay with importing
> Subversion which has less functionally and more dependencies but a single
> Fossil binary is too intrusive?
>

SVN is the necessary evil, the project uses it and until the project
switches to something else we're "stuck with it". What's the case for
Fossil?..

-- 
Igor M.
___
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: Prompt Live-CD/DVD with support for ZFS v.5000

[Allan Jude]

On 2013-10-10 17:12, Vladislav V. Prodan wrote:
> 04.10.2013 16:56, Ollivier Robert wrote:
>> According to Vladislav V. Prodan on Fri, Oct 04, 2013 at 01:48:16AM +0300:
>>> You want to add such a liveCD for automatic loading on PXE.
>>> MfsBSD built with ZFS v.28 :(
>> mfsbsd will be updated soon I guess but in the meantime it is very easy to 
>> generate your own.  Just get the code from github, modify a few config files 
>> if needed and make.
>>
> Thanks.
>
> In the latest build no libiconv.so.3
>
> root@mfsbsd:/tmp/oldpool/var/db/mysql # rsync -a
> /tmp/oldpool/var/db/mysql/ /tmp/newpool/var/db/mysql/
> Shared object "libiconv.so.3" not found, required by "rsync"
>
>
>
>
First time seeing this thread, but Devin Teske and I have just finished
integrated support for root-on-zfs installs in bsdinstall, should land
in head today

-- 
Allan Jude

___
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 10 and zfsd

[Outback Dingo]

On Thu, Oct 10, 2013 at 1:26 PM, Alan Somers  wrote:

> On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude 
> wrote:
> > On 2013-10-10 12:13, Mark Felder wrote:
> >> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
> >>> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks <
> joh.hendr...@gmail.com>
> >>> wrote:
>  When i started using ZFS on FreeBSD I quickly found out that hot
> spares are
>  not possible on FreeBSD.
>  I was told that with zfsd it should be possible and that it would be
>  included in FreeBSD 10.
> 
>  Is there some info about the zfsd function and how it could be used?
> >>> zfsd is currently not in FreeBSD/head and won't make it into 10, but
> >>> you can still get the source code from its project branch.  It's being
> >>> used in production by at least two companies.
> >>>
> >> So FreeBSD is going to have inferior ZFS management compared to
> >> Solaris/Illumos/etc for another 2+ years? Why are things like this
> >> allowed to miss releases?
> >> ___
> >> 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"
> > ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3
> > weeks ago). There is a lot of collaboration going on, to bring in some
> > work done by vendors like SpectraLogics. This is the type of feature
> > that can be assed in 10.1, it won't have to wait for 11.
> >
> > You can see Robert Watsons talk "How FreeBSD Works" to see why releases
> > are based on date, rather than on feature completion (because things are
> > never "finished")
> >
> >
> >
> > --
> > Allan Jude
> >
> > ___
> > 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"
>
> Due to popular demand, I have located a round toit.  I'm currently
> working on rebasing the zfsd project branch to head, after which I'll
> push SpectraLogic's recent changes.
>

Sweet... something to play with the next few days and see how
stable it is.


> ___
> 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"
>
___
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"

Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2

[Mike C.]

Hi,

I'm running Alpha-2 and wanted to test with iscsi but it seems I can't
start iscsid.


$ sudo service iscsid onerestart
kldload: can't load iscsi: Exec format error
/etc/rc.d/iscsid: WARNING: Unable to load kernel module iscsi
/etc/rc.d/iscsid: WARNING: failed precmd routine for iscsid


dmesg shows:
interface icl.1 already present in the KLD 'kernel'!
linker_load_file: Unsupported file type


And also it seems that iscsi is actually already loaded:

sudo kldstat -v | grep isci
470 pci/isci


Any help is appreciated.



-- 
Melhores Cumprimentos // Best Regards

Miguel Clara
*nix Sys Admin Freelance

___
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: Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2

[Allan Jude]

On 2013-10-10 17:41, Mike C. wrote:
> Hi,
>
> I'm running Alpha-2 and wanted to test with iscsi but it seems I can't
> start iscsid.
>
>
> $ sudo service iscsid onerestart
> kldload: can't load iscsi: Exec format error
> /etc/rc.d/iscsid: WARNING: Unable to load kernel module iscsi
> /etc/rc.d/iscsid: WARNING: failed precmd routine for iscsid
>
>
> dmesg shows:
> interface icl.1 already present in the KLD 'kernel'!
> linker_load_file: Unsupported file type
>
>
> And also it seems that iscsi is actually already loaded:
>
> sudo kldstat -v | grep isci
> 470 pci/isci
>
>
> Any help is appreciated.
>
>
>
isci is the intel SAS driver, not iscsi (confusing name)

The problem appears to be that the iscsi module you have is not the same
version as your kernel, try updating to ALPHA5

-- 
Allan Jude

___
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 10 and zfsd

[Allan Jude]

On 2013-10-10 15:59, O. Hartmann wrote:
> On Thu, 10 Oct 2013 13:41:06 -0500
> Mark Felder  wrote:
>
>>
>> On Thu, Oct 10, 2013, at 12:40, Allan Jude wrote:
>>> On 2013-10-10 13:26, Alan Somers wrote:
 On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude
  wrote:
> On 2013-10-10 12:13, Mark Felder wrote:
>> On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
>>> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks
>>>  wrote:
 When i started using ZFS on FreeBSD I quickly found out that
 hot spares are not possible on FreeBSD.
 I was told that with zfsd it should be possible and that it
 would be included in FreeBSD 10.

 Is there some info about the zfsd function and how it could
 be used?
>>> zfsd is currently not in FreeBSD/head and won't make it into
>>> 10, but you can still get the source code from its project
>>> branch.  It's being used in production by at least two
>>> companies.
>>>
>> So FreeBSD is going to have inferior ZFS management compared to
>> Solaris/Illumos/etc for another 2+ years? Why are things like
>> this allowed to miss releases?
>> ___
>> 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"
> ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev
> summit (3 weeks ago). There is a lot of collaboration going on,
> to bring in some work done by vendors like SpectraLogics. This
> is the type of feature that can be assed in 10.1, it won't have
> to wait for 11.
>
> You can see Robert Watsons talk "How FreeBSD Works" to see why
> releases are based on date, rather than on feature completion
> (because things are never "finished")
>
>
>
> --
> Allan Jude
>
> ___
> 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"
 Due to popular demand, I have located a round toit.  I'm currently
 working on rebasing the zfsd project branch to head, after which
 I'll push SpectraLogic's recent changes.
>>> See, all you have to do is complain loudly enough :p
>>>
>> I was sad more than anything. I'd been waiting for zfsd since the
>> project was announced. :-) I'm glad to know we won't have to wait
>> until 11.0.
>> ___
>> 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"
> Ha!
>
> Very funny. I created a RAIDZ1 pool and by reading the man page for
> zpool, which states precisely how to create a hot spare for a given
> pool. I wasn't aware until now that this action was useless, and even
> dangerous. Well, bravo, I must admit, the man page does not give any
> kind of warning that one can not rely on a hot spare.
>
> oh
The ZFS spare functinality basically just marks the drive as a spare, so
you as the admin know what drive to use when replacement time comes

I've been working on the handbook section on ZFS and made certain to
mention that, I'll have to look at improving the man page as well, but
as far as I know, the man page is imported from IllumOS, where spares do
work.

ZFSd is important and I hope to see more movement on it soon.

-- 
Allan Jude

___
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: /usr/local/lib /usr/bin/ld: ø: invalid DSO for symbol

[Alastair Hogge]

On 2013-10-10 Thu 21:51:48 +0200, Marc UBM wrote:
>
> Hiho! :-)

Hi

> Trying to compile several ports in the wake of the recent iconv change
> yields the following error that I could not get rid of yet:
>
> 
> libtool: link: cc -O2 -pipe -fno-strict-aliasing -Wall
> -I/usr/local/include -Wl,-rpath=/usr/local/lib
> -Wl,-rpath=/usr/local/lib -o irssi gui-entry.o gui-expandos.o
> gui-printtext.o gui-readline.o gui-windows.o lastlog.o mainwindows.o
> mainwindow-activity.o mainwindows-layout.o statusbar.o
> statusbar-config.o statusbar-items.o term.o term-dummy.o tparm.o
> term-terminfo.o terminfo-core.o textbuffer.o textbuffer-commands.o
> textbuffer-view.o irssi.o module-formats.o
> -Wl,-R/usr/local/lib/perl5/5.14/mach/CORE -pthread -Wl,-E
> -fstack-protector -Wl,--export-dynamic -pthread
> -Wl,--export-dynamic  ../fe-common/irc/libfe_common_irc.a 
> ../fe-common/irc/dcc/libfe_irc_dcc.a 
> ../fe-common/irc/notifylist/libfe_irc_notifylist.a 
> ../fe-common/core/libfe_common_core.a ../irc/libirc.a 
> ../irc/core/libirc_core.a ../irc/dcc/libirc_dcc.a ../irc/flood/libirc_flood.a 
> ../irc/notifylist/libirc_notifylist.a ../core/libcore.a 
> ../lib-config/libirssi_config.a ../perl/.libs/libperl_core_static.a 
> ../perl/.libs/libfe_perl_static.a
> -L/usr/local/lib -L/usr/local/lib/perl5/5.14/mach/CORE -lperl -lm
> -lcrypt
> -lutil /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libglib-2.0.so 
> /usr/local/lib/libpcre.so /usr/local/lib/libintl.so
> -lssl -lcrypto -lncurses -pthread -Wl,-rpath -Wl,/usr/local/lib
> -Wl,-rpath -Wl,/usr/local/lib /usr/bin/ld: ø: invalid DSO for symbol
> `tgetnum' definition /usr/local/lib/libtinfo.so.5.9: could not read
> symbols: Bad value
> 
>
>
> Any ideas how to solve that one / if I am doing something wrong?

Add the following to the offending ports' Makefile (I am upto 6):
LDFLAGS+= -ltinfow

> Bye
> Marc

Salud
alastair
--
Imagine there's no heaven... it's easy if you try.
-- John Lennon, "Imagine"
___
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: Prompt Live-CD/DVD with support for ZFS v.5000

[Martin Matuska]

I have updated the amd64 images with rsync without iconv linking.
Please re-download.

On 2013-10-10 23:12, Vladislav V. Prodan wrote:
> 04.10.2013 16:56, Ollivier Robert wrote:
>> According to Vladislav V. Prodan on Fri, Oct 04, 2013 at 01:48:16AM +0300:
>>> You want to add such a liveCD for automatic loading on PXE.
>>> MfsBSD built with ZFS v.28 :(
>> mfsbsd will be updated soon I guess but in the meantime it is very easy to 
>> generate your own.  Just get the code from github, modify a few config files 
>> if needed and make.
>>
> Thanks.
>
> In the latest build no libiconv.so.3
>
> root@mfsbsd:/tmp/oldpool/var/db/mysql # rsync -a
> /tmp/oldpool/var/db/mysql/ /tmp/newpool/var/db/mysql/
> Shared object "libiconv.so.3" not found, required by "rsync"

___
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: rcs

[Jos Backus]

On Oct 10, 2013 2:20 PM, "Igor Mozolevsky"  wrote:
>
>
>
>
> On 10 October 2013 21:18, Jos Backus  wrote:
>>
>>
>> On Oct 10, 2013 1:07 PM, "Igor Mozolevsky"  wrote:
>> >
>
> [snip]
>>
>> > You're missing the point- the requirement is "provide a way to keep
track of changes for file X" not "have many fancy and unnecessary
features"...
>>
>> That may have been the requirement at the time of the RCS import but the
world has changed in my view. Feel free to use the old tools though, nobody
is saying you can't.
>>
>> Anyway, why not change this for 11? Do we feel RCS is superior simply
because we are familiar with it? What about all the extra features modern
version control offers? Sounds like people think it's all a step backwards,
all we need is manage separate files. No need for changesets or any other
modern features.
>
>
> RCS is a tool that does it's job. It's been in base since time
immemoriam, and is more likely than not to be found in other flavours of
Unix(TM). Moreover, RCS commands are integrated into a lot of scripts that
sysadmins use (it'd be naive to think otherwise), so in terms of $$$ not
having RCS in base (yup, I know the change's been reverted) has a real cost
to business!

Like I said, change is hard. I'm not going to argue this any further, you
clearly have no interest in using better tools. Fine.

>> I don't really understand the resistance. We're okay with importing
Subversion which has less functionally and more dependencies but a single
Fossil binary is too intrusive?
>
>
> SVN is the necessary evil, the project uses it and until the project
switches to something else we're "stuck with it". What's the case for
Fossil?..

To replace RCS. But you're not interested, so I'll stop here. I have enough
trouble with Luddites at $work :-)

Jos

> --
> Igor M.
___
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: rcs

[Jakub Lach]

I have similar views. There is abundance of be-everything-for-everybody
Linuxes
and not enough lean and mean Unix-style kits...





--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/rcs-tp5850096p5850951.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
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: Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2

[Mike C.]

On 10/10/13 22:50, Allan Jude wrote:
> On 2013-10-10 17:41, Mike C. wrote:
>> Hi,
>>
>> I'm running Alpha-2 and wanted to test with iscsi but it seems I can't
>> start iscsid.
>>
>>
>> $ sudo service iscsid onerestart
>> kldload: can't load iscsi: Exec format error
>> /etc/rc.d/iscsid: WARNING: Unable to load kernel module iscsi
>> /etc/rc.d/iscsid: WARNING: failed precmd routine for iscsid
>>
>>
>> dmesg shows:
>> interface icl.1 already present in the KLD 'kernel'!
>> linker_load_file: Unsupported file type
>>
>>
>> And also it seems that iscsi is actually already loaded:
>>
>> sudo kldstat -v | grep isci
>> 470 pci/isci
>>
>>
>> Any help is appreciated.
>>
>>
>>
> isci is the intel SAS driver, not iscsi (confusing name)

Opps, you're right about that sorry.

> 
> The problem appears to be that the iscsi module you have is not the same
> version as your kernel, try updating to ALPHA5
> 

Hum, doesn't seems to be the case, but I doesn't hurt trying ALPHA 5 I
guess/hope!
___
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 10 and zfsd

[Lyndon Nerenberg]

On 2013-10-10, at 2:54 PM, Allan Jude  wrote:

> I've been working on the handbook section on ZFS and made certain to
> mention that, I'll have to look at improving the man page as well, but
> as far as I know, the man page is imported from IllumOS, where spares do
> work.

This is probably worthy of an in-tree man page update.  FreeBSD has a 
reputation for having highly accurate man pages, therefore people tend to take 
what they read as gospel.  Right now zpool(8) clearly spells out that hot spare 
substitution works.  When 10.0 goes live, people are going to believe that, and 
unknowingly put themselves in a position where Bad Things could happen.  Until 
zfsd goes into the tree, zpool(8) should have a warning that the hot spare 
functionality is not available under FreeBSD.

Proposed diff attached.

--lyndon

Index: zpool.8
===
--- zpool.8 (revision 255198)
+++ zpool.8 (working copy)
@@ -283,6 +283,7 @@
 For more information, see the
 .Qq Sx Hot Spares
 section.
+.Sy "(The hot spare functionality is not currently implemented on FreeBSD.)"
 .It Sy log
 A separate-intent log device. If more than one log device is specified, then
 writes are load-balanced between devices. Log devices can be mirrored. However,
@@ -425,6 +426,8 @@
 attempts to put the device online automatically. Device attach detection is
 hardware-dependent and might not be supported on all platforms.
 .Ss Hot Spares
+.Sy "(The hot spare functionality is not currently implemented on FreeBSD.)"
+.Pp
 .Tn ZFS
 allows devices to be associated with pools as
 .Qq hot spares .
@@ -1946,3 +1949,6 @@
 .Xr mdoc 7
 implementation of this manual page was initially written by
 .An Martin Matuska Aq m...@freebsd.org .
+.Sh BUGS
+Hot spare substitution awaits the import of
+.Xr zfsd 8 .


___
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: undefined reference to xenpci_alloc_space

[Justin T. Gibbs]

On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen  wrote:

> Hi List,
> 
> is it intended that kernel does not build if
> 
> device xenpci
> 
> is omitted in the kernel config? I get the following error:
> 
> linking kernel
> gnttab.o: In function `gnttab_resume':
> /usr/src/sys/xen/gnttab.c:(.text+0xe47): undefined reference to 
> `xenpci_alloc_space'
> 
> Thanks,
>  Michael
> ___
> 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"
> 

XENHVM depends on xenpci, so you must remove XENHVM if you remove
xenpci.  Perhaps we should make a change similar to the attached
patch in order to make this clear?

--
Justin



GENERIC.diff
Description: Binary data
___
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: X related ports not finding version strings and hanging

[Kevin Oberman]

On Mon, Oct 7, 2013 at 1:34 PM, Warren Block  wrote:

> On Sun, 6 Oct 2013, Kevin Oberman wrote:
>
>  As usual with such upgrades, pkg_libchk is your friend. Assuming you have
>> updated pixman:
>> portmaster graphics/libGL graphics/dri
>> pkg_libchk -o | grep pixman | cut -d: -f1 | sort | uniq > pixman-files.txt
>> portmaster =D `cat pixman-files.txt`
>> portmaster -aD
>> portmaster -y -clean-distfiles
>>
>
> pkg_libchk -q > /tmp/to-be-rebuilt.txt
> portmaster `cat /tmp/to-be-rebuilt.txt`
>
> worked for me, although I did it after following the pixman instructions
> in /usr/ports/UPDATING.
>

Cool! I have somehow missed the real value of the '-q' option.

Thanks!
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
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: undefined reference to xenpci_alloc_space

[Michael Schmiedgen]

On 10/11/13 05:39, Justin T. Gibbs wrote:

On Oct 10, 2013, at 12:40 PM, Michael Schmiedgen  wrote:


is it intended that kernel does not build if

device xenpci

is omitted in the kernel config? I get the following error:

linking kernel
gnttab.o: In function `gnttab_resume':
/usr/src/sys/xen/gnttab.c:(.text+0xe47): undefined reference to 
`xenpci_alloc_space'

Thanks,
  Michael


XENHVM depends on xenpci, so you must remove XENHVM if you remove
xenpci.  Perhaps we should make a change similar to the attached
patch in order to make this clear?



Arghh, my fault. I did not inspect changes to kernel config
carefully enough. Thanks for the hint.

  Michael


___
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"