hi
http://abc777pills.pisem.su ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: A very big Thank You for the inclusion of ZFS
I'm in no way responsible for ZFS, but I wanted to let you know that emails like this are very very awesome to get. Thank you for the kind words, it does make FreeBSD development worthwhile when someone takes the time to send in kind words. -Alfred * Freddie Cash [090526 12:35] wrote: > I just wanted to send out a very big THANK YOU to all those who have > had a hand in bringing ZFS to FreeBSD. You've done a wonderful job. > > With the release of FreeBSD 7.2, things have improved to the point > where I can't crash our storage servers anymore (and I've tried all > the things that would crash 7.0 and 7.1). Bravo! > > What impressed me even more, though, was just how performant a > multiple raidz2 pool could be. During a normal backup run (rsync of > 105 servers each night), we graph sustained reads of 80 MBytes/sec and > writes of 50 MBytes/sec (via snmpd). Nothing too spectacular, but > still quite nice. Didn't realise just how much of a bottleneck the > remote network connections are, though. > > Doing a local iozone benchmark, using a command-line someone posted > online as known to crash ZFS on FreeBSD 7.0, I was able to get just > under 350 MBytes/sec sustained write throughput (as shown by snmpd) > with over 15 MBytes/sec per drive (as shown by gstat). Fiddling with > the iozone options, I was able to push that to over 400 MBytes/sec > sustained write with just shy of 20 MBytes/sec per drive. And CPU > utilisation never went above 40% per core. System never crashed, > hung, locked up, of even seemed slow while connected via SSH. > > While those numbers may not seem all that high to some people, for us, > those are amazing!! :) (We've never used SCSI, or RAID0, or RAID10, > or FibreChannel, or any of the other fancy storage stuff that gives > uber-high stats.) This gives us hope for just how many remote sites > we'll be able to backup to these storage servers (ie still lots of > headroom on the storage side, just need to boost the network side of > things). > > For the curious, the hardware is: > Tyan h2000M motherboard > 2x dual-core AMD Opteron 2220 CPUs at 2.8 GHz > 8 GB ECC DDR2-667 SDRAM > 3Ware 9650SE-12ML PCIe RAID controller > 3Ware 9550SXU-12ML PCI-X RAID controller (64-bit/133 MHz slot) > 24x 500 GB WD SATA2 harddrives (12 per controller, configured as > Single Drives) > 4-port Intel Pro/1000MT PCIe NIC > > The software is: > 64-bit FreeBSD 7.2-RELEASE > no kmem tuning > ZFS ARC limited to 1 GB via /boot/loader.conf > test filesystem has no compression and no atime set > > Pool configuration: > 3 raidz2 vdevs of 8 drives each (1 vdev uses 4-drives from each RAID > controller, the other 2 vdevs use 8 drives from 1 controller) > > iozone commands: > iozone -M -e -+u -T -t 128 -S 4096 -L 64 -r 4k -s 40g -i 0 -i 1 -i 2 > -i 8 -+p 70 -C (350 MBytes/sec writes) > iozone -M -e -+u -T -t 128 -r 128k -s 4g -i 0 -i 1 -i 2 -i 8 -+p 70 > -C (400 MBytes/sec write) > > -- > Freddie Cash > fjwc...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I've borked my ZFS system upgrading to -STABLE
On Thu, 28 May 2009, Ruben van Staveren wrote: On 28 mei 2009, at 19:33, Niki Denev wrote: Just curious... doesn't a "zfs upgrade -a" do the same thing? The zpool upgrade is just for the pools, but the filesystems keep their original settings so we need to do that in a seperate move There is both a zpool upgrade and a zfs upgrade command. The zfs upgrade does the filesystems, and the zpool upgrade does the pool. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I've borked my ZFS system upgrading to -STABLE
On 28 mei 2009, at 19:33, Niki Denev wrote: Just curious... doesn't a "zfs upgrade -a" do the same thing? The zpool upgrade is just for the pools, but the filesystems keep their original settings so we need to do that in a seperate move Regards, Niki Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS booting without partitions (was: ZFS boot on zfs mirror)
On 28.05.2009, at 21:46, Mickael MAILLOT wrote: hi, did you erase gmirror meta ? (on the last sector) with: gmirror clear ad6 ohps I had forgotten that. just did it (in single user mode), but it didn't help :( Shall I repeat any of the other steps after clearing gmirror meta? thanx a lot for your help... Lorenzo 2009/5/28 Lorenzo Perone : Hi, I tried hard... but without success ;( the result is, when choosing the disk with the zfs boot sectors in it (in my case F5, which goes to ad6), the kernel is not found. the console shows: forth not found definitions not found only not found (the above repeated several times) can't load 'kernel' and I get thrown to the loader prompt. lsdev does not show any ZFS devices. Strange thing: if I boot from the other disk, F1, which is my ad4 containing the normal ufs system I used to make up the other one, and escape to the loader prompt, lsdev actually sees the zpool which is on the other disk, and shows: zfs0: tank I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, but there I get the panic: free: guard1 fail message. (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) Sure I'm doing something wrong, but what...? Is it a problem that the pool is made out of the second disk only (ad6)? Here are my details (note: latest stable and biosdisk.c merged with changes shown in r185095. no problems in buildworld/kernel): () ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS booting without partitions (was: ZFS boot on zfs mirror)
hi, did you erase gmirror meta ? (on the last sector) with: gmirror clear ad6 2009/5/28 Lorenzo Perone : > Hi, > > I tried hard... but without success ;( > > the result is, when choosing the disk with the zfs boot > sectors in it (in my case F5, which goes to ad6), the kernel > is not found. the console shows: > > forth not found > definitions not found > only not found > (the above repeated several times) > > can't load 'kernel' > > and I get thrown to the loader prompt. > lsdev does not show any ZFS devices. > > Strange thing: if I boot from the other disk, F1, which is my > ad4 containing the normal ufs system I used to make up the other > one, and escape to the loader prompt, lsdev actually sees the > zpool which is on the other disk, and shows: > zfs0: tank > > I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, > but there I get the panic: free: guard1 fail message. > (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) > > Sure I'm doing something wrong, but what...? Is it a problem that > the pool is made out of the second disk only (ad6)? > > Here are my details (note: latest stable and biosdisk.c merged > with changes shown in r185095. no problems in buildworld/kernel): > > > > Machine: p4 4GHz 4 GB RAM (i386) > > Note: the pool has actually a different name (heidi > instead of tank, if this can be of any relevance...), > just using tank here as it's one of the conventions... > > mount (just to show my starting situation) > > /dev/mirror/gm0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) > /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) > /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) > > gmirror status > Name Status Components > mirror/gm0 DEGRADED ad4 > (ad6 used to be the second disk...) > > echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf > > cd /usr/src > make buildworld && make buildkernel KERNCONF=HEIDI > make installkernel KERNCONF=HEIDI > mergemaster > make installworld > shutdown -r now > > dd if=/dev/zero of=/dev/ad6 bs=512 count=32 > > zpool create tank ad6 > zfs create tank/usr > zfs create tank/var > zfs create -V 4gb tank/swap > zfs set org.freebsd:swap=on tank/swap > zpool set bootfs=tank tank > > rsync -avx / /tank > rsync -avx /usr/ /tank/usr > rsync -avx /var/ /tank/var > cd /usr/src > make installkernel KERNCONF=HEIDI DESTDIR=/tank > > zpool export tank > > dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 > > zpool import tank > > zfs set mountpoint=legacy tank > zfs set mountpoint=/usr tank/usr > zfs set mountpoint=/var tank/var > > shutdown -r now ... > > at the 'mbr prompt' I pressed F5 (the second disk, ad6) > .. as written above, loader gets loaded (at this stage > I suppose it's the stuff dd't after block 1024?), > but kernel not found. > > /usr/src/sys/i386/conf/HEIDI: > (among other things...): > options KVA_PAGES=512 > > (/tank)/boot/loader.conf: > vm.kmem_size="1024M" > vm.kmem_size_max="1024M" > vfs.zfs.arc_max="128M" > vfs.zfs.vdev.cache.size="8M" > vfs.root.mountfrom="zfs:tank" > > (/tank)/etc/fstab: > # Device Mountpoint FStype Options Dump > Pass# > tank / zfs rw 0 0 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > > > > any help is welcome... don't know where to go from here right now. > > BTW: I can't stop thanking the team for the incredible > pace at which bugs are fixed these days! > > > Regards, > > Lorenzo > > > > On 26.05.2009, at 18:42, George Hartzell wrote: > >> Andriy Gapon writes: >>> >>> on 26/05/2009 19:21 George Hartzell said the following: Dmitry Morozovsky writes: > > On Tue, 26 May 2009, Mickael MAILLOT wrote: > > MM> Hi, > MM> > MM> i prefere use zfsboot boot sector, an example is better than a long > talk: > MM> > MM> $ zpool create tank mirror ad4 ad6 > MM> $ zpool export tank > MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 > MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 > MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 > MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 > > s/skeep/skip/ ? ;-) What is the reason for copying zfsboot one bit at a time, as opposed to dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 >>> >>> seek=1024 for the second part? and no 'count=1' for it? :-) >>> >>> [Just guessing] Apparently the first block of zfsboot is some form of MBR >>> and the >>> rest is zfs-specific code that goes to magical sector 1024. >> >> Ok, I managed to read the argument to seek as "one block", apparently >> my coffee hasn't hit yet. >> >> I'm still confused about the two parts of zfsboot and what's magical >> about seeking to 1024. >> >> g. >> >> ___ >> freebsd-stable@freebsd.org m
Re: RFC: side effects of fixing loader_conf_files handling
On Wed, Jan 21, 2009 at 4:39 PM, Andrew Thompson wrote: > That sounds good, thanks for working on this. Hi All, With this change it seems that if /boot/loader.conf is not present the loader stops altogether at |. Was that the desired effect of these changes? It is not a big deal for me to touch the files during build but wanted to make sure that this was the desired effect. Thanks Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PXE boot FreeBSD without need of NFS server
On Thu, May 28, 2009 at 09:10:50AM +0200, Mikael Bak wrote: > Pertti, András, > Thank You for the useful links! > Kiitos and Köszönöm szépen :-) > > Gót András wrote: > > Hi, > > > > AFAIK only the kernel and initrd (in the linux case) can be booted from > > tftp, that's a PXE feature. When the kernel loaded it takes over and from > > then on the kernel will need a rootfs from somewhere. I don't think that a > > tftp rootfs is possible. > > > > Yes, I know it's not possible to have the rootfs on tftp. That is not my > goal. I only wish to host an image file containing a rootfs that will > act as a ram disk. Much like the initrd does in the Linux world. The > rootfs will only contain the things needed to start the installation > process. Have a look at ThinBSD. It a mini FreeBSD-5.x system which uses a ramdisk image as root. It can be booted from a TFTP server, without NFS. The web site is here: http://thinbsd.zefyris.com/ I use it everyday to run a X terminal. -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS issue?
I updated my stable box (i386) on Tuesday and started seeing errors like the below intermittently. Is anyone else seeing anything like this? I saw similar errors periodically doing portupgrade and portinstall. Besides the intermittent errors the stability is much improved, my i386 box hasn't crashed at all since the update. Previously I could crash the box fairly reproducibly. Thanks, Brad mv: /home/bdutton/email/spam/cur/1243427579.M855387P56232VCB777092I0003F135_0.uno,S=4010:2,S: set owner/group (was: 1000/89): Operation not permitted mv: /home/bdutton/email/spam/cur/1243427579.M855387P56232VCB777092I0003F135_0.uno,S=4010:2,S: set flags (was: ): Invalid argument mv: /home/bdutton/email/spam/cur/1243428013.M780180P56404VCB777092I0003F139_0.uno,S=3330:2,S: set owner/group (was: 1000/89): Operation not permitted mv: /home/bdutton/email/spam/cur/1243428013.M780180P56404VCB777092I0003F139_0.uno,S=3330:2,S: set flags (was: ): Invalid argument ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I've borked my ZFS system upgrading to -STABLE
On Thu, May 28, 2009 at 11:47 AM, Ruben van Staveren wrote:
>
> On 27 May 2009, at 22:44, Kevin Day wrote:
>
>> tries to do a chflags on it, fails because ZFS doesn't support flags
>
>
> are the pools already upgraded to v13 ? if not please do so with zpool
> upgrade -a
>
> Then in single user mode do
>
> zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
>
> flags should work now
>
>
> Regards,
> Ruben
Just curious... doesn't a "zfs upgrade -a" do the same thing?
Regards,
Niki
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: I've borked my ZFS system upgrading to -STABLE
on 28/05/2009 11:47 Ruben van Staveren said the following:
>
> On 27 May 2009, at 22:44, Kevin Day wrote:
>
>> tries to do a chflags on it, fails because ZFS doesn't support flags
>
>
> are the pools already upgraded to v13 ? if not please do so with zpool
> upgrade -a
>
> Then in single user mode do
>
> zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
>
> flags should work now
Big thanks for the recipe!
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic in zfs_fuid_create
on 27/05/2009 19:25 Lawrence Farr said the following: > I updated my backup boxes to the latest and greatest ZFS code, > and started getting the following panic on them all (3 machines): > > panic: zfs_fuid_create > cpuid = 1 > Uptime: 1h28m48s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort > > A quick google found kern/133020 with a patch from PJD that has fixed > it for me. Should it be in stable or does it break something else? Hmm I wonder if you really do have UIDs or GIDs greater than 2147483647 defined on your system? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [releng_7 tinderbox] failure on amd64/amd64
On Thu, May 28, 2009 at 09:15:38AM -0400, FreeBSD Tinderbox wrote: > TB --- 2009-05-28 11:26:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2009-05-28 11:26:51 - starting RELENG_7 tinderbox run for amd64/amd64 > TB --- 2009-05-28 11:26:51 - cleaning the object tree > TB --- 2009-05-28 11:27:23 - cvsupping the source tree > TB --- 2009-05-28 11:27:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s > /tinderbox/RELENG_7/amd64/amd64/supfile > /src/sys/compat/linux/linux_mib.c: In function 'linux_kernver': > /src/sys/compat/linux/linux_mib.c:267: warning: 'osrel' may be used > uninitialized in this function > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > ughh, fixed by r192981. Im sorry. -- Have fun! chd pgpei8VGudlrQ.pgp Description: PGP signature
Re: ZFS MFC heads down
Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. --- clipped --- By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? I find the answer to this question and think it may be really useful to others: zdb -C [ -U ] Henri Henri Thanks, Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS MFC heads down
Andriy Gapon wrote: on 28/05/2009 16:26 Henri Hennebert said the following: (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 I find the above part interesting. Could this be because of the following discrepancy: 1) cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: extern void __assert(const char *, const char *, int); 2) lib/libc/gen/assert.c: void __assert(func, file, line, failedexpr) const char *func, *file; int line; const char *failedexpr; #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 But back to the problem - without an additional printf we still can not what was the value in m_owner. Only that it was not null. Probably it's better to build with debugging symbols and examine with gdb. Firt try: [r...@avoriaz libzpool]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100299] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100299)] [New Thread 0x801802240 (LWP 100354)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100369)] [New Thread 0x801802560 (LWP 100370)] [New Thread 0x8018026f0 (LWP 100371)] [New Thread 0x801802880 (LWP 100372)] [New Thread 0x801802a10 (LWP 100376)] [New Thread 0x801802ba0 (LWP 100382)] [New Thread 0x801802d30 (LWP 100383)] [New Thread 0x801802ec0 (LWP 100384)] [New Thread 0x801803050 (LWP 100385)] [New Thread 0x8018031e0 (LWP 100386)] [New Thread 0x801803370 (LWP 100387)] [New Thread 0x801803500 (LWP 100388)] [New Thread 0x801803690 (LWP 100389)] [New Thread 0x801803820 (LWP 100390)] [New Thread 0x8018039b0 (LWP 100391)] [New Thread 0x801803b40 (LWP 100392)] [New Thread 0x801803cd0 (LWP 100393)] [New Thread 0x801803e60 (LWP 100394)] [New Thread 0x801803ff0 (LWP 100395)] [New Thread 0x801804180 (LWP 100396)] [New Thread 0x801804310 (LWP 100397)] [New Thread 0x8018044a0 (LWP 100398)] [New Thread 0x801804630 (LWP 100399)] [New Thread 0x8018047c0 (LWP 100400)] [New Thread 0x801804950 (LWP 100401)] [New Thread 0x801804ae0 (LWP 100402)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100299)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 #6 0x000800fef230 in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #7 0x00080102e2b0 in dsl_dataset
Re: [releng_7 tinderbox] failure on i386/i386
on 28/05/2009 16:56 FreeBSD Tinderbox said the following: > /src/sys/compat/linux/linux_mib.c: In function 'linux_kernver': > /src/sys/compat/linux/linux_mib.c:267: warning: 'osrel' may be used > uninitialized in this function > *** Error code 1 I agree :-) So what would osrel be if pr != NULL but pr->pr_linux == NULL ? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS booting without partitions (was: ZFS boot on zfs mirror)
Hi, I tried hard... but without success ;( the result is, when choosing the disk with the zfs boot sectors in it (in my case F5, which goes to ad6), the kernel is not found. the console shows: forth not found definitions not found only not found (the above repeated several times) can't load 'kernel' and I get thrown to the loader prompt. lsdev does not show any ZFS devices. Strange thing: if I boot from the other disk, F1, which is my ad4 containing the normal ufs system I used to make up the other one, and escape to the loader prompt, lsdev actually sees the zpool which is on the other disk, and shows: zfs0: tank I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel, but there I get the panic: free: guard1 fail message. (would boot zfs:tank:/boot/kernel/kernel be correct, anyways?) Sure I'm doing something wrong, but what...? Is it a problem that the pool is made out of the second disk only (ad6)? Here are my details (note: latest stable and biosdisk.c merged with changes shown in r185095. no problems in buildworld/kernel): Machine: p4 4GHz 4 GB RAM (i386) Note: the pool has actually a different name (heidi instead of tank, if this can be of any relevance...), just using tank here as it's one of the conventions... mount (just to show my starting situation) /dev/mirror/gm0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates) /dev/mirror/gm0s1f on /usr (ufs, local, soft-updates) /dev/mirror/gm0s1d on /var (ufs, local, soft-updates) gmirror status NameStatus Components mirror/gm0 DEGRADED ad4 (ad6 used to be the second disk...) echo 'LOADER_ZFS_SUPPORT=yes' >> /etc/make.conf cd /usr/src make buildworld && make buildkernel KERNCONF=HEIDI make installkernel KERNCONF=HEIDI mergemaster make installworld shutdown -r now dd if=/dev/zero of=/dev/ad6 bs=512 count=32 zpool create tank ad6 zfs create tank/usr zfs create tank/var zfs create -V 4gb tank/swap zfs set org.freebsd:swap=on tank/swap zpool set bootfs=tank tank rsync -avx / /tank rsync -avx /usr/ /tank/usr rsync -avx /var/ /tank/var cd /usr/src make installkernel KERNCONF=HEIDI DESTDIR=/tank zpool export tank dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024 zpool import tank zfs set mountpoint=legacy tank zfs set mountpoint=/usr tank/usr zfs set mountpoint=/var tank/var shutdown -r now ... at the 'mbr prompt' I pressed F5 (the second disk, ad6) .. as written above, loader gets loaded (at this stage I suppose it's the stuff dd't after block 1024?), but kernel not found. /usr/src/sys/i386/conf/HEIDI: (among other things...): options KVA_PAGES=512 (/tank)/boot/loader.conf: vm.kmem_size="1024M" vm.kmem_size_max="1024M" vfs.zfs.arc_max="128M" vfs.zfs.vdev.cache.size="8M" vfs.root.mountfrom="zfs:tank" (/tank)/etc/fstab: # DeviceMountpoint FStype Options DumpPass# tank/ zfs rw 0 0 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 any help is welcome... don't know where to go from here right now. BTW: I can't stop thanking the team for the incredible pace at which bugs are fixed these days! Regards, Lorenzo On 26.05.2009, at 18:42, George Hartzell wrote: Andriy Gapon writes: on 26/05/2009 19:21 George Hartzell said the following: Dmitry Morozovsky writes: On Tue, 26 May 2009, Mickael MAILLOT wrote: MM> Hi, MM> MM> i prefere use zfsboot boot sector, an example is better than a long talk: MM> MM> $ zpool create tank mirror ad4 ad6 MM> $ zpool export tank MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1 MM> $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1 seek=1024 MM> $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1 seek=1024 s/skeep/skip/ ? ;-) What is the reason for copying zfsboot one bit at a time, as opposed to dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2 seek=1024 for the second part? and no 'count=1' for it? :-) [Just guessing] Apparently the first block of zfsboot is some form of MBR and the rest is zfs-specific code that goes to magical sector 1024. Ok, I managed to read the argument to seek as "one block", apparently my coffee hasn't hit yet. I'm still confused about the two parts of zfsboot and what's magical about seeking to 1024. g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Slow detection of Dell SAS 6i/R aka LSILogic SAS/SATA Adapter (mpt0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm not sure if I should have sent this to freebsd-questions@, but here we go. I have a couple of Dell PowerEdge R200 rack servers, both equipped with the Dell SAS 6i/R RAID controller, running i386 7.2-RELEASE but they'll soon be upgraded to i386 7.2-STABLE. The mpt driver spends a minute or so eager to initialize the controller, but fails with the following messages: mpt0: port 0xec00-0xecff mem 0xdfbec000-0xdfbe,0xdfbf-0xdfbf irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.18.0 mpt0: mpt_wait_req(6) timed out mpt0: port 0 enable timed out mpt0: failed to enable port 0 mpt0: unable to initialize IOC The virtual disk comprised of two SAS disks is recognized as the following: da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 285568MB (584843264 512 byte sectors: 255H 63S/T 36404C) Is there a way to get rid of the slow and failing initialization? I'd be happy to try out patches or even allow shell access. Complete dmesg output is available on demand. I can arrange for a verbose dmesg output if verbose booting is still an option. I can't remember the last time I attempted a verbose (re)boot. Trond. - -- - -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 6.2-STABLE & Pine 4.64 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFKHphmbYWZalUoElsRAkrPAJ96OGFn8wVayjIDEtZOC6Vf97ohMACcDBVY tX+dVBQ879/lhJsMYczOaOs= =B7sL -END PGP SIGNATURE-___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[releng_7 tinderbox] failure on i386/i386
TB --- 2009-05-28 12:33:50 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-28 12:33:50 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2009-05-28 12:33:50 - cleaning the object tree TB --- 2009-05-28 12:34:13 - cvsupping the source tree TB --- 2009-05-28 12:34:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2009-05-28 12:34:23 - building world TB --- 2009-05-28 12:34:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 12:34:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 12:34:23 - TARGET=i386 TB --- 2009-05-28 12:34:23 - TARGET_ARCH=i386 TB --- 2009-05-28 12:34:23 - TZ=UTC TB --- 2009-05-28 12:34:23 - __MAKE_CONF=/dev/null TB --- 2009-05-28 12:34:23 - cd /src TB --- 2009-05-28 12:34:23 - /usr/bin/make -B buildworld >>> World build started on Thu May 28 12:34:25 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu May 28 13:40:58 UTC 2009 TB --- 2009-05-28 13:40:58 - generating LINT kernel config TB --- 2009-05-28 13:40:58 - cd /src/sys/i386/conf TB --- 2009-05-28 13:40:58 - /usr/bin/make -B LINT TB --- 2009-05-28 13:40:59 - building LINT kernel TB --- 2009-05-28 13:40:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 13:40:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 13:40:59 - TARGET=i386 TB --- 2009-05-28 13:40:59 - TARGET_ARCH=i386 TB --- 2009-05-28 13:40:59 - TZ=UTC TB --- 2009-05-28 13:40:59 - __MAKE_CONF=/dev/null TB --- 2009-05-28 13:40:59 - cd /src TB --- 2009-05-28 13:40:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 28 13:40:59 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -W
Re: ZFS MFC heads down
on 28/05/2009 16:26 Henri Hennebert said the following: > (gdb) bt > #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 > #1 0x0008012a0feb in open () from /lib/libc.so.7 > #2 0x00080129ea59 in open () from /lib/libc.so.7 > #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 > #4 0x000801291158 in fprintf () from /lib/libc.so.7 > #5 0x000801290fb0 in __assert () from /lib/libc.so.7 I find the above part interesting. Could this be because of the following discrepancy: 1) cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: extern void __assert(const char *, const char *, int); 2) lib/libc/gen/assert.c: void __assert(func, file, line, failedexpr) const char *func, *file; int line; const char *failedexpr; > #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 > #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 > #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 > #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 > #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 > #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 > #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 But back to the problem - without an additional printf we still can not what was the value in m_owner. Only that it was not null. Probably it's better to build with debugging symbols and examine with gdb. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
zdb core (same problem?)
Hi! > Adding to rw_init looks fine, but I'd rather find out why owner isn't > NULL when the calling convention expects it. Getting a backtrace from > where the assert is hit would be helpful. I have another zdb mypool crash on a 7.2-STABLE. f7# zpool history mypool History for 'mypool': 2009-05-24.21:58:36 zpool create -m /spare1 mypool ad4s3d 2009-05-24.22:11:35 zfs set compression=on mypool 2009-05-25.08:07:04 zpool upgrade -a 2009-05-27.22:31:21 zpool scrub mypool 2009-05-27.22:31:26 zpool scrub mypool For a gdb with backtrace see http://opsec.eu/backup/zdb-backtrace -- p...@opsec.eu+49 171 310137211 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS MFC heads down
Kip Macy wrote: On Wed, May 27, 2009 at 11:04 AM, Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. --Artem Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 Is it useful ? [r...@avoriaz ~]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r rpool Starting program: /usr/sbin/zdb rpool (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100343] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100343)] [New Thread 0x801802240 (LWP 100346)] version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100347)] [New Thread 0x801802560 (LWP 100354)] [New Thread 0x8018026f0 (LWP 100355)] [New Thread 0x801802880 (LWP 100356)] [New Thread 0x801802a10 (LWP 100359)] [New Thread 0x801802ba0 (LWP 100360)] [New Thread 0x801802d30 (LWP 100368)] [New Thread 0x801802ec0 (LWP 100369)] [New Thread 0x801803050 (LWP 100370)] [New Thread 0x8018031e0 (LWP 100371)] [New Thread 0x801803370 (LWP 100372)] [New Thread 0x801803500 (LWP 100373)] [New Thread 0x801803690 (LWP 100374)] [New Thread 0x801803820 (LWP 100375)] [New Thread 0x8018039b0 (LWP 100376)] [New Thread 0x801803b40 (LWP 100377)] [New Thread 0x801803cd0 (LWP 100378)] [New Thread 0x801803e60 (LWP 100379)] [New Thread 0x801803ff0 (LWP 100380)] [New Thread 0x801804180 (LWP 100381)] [New Thread 0x801804310 (LWP 100382)] [New Thread 0x8018044a0 (LWP 100383)] [New Thread 0x801804630 (LWP 100384)] [New Thread 0x8018047c0 (LWP 100385)] [New Thread 0x801804950 (LWP 100386)] [New Thread 0x801804ae0 (LWP 100387)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100343)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0008012a6f22 in strlen () from /lib/libc.so.7 #1 0x0008012a0feb in open () from /lib/libc.so.7 #2 0x00080129ea59 in open () from /lib/libc.so.7 #3 0x0008012a1f2e in vfprintf () from /lib/libc.so.7 #4 0x000801291158 in fprintf () from /lib/libc.so.7 #5 0x000801290fb0 in __assert () from /lib/libc.so.7 #6 0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 #7 0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 #8 0x000801045ffa in dbuf_find () from /lib/libzpool.so.1 #9 0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1 #13 0x00408b41 in ?? () #14 0x004036de in ?? () #15 0x000800534000 in ?? () #16 0x in ?? () #17 0x0002 in ?? () #18 0x7fffed70 in ?? () #19 0x7fffed7e in ?? () #20 0x in ?? () #21 0x7fffed84 in ?? () #22 0x7fffed9a in ?? () #23 0x7fffeda5 in ?? () #24 0x7fffedbf in ?? () #25 0x7fffedea in ?? () #26 0x7
[releng_7 tinderbox] failure on amd64/amd64
TB --- 2009-05-28 11:26:51 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-05-28 11:26:51 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2009-05-28 11:26:51 - cleaning the object tree TB --- 2009-05-28 11:27:23 - cvsupping the source tree TB --- 2009-05-28 11:27:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2009-05-28 11:27:32 - building world TB --- 2009-05-28 11:27:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 11:27:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 11:27:32 - TARGET=amd64 TB --- 2009-05-28 11:27:32 - TARGET_ARCH=amd64 TB --- 2009-05-28 11:27:32 - TZ=UTC TB --- 2009-05-28 11:27:32 - __MAKE_CONF=/dev/null TB --- 2009-05-28 11:27:32 - cd /src TB --- 2009-05-28 11:27:32 - /usr/bin/make -B buildworld >>> World build started on Thu May 28 11:27:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu May 28 13:00:57 UTC 2009 TB --- 2009-05-28 13:00:57 - generating LINT kernel config TB --- 2009-05-28 13:00:57 - cd /src/sys/amd64/conf TB --- 2009-05-28 13:00:57 - /usr/bin/make -B LINT TB --- 2009-05-28 13:00:57 - building LINT kernel TB --- 2009-05-28 13:00:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-28 13:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-28 13:00:57 - TARGET=amd64 TB --- 2009-05-28 13:00:57 - TARGET_ARCH=amd64 TB --- 2009-05-28 13:00:57 - TZ=UTC TB --- 2009-05-28 13:00:57 - __MAKE_CONF=/dev/null TB --- 2009-05-28 13:00:57 - cd /src TB --- 2009-05-28 13:00:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu May 28 13:00:57 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4
Re: I've borked my ZFS system upgrading to -STABLE
On 27 May 2009, at 22:44, Kevin Day wrote:
tries to do a chflags on it, fails because ZFS doesn't support flags
are the pools already upgraded to v13 ? if not please do so with zpool
upgrade -a
Then in single user mode do
zfs list -H | awk '{print $1}' | xargs -n 1 zfs set version=3
flags should work now
Regards,
Ruben
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader not working with GPT and LOADER_ZFS_SUPPORT
On 28 May 2009, at 9:40, Kip Macy wrote: MFC'd in 192969 Thanks for the explanation and all the hard work! Kind Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS on ZFS
The flags checks are too strict. File a PR. I'll fix it when I get to it. Sorrry. -Kip On Wed, May 27, 2009 at 7:24 PM, Mike Andrews wrote: > On Tue, 26 May 2009, Mike Andrews wrote: > >> Takahashi Yoshihiro wrote: >>> >>> Today's stable has a problem creating a new file via NFS on ZFS. >>> >>> On the NFS server, there is no problem. >>> >>> % cd /ZFS >>> % mktemp hoge >>> hoge >>> % ls -l hoge >>> -rw--- 1 nyan nyan 0 5 26 19:09 hoge >>> >>> >>> But it's a problem on the NFS client. >>> >>> # mount server:/ZFS /ZFS >>> % cd /ZFS >>> % mktemp hoge >>> mktemp: mkstemp failed on hoge: Input/output error >>> % ls -l hoge >>> -- 1 nyan wheel 0 5 26 19:09 hoge >>> >>> The file has a wrong permission. >>> >>> This problem is only on stable, current has no problem. >> >> I'm seeing this too. It seems so far to be limited to mkstemp() -- just >> copying files normally works. For example /usr/bin/install -S fails, >> without -S works, if the target is an NFS+ZFS volume. > > Anyone? > > I've verified that if the NFS server uses UFS2, mkstemp() from an NFS > client to the server works fine, but if the NFS server uses ZFS, the NFS > server returns EIO after creating a file with 000 permissions. > > In addition to breaking /usr/bin/install -S, it also breaks rsync over NFS. > > I don't yet know if it matters whether the on-disk format is ZFS v6 vs v13. > > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS MFC heads down
On Wed, May 27, 2009 at 11:04 AM, Artem Belevich wrote: > I had the same problem on -current. Try attached patch. It may not > apply cleanly on -stable, but should be easy enough to make equivalent > changes on -stable. > > --Artem > Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip > > > On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert wrote: >> Kip Macy wrote: >>> >>> On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. >>> >>> >>> The MFC went in r192498. Please let me know if you have any problems. >> >> No a real problem but maybe worth mentioning: >> >> on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 >> 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE >> i386 >> >> [r...@morzine ~]# zdb rpool >> version=13 >> name='rpool' >> state=0 >> txg=959 >> pool_guid=17669857244588609348 >> hostid=2315842372 >> hostname='unset' >> vdev_tree >> type='root' >> id=0 >> guid=17669857244588609348 >> children[0] >> type='mirror' >> id=0 >> guid=3225603179255348056 >> metaslab_array=23 >> metaslab_shift=28 >> ashift=9 >> asize=51534888960 >> is_log=0 >> children[0] >> type='disk' >> id=0 >> guid=17573085726489368265 >> path='/dev/da0p2' >> whole_disk=0 >> children[1] >> type='disk' >> id=1 >> guid=2736169600077218893 >> path='/dev/da1p2' >> whole_disk=0 >> Assertion failed: (?Ąuč? ėŪ¨´&), function mp->m_owner == NULL, file >> /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, >> line 112. >> Abort trap: 6 >> >> >> and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May >> 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ >> amd64 >> >> [r...@avoriaz ~]# zdb rpool >> version=13 >> name='rpool' >> state=0 >> txg=3467 >> pool_guid=536117255064806899 >> hostid=1133576597 >> hostname='unset' >> vdev_tree >> type='root' >> id=0 >> guid=536117255064806899 >> children[0] >> type='mirror' >> id=0 >> guid=3124217685892976292 >> metaslab_array=23 >> metaslab_shift=30 >> ashift=9 >> asize=155741847552 >> is_log=0 >> children[0] >> type='disk' >> id=0 >> guid=11099413743436480159 >> path='/dev/ad4p2' >> whole_disk=0 >> children[1] >> type='disk' >> id=1 >> guid=12724983687805955432 >> path='/dev/ad6p2' >> whole_disk=0 >> Segmentation fault: 11 >> >> By the way, to help prepare a boot/root pool does a utility to display the >> content of zpool.cache exist ? >> >> >> Henri >>> >>> Thanks, >>> Kip >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: loader not working with GPT and LOADER_ZFS_SUPPORT
MFC'd in 192969
On Wed, May 27, 2009 at 3:31 PM, Artis Caune wrote:
> 2009/5/28 Lorenzo Perone :
>> Hi, I'm a bit confused:
>>
>> I can't find this change (rev 185095) in the stable log, yet stable has some
>> other
>> recent changes related to the current posts (in turn commited also to
>> head)...
>>
>> http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/libi386/biosdisk.c?view=log
>> http://svn.freebsd.org/viewvc/base/stable/7/sys/boot/i386/libi386/biosdisk.c?view=log
>>
>> maybe I'm misunderstanding how things eventually get ingto -stable,
>> however, which revision to use now for a peaceful world & boot? :)
>>
>> I'll go for the -head version for my next try..
>
>
> It's not merged to stable yet. You should apply r185095 diff by hand.
> Just edit "sys/boot/i386/libi386/biosdisk.c" and change:
>
>
> --- sys/boot/i386/libi386/biosdisk.c (revision 192872)
> +++ sys/boot/i386/libi386/biosdisk.c (working copy)
> @@ -996,8 +996,10 @@
> od->od_boff = gp->gp_start;
>
> out:
> - if (error)
> + if (error) {
> free(od->od_partitions);
> + od->od_flags &= ~BD_GPTOK;
> + }
> return (error);
> }
>
> @@ -1088,7 +1090,7 @@
>
> switch(rw){
> case F_READ:
> - DEBUG("read %d from %d to %p", blks, dblk, buf);
> + DEBUG("read %d from %lld to %p", blks, dblk, buf);
>
> if (blks && bd_read(od, dblk, blks, buf)) {
> DEBUG("read error");
>
>
>
>
> --
> Artis Caune
>
> Everything should be made as simple as possible, but not simpler.
>
--
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
Edmund Burke
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PXE boot FreeBSD without need of NFS server
Pertti, András, Thank You for the useful links! Kiitos and Köszönöm szépen :-) Gót András wrote: > Hi, > > AFAIK only the kernel and initrd (in the linux case) can be booted from > tftp, that's a PXE feature. When the kernel loaded it takes over and from > then on the kernel will need a rootfs from somewhere. I don't think that a > tftp rootfs is possible. > Yes, I know it's not possible to have the rootfs on tftp. That is not my goal. I only wish to host an image file containing a rootfs that will act as a ram disk. Much like the initrd does in the Linux world. The rootfs will only contain the things needed to start the installation process. I think I have the information I was looking for. Thanks again! Mikael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
