Re: netboot issues, 8.0, mfsroot mount failure
On Tue, Feb 16, 2010 at 10:47 PM, Charles Sprickman wrote: > Is this documented somewhere? > Here: http://www.nber.org/sys-admin/FreeBSD-diskless.html Whoever wrote that, thank you. -- Adam Vande More ___ 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: netboot issues, 8.0, mfsroot mount failure
On Tue, 16 Feb 2010, Garrett Cooper wrote: On Tue, Feb 16, 2010 at 5:28 PM, Charles Sprickman wrote: Howdy, I'm having some problems getting 8.0 to install over the network. I've got my dhcp, tftp and nfs server working well, and I've tested all three services from this host before attempting to boot over the network. pxeboot seems to work, and I see it get loaded via tftp. The kernel boots, and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD fileset: [r...@archive /home/spork/tmp]# cat /usr/local/netboot/freebsd8/boot/loader.conf mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" boot_multicons="YES" boot_serial="YES" console="comconsole,vidconsole" vfs.root.mountfrom="ufs:/dev/md0c" I see the kernel does find mfsroot and attaches it: md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 But then when it's ready to mount the root filesystem, I get this: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/md0c ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. It doesn't really state what the error is. It's hinting that it's read-only, but that seems odd. Even if it couldn't mount r/w, shouldn't it just drop to single-user at this point? Next it tries nfs: Trying to mount root from nfs: NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 em0: link state changed to UP And there it sits. Remotely I can't do anything. If I'm local, I can ctrl-alt-del a few times and then about a minute later it does an orderly restart. I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nfs traffic between the two hosts, which appears to be the client stat-ing a file or directory. tcpdump also shows some checksum errors, but I recall a few threads here mentioning that on Intel cards that generally is not a cause for concern. From another host, I have no issues mounting that nfs filesystem r/w: r...@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd8 /mntr...@h10[/home/spork]# ls /mnt/ .cshrc HARDWARE.TXT boot.catalog media sbin .profile README.HTM cdrom.inf mnt stand 8.0-RELEASE README.TXT dev packages sys COPYRIGHT RELNOTES.HTM docbook.css proc tmp ERRATA.HTM RELNOTES.TXT etc rescue usr ERRATA.TXT bin lib root var HARDWARE.HTM boot libexec rr_moved r...@h10[/home/spork]# touch /mnt/foo r...@h10[/home/spork]# rm /mnt/foo r...@h10[/home/spork]# umount /mnt Any ideas? I've got about a dozen remote boxes to upgrade, so I want to totally nail down this procedure. I've been putting off learning this for a few years, and now I've got an actual need for it. I'll be in your shoes in a little bit... I ran into some issues when I last tried with NFSv3 on a Solaris server so we'll see how things go in the second go-around [with a FreeBSD nfs rootfs server], In my case the server is FreeBSD (7.2). It's running with default nfsd flags, so I suppose it's offering both tcp and udp. No idea what version. It seems to work enough for the loader to fetch the loader files and kernel... but 7.x netbooted and 8.x didn't when I tried last; the 7.x images have some secret sauce fixes for PXE booting -- the ones I know of are as follows (apply to loader.conf as you feel fit): vfs.root.mountfrom="nfs" boot.nfsroot.path="/absolute/path/to/netboot/dir" boot.nfsroot.server="nfs-server-ip-addr" Is this documented somewhere? There were also some code changes made to `fix' netbooting with pxeloader, but I'm not sure if they're applicable or needed in 8.x, and I'm not sure what the actual changes are TBH... Ugh. With all these variables AND the general nuttiness of PC hardware I see many reboot cycles in my future. Charles Cheers, -Garrett ___ 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: netboot issues, 8.0, mfsroot mount failure
On Tue, 16 Feb 2010, Jeremy Chadwick wrote: On Tue, Feb 16, 2010 at 08:28:03PM -0500, Charles Sprickman wrote: Howdy, I'm having some problems getting 8.0 to install over the network. I've got my dhcp, tftp and nfs server working well, and I've tested all three services from this host before attempting to boot over the network. pxeboot seems to work, and I see it get loaded via tftp. The kernel boots, and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD fileset: [r...@archive /home/spork/tmp]# cat /usr/local/netboot/freebsd8/boot/loader.conf mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" boot_multicons="YES" boot_serial="YES" console="comconsole,vidconsole" vfs.root.mountfrom="ufs:/dev/md0c" I see the kernel does find mfsroot and attaches it: md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 But then when it's ready to mount the root filesystem, I get this: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/md0c ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. It doesn't really state what the error is. It's hinting that it's read-only, but that seems odd. Even if it couldn't mount r/w, shouldn't it just drop to single-user at this point? Next it tries nfs: Trying to mount root from nfs: NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 em0: link state changed to UP And there it sits. Remotely I can't do anything. If I'm local, I can ctrl-alt-del a few times and then about a minute later it does an orderly restart. We've been talking off-list about this (and other things), but at this point I'm pretty sure the problem is that the local slice naming convention has changed in RELENG_8 from what it was in RELENG_7. This is the cause/result of the "GEOM overhall" (or whatever it is; I don't know what to call it. Is it libdisk changes? GEOM? Both? I really don't know). Basically, the way the full size of the disk gets handled differs now from RELENG_7. (See footnote for "fun") So, try changing this: vfs.root.mountfrom="ufs:/dev/md0c" ...to this (look closely): vfs.root.mountfrom="ufs:/dev/md0" I made the change on the server, but the box is stuck until I can get over there again. Serial consoles are nice, but not being able to send "ctrl-alt-del" is a sad limitation. :) Remember: the mfsroot image is essentially a UFS filesystem that's mounted as memory disk. Since you re-created mfsroot (like you're supposed to :-) ) on a RELENG_8 box, the layout is different. In this case, I'm still using the stock 8.0 mfsroot. The only change was to un-gzip it. But this particular issue is probably due to the geom change you noted, so we'll see what happens on reboot. The NFS root mount you see happening later is a result of the root filesystem not being available. This is normal if mfsroot fails. I'm still stumped as to why it hangs there. I do have something for it to mount there via NFS (the 8.0 dvd contents), and it appears to try, but then it just sits there. Not locked up, just waiting... Please let me (on the list) know if this fixes your problem. As soon as she boots, I'll report back. Footnote: This is why I tell folks to zero out the first 8192 bytes of any disk they've previously installed FreeBSD on (even if the disk has no filesystems/slices on it). The way FreeBSD determines the size of the disk differs in RELENG_8; I believe GEOM "figures it out" on its own now, while previous releases relied on the "c" slice. The method I've recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. Is it also advisable to blot out any old glabel stuff at the end of the disk? What's the math to get that? Get a sector count for the whole disk, set "bs" to 512 and "skip" to (sector count - 1)? Thanks, Charles -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ 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 tuning [was: hardware for home use large storage]
On Tue, 16 Feb 2010 13:30, mattjreimer@ wrote: On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It is funny that you guys are all of a sudden talking about this, as I was just working on some modifications to the arc_summary.pl script for some better formatting and inclusion of kmem statistics. My intent on the modifications is to make the output more usable to the whole community by revealing the relevant system information that can be included in an email to the lists for diagnosis by others. ... Example output: - - System Summary OS Revision:199506 OS Release Date:703100 Hardware Platform: i386 Processor Architecture: i386 Storage pool Version: 13 Filesystem Version: 3 Kernel Memory Usage TEXT: 8950208 KiB,8 MiB DATA: 206347264 KiB, 196 MiB TOTAL: 215297472 KiB, 205 MiB Above did you really mean "8950208 B" not KiB, etc.? Matt Yes, Thank you for pointing this out. I have fixed this and it will be added to the the same url as before in about 3 or so hours from the time of this email. This update will also add some stats for L2 ARC as well. Thanks again. -- jhell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: netboot issues, 8.0, mfsroot mount failure
On Tue, Feb 16, 2010 at 5:28 PM, Charles Sprickman wrote: > Howdy, > > I'm having some problems getting 8.0 to install over the network. I've got > my dhcp, tftp and nfs server working well, and I've tested all three > services from this host before attempting to boot over the network. > > pxeboot seems to work, and I see it get loaded via tftp. The kernel boots, > and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD > fileset: > > [r...@archive /home/spork/tmp]# cat > /usr/local/netboot/freebsd8/boot/loader.conf > mfsroot_load="YES" > mfsroot_type="mfs_root" > mfsroot_name="/boot/mfsroot" > boot_multicons="YES" > boot_serial="YES" > console="comconsole,vidconsole" > vfs.root.mountfrom="ufs:/dev/md0c" > > I see the kernel does find mfsroot and attaches it: > > md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 > > But then when it's ready to mount the root filesystem, I get this: > > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/md0c > ROOT MOUNT ERROR: > > If you have invalid mount options, reboot, and first try the following from > the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > It doesn't really state what the error is. It's hinting that it's > read-only, but that seems odd. Even if it couldn't mount r/w, shouldn't it > just drop to single-user at this point? > > Next it tries nfs: > > Trying to mount root from nfs: > NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 > em0: link state changed to UP > > And there it sits. Remotely I can't do anything. If I'm local, I can > ctrl-alt-del a few times and then about a minute later it does an orderly > restart. > > I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nfs > traffic between the two hosts, which appears to be the client stat-ing a > file or directory. tcpdump also shows some checksum errors, but I recall a > few threads here mentioning that on Intel cards that generally is not a > cause for concern. > >> From another host, I have no issues mounting that nfs filesystem r/w: > > r...@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd8 > /mntr...@h10[/home/spork]# ls /mnt/ > .cshrc HARDWARE.TXT boot.catalog media sbin > .profile README.HTM cdrom.inf mnt stand > 8.0-RELEASE README.TXT dev packages sys > COPYRIGHT RELNOTES.HTM docbook.css proc tmp > ERRATA.HTM RELNOTES.TXT etc rescue usr > ERRATA.TXT bin lib root var > HARDWARE.HTM boot libexec rr_moved > r...@h10[/home/spork]# touch /mnt/foo > r...@h10[/home/spork]# rm /mnt/foo > r...@h10[/home/spork]# umount /mnt > > Any ideas? I've got about a dozen remote boxes to upgrade, so I want to > totally nail down this procedure. I've been putting off learning this for a > few years, and now I've got an actual need for it. I'll be in your shoes in a little bit... I ran into some issues when I last tried with NFSv3 on a Solaris server so we'll see how things go in the second go-around [with a FreeBSD nfs rootfs server], but 7.x netbooted and 8.x didn't when I tried last; the 7.x images have some secret sauce fixes for PXE booting -- the ones I know of are as follows (apply to loader.conf as you feel fit): vfs.root.mountfrom="nfs" boot.nfsroot.path="/absolute/path/to/netboot/dir" boot.nfsroot.server="nfs-server-ip-addr" There were also some code changes made to `fix' netbooting with pxeloader, but I'm not sure if they're applicable or needed in 8.x, and I'm not sure what the actual changes are TBH... Cheers, -Garrett ___ 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: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
Xorg.log after: #killall xdm #kldunload radeon #dmesg: info: [drm] Resetting GPU vgapci0: child drm0 requested pci_disable_busmaster info: [drm] MSI released drm0: detached Warning: memory type drm_bufs leaked memory on destroy (2 allocations, 64 bytes leaked). drm0: on vgapci0 #kldload radeon #dmesg: drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 #xdm after this procedure the X never come up, but the system not crashed, and the log attached. On 2/15/10, Robert Noland wrote: > On Mon, 2010-02-15 at 14:23 +0100, Martin Kristensen wrote: >> On Sat, 13 Feb 2010 15:27:04 -0600 >> Robert Noland wrote: >> >> > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: >> > > On February 13, 2010, Robert Noland wrote: >> > > > Ok, I've put up a patch at: >> > > > >> > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch >> > > > >> > >> > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch >> > >> > This one should work on 8... >> > >> > robert. >> > >> > > > This is sort of a mega patch and includes: >> > > > >> > > > Re-worked drm mapping code, that ensures that we don't end up >> > > > incorrectly mapping certain maps with overlapping offsets. This >> > > > generally shows up as the ring buffer not being cleared >> > > > (contents != 0 in xorg.log) which leads to corruption and other >> > > > bad behavior. >> > > > >> > > > Re-written scatter gather allocation code. This interacts >> > > > directly with the VM system, rather than using bus_dma to allow >> > > > us to grab non-contiguous pages for the scatter gather backing of >> > > > the GART. It also makes it easier to handle the caching mode of >> > > > the backing pages. >> > > > >> > > > Disable cache snooping on radeon cards, since we have write >> > > > combining set properly now. >> > > > >> > > > I have at least done a test build on -CURRENT with this patch, >> > > > but I haven't had time to do much else without the rest of the >> > > > code in my tree. I've been running most all of this code for a >> > > > month or two now at least, so it is mostly just a question of >> > > > whether or not I got all of the conflicts sorted out properly >> > > > when I made this patch. >> > > > >> > > > The re-mapping code has the most widespread impact and has been >> > > > tested on radeon r600 amd64, intel g45 i386 and mga amd64. >> > > > >> > > > robert. >> >> The patch applied cleanly. I have applied the patch to a clean 8-STABLE >> environment with WITNESS, INVARIANTS and KDB_UNATTENDED in the kernel. >> I still see the crashes when starting X with DRI on. This is what I see >> in messages: >> >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 070001c7b000 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 070001c7c000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 070001c7d000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 070001c7e000 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_mmap] called with offset >> 070001c7f000 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, >> cmd=0xc0286415, nr=0x15, dev 0xff0001a79400, auth=1 >> Feb 14 19:13:44 alpha kernel: >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] offset = >> 0xfe8e, size = 0x0001, type = 1 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Found kernel map 1 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_addmap] Added map 1 >> 0xfe8e/0x1 >> Feb 14 19:13:44 alpha kernel: [drm:pid30467:drm_ioctl] pid=30467, >> cmd=0x80106459, nr=0x59, dev 0xff0001a79400, auth=1 >> >> >> There has been one odd development. If I startx with DRI off or NoAccel >> set it starts as usual. If I then quit and to cli and restart, I see the >> same crash as if I had DRI on. > > I'm really starting to think that this is a bug in the Xserver > somewhere... If DRI is off, the kernel drm is not involved at all. The > radeon driver does grope around on the pci bus (via libpciaccess) which > could potentially cause issues, but... miwi and a few other folks have > picked up the ball to get us up to xorg 7.5, since I just don't have > time to do it all now. That might be a good thing to try, I expect that > they will have a patch ready soon, like within a few days. > > robert. > >> Martin > -- > Robert Noland > FreeBSD > > ___ > 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 unsubsc
Re: netboot issues, 8.0, mfsroot mount failure
On Tue, Feb 16, 2010 at 06:11:36PM -0800, Jeremy Chadwick wrote: > The NFS root mount you see happening later is a result of the root > filesystem not being available. This is normal if mfsroot fails. A follow-up to my own post: The above paragraph is incorrect. The NFS root mount is proper, expected, and required -- but the failures you see later on (e.g. /etc/fstab missing, etc. -- which are in your private mail to me but not here), I believe, are a result of the mfsroot stuff not working. Sorry for the confusion; I should really be asleep right now... -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: netboot issues, 8.0, mfsroot mount failure
On Tue, Feb 16, 2010 at 08:28:03PM -0500, Charles Sprickman wrote: > Howdy, > > I'm having some problems getting 8.0 to install over the network. > I've got my dhcp, tftp and nfs server working well, and I've tested > all three services from this host before attempting to boot over the > network. > > pxeboot seems to work, and I see it get loaded via tftp. The kernel > boots, and parses the options in loader.conf that exist in my > nfs-exported 8.0 DVD fileset: > > [r...@archive /home/spork/tmp]# cat > /usr/local/netboot/freebsd8/boot/loader.conf > mfsroot_load="YES" > mfsroot_type="mfs_root" > mfsroot_name="/boot/mfsroot" > boot_multicons="YES" > boot_serial="YES" > console="comconsole,vidconsole" > vfs.root.mountfrom="ufs:/dev/md0c" > > I see the kernel does find mfsroot and attaches it: > > md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 > > But then when it's ready to mount the root filesystem, I get this: > > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/md0c > ROOT MOUNT ERROR: > > If you have invalid mount options, reboot, and first try the > following from the loader prompt: > > set vfs.root.mountfrom.options=rw > > and then remove invalid mount options from /etc/fstab. > > It doesn't really state what the error is. It's hinting that it's > read-only, but that seems odd. Even if it couldn't mount r/w, > shouldn't it just drop to single-user at this point? > > Next it tries nfs: > > Trying to mount root from nfs: > NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 > em0: link state changed to UP > > And there it sits. Remotely I can't do anything. If I'm local, I > can ctrl-alt-del a few times and then about a minute later it does > an orderly restart. We've been talking off-list about this (and other things), but at this point I'm pretty sure the problem is that the local slice naming convention has changed in RELENG_8 from what it was in RELENG_7. This is the cause/result of the "GEOM overhall" (or whatever it is; I don't know what to call it. Is it libdisk changes? GEOM? Both? I really don't know). Basically, the way the full size of the disk gets handled differs now from RELENG_7. (See footnote for "fun") So, try changing this: vfs.root.mountfrom="ufs:/dev/md0c" ...to this (look closely): vfs.root.mountfrom="ufs:/dev/md0" Remember: the mfsroot image is essentially a UFS filesystem that's mounted as memory disk. Since you re-created mfsroot (like you're supposed to :-) ) on a RELENG_8 box, the layout is different. The NFS root mount you see happening later is a result of the root filesystem not being available. This is normal if mfsroot fails. Please let me (on the list) know if this fixes your problem. Footnote: This is why I tell folks to zero out the first 8192 bytes of any disk they've previously installed FreeBSD on (even if the disk has no filesystems/slices on it). The way FreeBSD determines the size of the disk differs in RELENG_8; I believe GEOM "figures it out" on its own now, while previous releases relied on the "c" slice. The method I've recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
netboot issues, 8.0, mfsroot mount failure
Howdy, I'm having some problems getting 8.0 to install over the network. I've got my dhcp, tftp and nfs server working well, and I've tested all three services from this host before attempting to boot over the network. pxeboot seems to work, and I see it get loaded via tftp. The kernel boots, and parses the options in loader.conf that exist in my nfs-exported 8.0 DVD fileset: [r...@archive /home/spork/tmp]# cat /usr/local/netboot/freebsd8/boot/loader.conf mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" boot_multicons="YES" boot_serial="YES" console="comconsole,vidconsole" vfs.root.mountfrom="ufs:/dev/md0c" I see the kernel does find mfsroot and attaches it: md0: Preloaded image 4423680 bytes at 0xc0f6dfe0 But then when it's ready to mount the root filesystem, I get this: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/md0c ROOT MOUNT ERROR: If you have invalid mount options, reboot, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove invalid mount options from /etc/fstab. It doesn't really state what the error is. It's hinting that it's read-only, but that seems odd. Even if it couldn't mount r/w, shouldn't it just drop to single-user at this point? Next it tries nfs: Trying to mount root from nfs: NFS ROOT: 192.168.1.111:/usr/local/netboot/freebsd8 em0: link state changed to UP And there it sits. Remotely I can't do anything. If I'm local, I can ctrl-alt-del a few times and then about a minute later it does an orderly restart. I'm not aware of a good way to snoop on nfs traffic, but tcpdump shows nfs traffic between the two hosts, which appears to be the client stat-ing a file or directory. tcpdump also shows some checksum errors, but I recall a few threads here mentioning that on Intel cards that generally is not a cause for concern. From another host, I have no issues mounting that nfs filesystem r/w: r...@h10[/home/spork]# mount_nfs 192.168.1.111:/usr/local/netboot/freebsd8 /mntr...@h10[/home/spork]# ls /mnt/ .cshrc HARDWARE.TXTboot.catalogmedia sbin .profileREADME.HTM cdrom.inf mnt stand 8.0-RELEASE README.TXT dev packagessys COPYRIGHT RELNOTES.HTMdocbook.css proctmp ERRATA.HTM RELNOTES.TXTetc rescue usr ERRATA.TXT bin lib rootvar HARDWARE.HTMbootlibexec rr_moved r...@h10[/home/spork]# touch /mnt/foo r...@h10[/home/spork]# rm /mnt/foo r...@h10[/home/spork]# umount /mnt Any ideas? I've got about a dozen remote boxes to upgrade, so I want to totally nail down this procedure. I've been putting off learning this for a few years, and now I've got an actual need for it. Thanks, Charles ___ 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 tuning [was: hardware for home use large storage]
On Wed, Feb 17, 2010 at 07:05:11AM +1100, Peter Jeremy wrote: > Overall, Barry's script makes an excellent proof-of-concept - which is > what he was offering. You know, I had a verbose in-line response typed up, agreeing with some points of yours and disagreeing with others (with perlfaq and other reference material), but decided... fuck it! :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: raidz/2 stripe widths
On Tue, Feb 16, 2010 at 11:47 AM, Peter C. Lai wrote: > Which one might be "better" on pool that will consist of 6 disks: > > 6x raidz2 > or > 2 stripes of 3 disks in raidz? > > It should provide slightly less reliability (still allows for 2 disks to be > off the array at a time) but the latter should improve reads since a given > read only has to touch 3 spindles at a time instead of 5? > Depends. Do you want better reliability/redundancy (raidz2) or more throughput/IOPS (2x raidz1)? The max IOPS of a raidz vdev will be that of 1 disk. Thus, to get better IOPS, you have to have multiple raidz vdevs. The overly-simplistic way to look at is to think of the entire raidz vdev as a "single disk". Then it's an easy comparison: 1 disk is slower than 2 disks striped together. -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS tuning [was: hardware for home use large storage]
On 2010-Feb-16 09:59:46 -0800, Jeremy Chadwick wrote:
>On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote:
>> maybe something like this tacked on the end of the script (excuse my
>> Perl, I'm a Python guy).
>>
>>
>> Loader Settings #
>> open(LOADER, '/boot/loader.conf');
>> print "\n/boot/loader.conf settings:\n";
>> while (){
>> chomp;
>> if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
>> print "\t$_\n";
>> }
>> }
>>
>
>Major problems with the above code:
>
>1) Opens /boot/loader.conf for rw access; should be read-only
Wrong. It opens /boot/loader.conf read-only, as it should.
>2) Makes the assumption /boot/loader.conf exists
Accepted but it was offered as a proof-of-concept.
>3) Does not close the fd
This is hardly a "major problem" in a short once-through script.
>4) Excessively quotes variables for no justified reason
If you mean including the $_ inside "", this is a standard perl idiom.
>5) Makes some bad assumptions about the contents of the file (ex.
> comments with the word "zfs" in them would match)
Wrong. It only matches "zfs" as the first non-blank text on
a line - which means it can't be a comment.
So that's one real deficiency in a proof-of-concept script written by
someone who does not claim to be comfortable with perl.
>The code should really be something like what's below. This should
>be much more manageable as well (@tunables that is), although I always
>worry when using grep()...
Whilst we are picking nits, your script has the following issues:
- unnecessary trailing wildcard matches in the regexps
- "grep" misused as "map"
- "die" is probably not appropriate for embedding into another script
- No useful error message if /boot/loader.conf can't be opened.
- Doesn't correctly handle optional whitespace around "="
- No heading to explain what is being reported.
- Doesn't allow for "zfs" as a top-level identifier
Overall, Barry's script makes an excellent proof-of-concept - which is
what he was offering.
--
Peter Jeremy
pgpI6dXwSO06C.pgp
Description: PGP signature
Re: raidz/2 stripe widths
http://blogs.sun.com/ahl/entry/double_parity_raid_z Looks like raidz2 is recommended for better protection against failures than 2 stripes. On Tue, Feb 16, 2010 at 2:47 PM, Peter C. Lai wrote: > Which one might be "better" on pool that will consist of 6 disks: > > 6x raidz2 > > or > > 2 stripes of 3 disks in raidz? > > It should provide slightly less reliability (still allows for 2 disks to be > off the array at a time) but the latter should improve reads since a given > read only has to touch 3 spindles at a time instead of 5? > -- > === > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator| 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > === > > ___ > 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" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ 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"
raidz/2 stripe widths
Which one might be "better" on pool that will consist of 6 disks: 6x raidz2 or 2 stripes of 3 disks in raidz? It should provide slightly less reliability (still allows for 2 disks to be off the array at a time) but the latter should improve reads since a given read only has to touch 3 spindles at a time instead of 5? -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ 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: hardware for home use large storage
On Tue, February 16, 2010 2:05 pm, Alexander Motin wrote: > Dan Langille wrote: >> On Wed, February 10, 2010 10:00 pm, Bruce Simpson wrote: >>> On 02/10/10 19:40, Steve Polyack wrote: I haven't had such bad experience as the above, but it is certainly a concern. Using ZFS we simply 'offline' the device, pull, replace with a new one, glabel, and zfs replace. It seems to work fine as long as nothing is accessing the device you are replacing (otherwise you will get a kernel panic a few minutes down the line). m...@freebsd.org has also committed a large patch set to 9-CURRENT which implements "proper" SATA/AHCI hot-plug support and error-recovery through CAM. >>> I've been running with this patch in 8-STABLE for well over a week now >>> on my desktop w/o issues; I am using main disk for dev, and eSATA disk >>> pack for light multimedia use. >> >> MFC to 8.x? > > Merged. Thank you. :) -- Dan Langille -- http://langille.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: hardware for home use large storage
Dan Langille wrote: > On Wed, February 10, 2010 10:00 pm, Bruce Simpson wrote: >> On 02/10/10 19:40, Steve Polyack wrote: >>> I haven't had such bad experience as the above, but it is certainly a >>> concern. Using ZFS we simply 'offline' the device, pull, replace with >>> a new one, glabel, and zfs replace. It seems to work fine as long as >>> nothing is accessing the device you are replacing (otherwise you will >>> get a kernel panic a few minutes down the line). m...@freebsd.org has >>> also committed a large patch set to 9-CURRENT which implements >>> "proper" SATA/AHCI hot-plug support and error-recovery through CAM. >> I've been running with this patch in 8-STABLE for well over a week now >> on my desktop w/o issues; I am using main disk for dev, and eSATA disk >> pack for light multimedia use. > > MFC to 8.x? Merged. -- Alexander Motin ___ 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 tuning [was: hardware for home use large storage]
On Mon, Feb 15, 2010 at 5:49 PM, jhell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > It is funny that you guys are all of a sudden talking about this, as I was > just working on some modifications to the arc_summary.pl script for some > better formatting and inclusion of kmem statistics. > > My intent on the modifications is to make the output more usable to the > whole community by revealing the relevant system information that can be > included in an email to the lists for diagnosis by others. > ... > Example output: > - - > System Summary > OS Revision:199506 > OS Release Date:703100 > Hardware Platform: i386 > Processor Architecture: i386 > Storage pool Version: 13 > Filesystem Version: 3 > > Kernel Memory Usage > TEXT: 8950208 KiB,8 MiB > DATA: 206347264 KiB, 196 MiB > TOTAL: 215297472 KiB, 205 MiB > Above did you really mean "8950208 B" not KiB, etc.? Matt ___ 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 tuning [was: hardware for home use large storage]
On Tue, Feb 16, 2010 at 11:06:43AM -0600, Barry Pederson wrote:
> On 2/15/10 7:49 PM, jhell wrote:
>
> >As I make final modifications to the script I will keep the below URLs
> >updated and welcome any bug reports or modification requests to me
> >personally.
> >
> >Here is the URLs:
> >http://jhell.googlecode.com/files/arc_summary.pl
> >http://jhell.googlecode.com/files/arc_summary.pl.asc
>
> Nice. How about including relevant lines from /boot/loader.conf,
> maybe something like this tacked on the end of the script (excuse my
> Perl, I'm a Python guy).
>
>
> Loader Settings #
> open(LOADER, '/boot/loader.conf');
> print "\n/boot/loader.conf settings:\n";
> while (){
> chomp;
> if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
> print "\t$_\n";
> }
> }
>
>
> Yes, it should more or less duplicate the sysctl values, but it may
> make it more obvious where the settings are coming from, or if the
> user has bad or ignored settings
Major problems with the above code:
1) Opens /boot/loader.conf for rw access; should be read-only
2) Makes the assumption /boot/loader.conf exists
3) Does not close the fd
4) Excessively quotes variables for no justified reason
5) Makes some bad assumptions about the contents of the file (ex.
comments with the word "zfs" in them would match)
The code should really be something like what's below. This should
be much more manageable as well (@tunables that is), although I always
worry when using grep()...
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
#!/usr/local/bin/perl
my @tunables = qw(
vfs\.zfs\..+
vm\.kmem_size.*
);
my $loaderconf = "/boot/loader.conf";
if (-e $loaderconf)
{
open(FH, "<", $loaderconf) or die;
while ()
{
# Get rid of trailing newlines and preceding spaces.
chomp;
s/^\s+//g;
# Match against any key=value pair, and then see if the
# key portion matches against any regex string in @tunables.
if (/^([\w\.]+)=.+/)
{
if (grep $1 =~ /$_/, @tunables) {
print "\t", $_ , "\n";
}
}
}
close(FH);
}
___
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: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related)
On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote: > I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone > shed light on the below error? I unfortunately cannot provide a proper crash > dump. The pointer addresses are always the same. The only other thing I've > noticed that may be related is a watchdog timeout on bge0 error before the > panic. Thanks. > Any chance to get backtrace from the crash? > Jan 27 15:25:01 wifi kernel: > Jan 27 15:25:01 wifi kernel: > Jan 27 15:25:01 wifi kernel: Fatal trap 12: page fault while in kernel mode > Jan 27 15:25:01 wifi kernel: cpuid = 4; apic id = 04 > Jan 27 15:25:02 wifi kernel: > Jan 27 15:25:02 wifi kernel: fault virtual address = 0x28 > Jan 27 15:25:02 wifi kernel: fault code = supervisor write data, > page not present > Jan 27 15:25:02 wifi kernel: instruction pointer= > 0x20:0x803263b7 > Jan 27 15:25:02 wifi kernel: stack pointer = > 0x28:0xff8073acdb40 > Jan 27 15:25:02 wifi kernel: frame pointer = > 0x28:0xff8073acdba0 > Jan 27 15:25:02 wifi kernel: code segment = base 0x0, limit > 0xf, type 0x1b > Jan 27 15:25:02 wifi kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > Jan 27 15:25:02 wifi kernel: processor eflags = > Jan 27 15:25:02 wifi kernel: interrupt enabled, > Jan 27 15:25:02 wifi kernel: resume, > Jan 27 15:25:02 wifi kernel: IOPL = 0 > Jan 27 15:25:02 wifi kernel: > Jan 27 15:25:02 wifi kernel: current process > ___ > 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 tuning [was: hardware for home use large storage]
On 2/15/10 7:49 PM, jhell wrote:
As I make final modifications to the script I will keep the below URLs
updated and welcome any bug reports or modification requests to me
personally.
Here is the URLs:
http://jhell.googlecode.com/files/arc_summary.pl
http://jhell.googlecode.com/files/arc_summary.pl.asc
Nice. How about including relevant lines from /boot/loader.conf, maybe
something like this tacked on the end of the script (excuse my Perl, I'm
a Python guy).
Loader Settings #
open(LOADER, '/boot/loader.conf');
print "\n/boot/loader.conf settings:\n";
while (){
chomp;
if (/^\s*(zfs|vfs\.zfs|vm\.kmem)/){
print "\t$_\n";
}
}
Yes, it should more or less duplicate the sysctl values, but it may make
it more obvious where the settings are coming from, or if the user has
bad or ignored settings
Barry
___
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: hardware for home use large storage
On 2010-02-15 10:29:22PM +0100, Gót András wrote: > On Hét, Február 15, 2010 10:15 pm, Dan Naumov wrote: > >>> A C2Q CPU makes little sense right now from a performance POV. For > >>> the price of that C2Q CPU + LGA775 board you can get an i5 750 CPU and > >>> a 1156 socket motherboard that will run circles around that C2Q. You > >>> would lose the ECC though, since that requires the more expensive 1366 > >>> socket CPUs and boards. > >>> > >>> - Sincerely, > >>> Dan Naumov > >>> > >> > >> Hi, > >> > >> > >> Do have test about this? I'm not really impressed with the i5 series. > >> > >> > >> Regards, > >> Andras > >> > > > > There: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3634&p=10 > > > > > > The i5 750, which is a 180 euro CPU, beats Q9650 C2Q, which is a 300 euro > > CPU. > > > > > > > > - Sincerely, > > Dan Naumov > > > > > > Oh, I was not up to date on price performance ratio. However I'd compare > the i5 750 to the Q8400 which is also a 2,66GHz one. > Perhaps there is some confusion between the i5 and i3? A C2Q will probably beat an i3 at the same clock speed but i5 750 has 8mb of unified cache and the turboboost feature. IMO a lot of the benchmark differences between an i5 and C2Q can be attributed to DDR3 and the onboard ram controller on the i5 reducing latency (which if one is to believe Herb Sutter, is the bane of all modern CPUs). -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ 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: hardware for home use large storage
On 2010-02-15 02:25:57PM -0800, Artem Belevich wrote: > > How much ram are you running with? > > 8GB on amd64. kmem_size=16G, zfs.arc_max=6G > > > In a latest test with 8.0-R on i386 with 2GB of ram, an install to a ZFS > > root *will* panic the kernel with kmem_size too small with default > > settings. Even dropping down to Cy Schubert's uber-small config will panic > > the kernel (vm.kmem_size_max = 330M, vfs.zfs.arc_size = 40M, > > vfs.zfs.vdev.cache_size = 5M); the system is currently stable using DIST > > kernel, vm.kmem_size/max = 512M, arc_size = 40M and vdev.cache_size = 5M. > > On i386 you don't really have much wiggle room. Your address space is > 32-bit and, to make things more interesting, it's split between > user-land and kernel. You can keep bumping KVA_PAGES only so far and > that's what limits your vm.kmem_size_max which is the upper limit for > vm.kmem_size. > > The bottom line -- if you're planning to use ZFS, do switch to amd64. > Even with only 2GB of physical RAM available, your box will behave > better. At the very least it will be possible to avoid the panics > caused by kmem exhaustion. > > --Artem Well this ZFS box (which admittedly is mostly a testbed) is only a lowly NetBurst Gallatin Xeon, pre-amd64 :( -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ 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: Kernel probe order issues
on 15/02/2010 00:24 Peter Jeremy said the following: > On 2010-Feb-05 00:40:24 +0200, Andriy Gapon wrote: >> I came up with some things with which you can try to experiment: >> >> 1. Boot with hw.pci.usb_early_takeover="0" in loader.conf. >> >> 2. Comment out the following line in sys/dev/usb/controller/uhci_pci.c: >> pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2); > > Sorry for the delay in responding. Neither of these made any difference. > > I have also tried asking in FreeBSD-usb and hps@ suggested > trying ukbd.c Rev 43 from p4 - which also didn't help. I am out of ideas, sorry. -- 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: hardware for home use large storage
On 2/16/2010 6:28 AM, Miroslav Lachman wrote: Dan Langille wrote: Daniel O'Connor wrote: [...] Why even bother with the LSI card at all? That board already has 6 SATA slots - depends how many disks you want to use of course. (5 HDs + 1 DVD drive?) Plus two SATA drives in a gmirror for the base OS, and one optical. I want a minimum of 8 slots. I think that 2 HDDs in gmirror just for base OS is an overkill if you want this machine as home storage. You will be fine with booting the base OS from CF card or USB stick. (and you can put two USB flash disks in gmirror if you want redundancy) This way you will save some money, SATA ports/cards and if you will use some kind of fast and big USB stick, you can use part of it as L2ARC for speeding up read performance of ZFS http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ I have my backup storage machine booted from USB stick (as read-only UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year without problem. I agree. However, the machine will be primarily storage, but it will also be running PostgreSQL and Bacula. I already have smaller unused SATA drives laying around here. Thank you -- Dan Langille - http://langille.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: booting off a ZFS pool consisting of multiple striped mirror vdevs
On Tue, 2010-02-16 at 10:38 +0200, Dan Naumov wrote: > > I don't know, but I plan to test that scenario in a few days. > > > > Matt > > Please share the results when you're done, I am really curious :) > > > > It *should* work... I made changes a while back that allow for multiple > > vdevs to attach to the root. In this case you should have 3 mirror > > vdevs attached to the root, so as long as the BIOS can enumerate all of > > the drives, we should find all of the vdevs and build the tree > > correctly. It should be simple enough to test in qemu, except that the > > BIOS in qemu is a little broken and might not id all of the drives. > > > > robert. > > If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, > can you explain why is booting off simple stripes (of any number of > disks) currently unsupported? I haven't tested that myself, but > everywhere I look seems to indicate that booting off a simple stripe > doesn't work or is that "everywhere" also out of date after your > changes? :) I would need to setup a qemu test for it... But I can't think of a reason that it shouldn't work. I currently boot from two physical drives attached to the root. In the boot code we enumerate all the physical vdevs, so that we can correctly identify the correct disk and offset from the block pointer. The mirror driver is really pretty simple. robert. > > - Sincerely, > Dan Naumov -- Robert Noland FreeBSD ___ 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: hardware for home use large storage
On Tue, 16 Feb 2010, Miroslav Lachman wrote: > I have my backup storage machine booted from USB stick (as read-only > UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year > without problem. Yeah, I am booting off a 4Gb CF card with adapter (I didn't trust the BIOS enough for USB :) I wouldn't use it for a remote system without redundancy but for a home setup a very lightly used flash device seems like an obvious (and cost effective) choice. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: hardware for home use large storage
Dan Langille wrote: Daniel O'Connor wrote: [...] Why even bother with the LSI card at all? That board already has 6 SATA slots - depends how many disks you want to use of course. (5 HDs + 1 DVD drive?) Plus two SATA drives in a gmirror for the base OS, and one optical. I want a minimum of 8 slots. I think that 2 HDDs in gmirror just for base OS is an overkill if you want this machine as home storage. You will be fine with booting the base OS from CF card or USB stick. (and you can put two USB flash disks in gmirror if you want redundancy) This way you will save some money, SATA ports/cards and if you will use some kind of fast and big USB stick, you can use part of it as L2ARC for speeding up read performance of ZFS http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ I have my backup storage machine booted from USB stick (as read-only UFS) with 4x 1TB HDDs in RAIDZ. It is running one and half year without problem. Miroslav Lachman ___ 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"
Xircom X3201 10/100BaseTX still doesn't work with FreeBSD 7.3
Hello, I was wondering if there were any plans with regards to the bug mentioned in kern/115623 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/115623)? FreeBSD 7.3-PRERELEASE (haven't tried RC1 yet, pulling the sources down now via cvsup) doesn't work with the card until the patch included in the pr is used. (complete description on what it does before the patch is applied is included in the pr). I added a comment to the pr back in April saying that it didn't work with 7.2. In November, someone replied that it still doesn't work with 8. Any ideas? Thanks -Stacy ___ 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: kernel make error: scvidctl.c
Oh, I'm sorry for bothering you all, guys. I commented out vga instead of agp. :) 2010/2/16 Nikolay Tychina > Hi. > > I csupped RELENG_8, buildworld succeeded, but buildkernel fails. Any ideas > what is going wrong here? > > > MAKE=make sh /usr/home/nicholas/example/usr/src/sys/conf/newvers.sh LETTUCE > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/home/nicholas/example/usr/src/sys > -I/usr/home/nicholas/example/usr/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 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > scvidctl.o(.text+0x7d): In function `sc_render_match': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:867: > undefined reference to `__start_set_scrndr_set' > scvidctl.o(.text+0x82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__start_set_scrndr_set' > scvidctl.o(.text+0x87):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__stop_set_scrndr_set' > scvidctl.o(.text+0xfe):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: > undefined reference to `__stop_set_scrndr_set' > scvidctl.o(.text+0x145): In function `sc_set_graphics_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:261: > undefined reference to `vidsw' > scvidctl.o(.text+0x2df): In function `sc_set_text_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:145: > undefined reference to `vidsw' > scvidctl.o(.text+0xa44): In function `sc_vid_ioctl': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:500: > undefined reference to `vidsw' > scvidctl.o(.text+0xa6e):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:504: > undefined reference to `vidsw' > scvidctl.o(.text+0xaa4):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:508: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb18):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:530: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb30):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:534: > undefined reference to `vidsw' > scvidctl.o(.text+0xb82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:542: > undefined reference to `vid_get_adapter' > scvidctl.o(.text+0xb94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:546: > undefined reference to `vidsw' > scvidctl.o(.text+0xbf9):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:558: > undefined reference to `vidsw' > scvidctl.o(.text+0xc9a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:569: > undefined reference to `vidsw' > scvidctl.o(.text+0xce0):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:576: > undefined reference to `vidsw' > scvidctl.o(.text+0xd3a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:581: > undefined reference to `vidsw' > scvidctl.o(.text+0xd80):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:588: > more undefined references to `vidsw' follow > syscons.o(.text+0xd63): In function `sc_cnterm': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2857: > undefined reference to `vid_release' > syscons.o(.text+0xe11): In function `set_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3458: > undefined reference to `vidsw' > syscons.o(.text+0xe58):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3466: > undefined reference to `vidsw' > syscons.o(.text+0x10a5): In function `restore_scrn_saver_mode': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2052: > undefined reference to `vidsw' > syscons.o(.text+0x113a): In function `init_scp': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2984: > undefined reference to `vidsw' > syscons.o(.text+0x19ea): In function `exchange_scr': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2456: > undefined reference to `vidsw' > syscons.o(.text+0x1ea5): In function `scvidprobe': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:269: undefined > reference to `vid_configure' > syscons.o(.text+0x1eb5):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:271: > undefined reference to `vid_find_adapter' > syscons.o(.text+0x4d51): In function `scinit': > /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2656: > undefined reference to `vid_release' > syscons.o(.text+0x4d94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2670: > undefined reference to `vid_allocate' > syscons.o(.text
kernel make error: scvidctl.c
Hi. I csupped RELENG_8, buildworld succeeded, but buildkernel fails. Any ideas what is going wrong here? MAKE=make sh /usr/home/nicholas/example/usr/src/sys/conf/newvers.sh LETTUCE cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/home/nicholas/example/usr/src/sys -I/usr/home/nicholas/example/usr/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug scvidctl.o(.text+0x7d): In function `sc_render_match': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:867: undefined reference to `__start_set_scrndr_set' scvidctl.o(.text+0x82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__start_set_scrndr_set' scvidctl.o(.text+0x87):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__stop_set_scrndr_set' scvidctl.o(.text+0xfe):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:876: undefined reference to `__stop_set_scrndr_set' scvidctl.o(.text+0x145): In function `sc_set_graphics_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:261: undefined reference to `vidsw' scvidctl.o(.text+0x2df): In function `sc_set_text_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:145: undefined reference to `vidsw' scvidctl.o(.text+0xa44): In function `sc_vid_ioctl': /usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:500: undefined reference to `vidsw' scvidctl.o(.text+0xa6e):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:504: undefined reference to `vidsw' scvidctl.o(.text+0xaa4):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:508: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb18):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:530: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb30):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:534: undefined reference to `vidsw' scvidctl.o(.text+0xb82):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:542: undefined reference to `vid_get_adapter' scvidctl.o(.text+0xb94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:546: undefined reference to `vidsw' scvidctl.o(.text+0xbf9):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:558: undefined reference to `vidsw' scvidctl.o(.text+0xc9a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:569: undefined reference to `vidsw' scvidctl.o(.text+0xce0):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:576: undefined reference to `vidsw' scvidctl.o(.text+0xd3a):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:581: undefined reference to `vidsw' scvidctl.o(.text+0xd80):/usr/home/nicholas/example/usr/src/sys/dev/syscons/scvidctl.c:588: more undefined references to `vidsw' follow syscons.o(.text+0xd63): In function `sc_cnterm': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2857: undefined reference to `vid_release' syscons.o(.text+0xe11): In function `set_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3458: undefined reference to `vidsw' syscons.o(.text+0xe58):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:3466: undefined reference to `vidsw' syscons.o(.text+0x10a5): In function `restore_scrn_saver_mode': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2052: undefined reference to `vidsw' syscons.o(.text+0x113a): In function `init_scp': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2984: undefined reference to `vidsw' syscons.o(.text+0x19ea): In function `exchange_scr': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2456: undefined reference to `vidsw' syscons.o(.text+0x1ea5): In function `scvidprobe': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:269: undefined reference to `vid_configure' syscons.o(.text+0x1eb5):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:271: undefined reference to `vid_find_adapter' syscons.o(.text+0x4d51): In function `scinit': /usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2656: undefined reference to `vid_release' syscons.o(.text+0x4d94):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2670: undefined reference to `vid_allocate' syscons.o(.text+0x4d9f):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2671: undefined reference to `vid_get_adapter' syscons.o(.text+0x4e71):/usr/home/nicholas/example/usr/src/sys/dev/syscons/syscons.c:2701: undefined reference to `vidsw' syscons.o(.text+0x4e92):/usr/home/nicholas/
Re: ZFS tuning [was: hardware for home use large storage]
Quoting jhell (from Mon, 15 Feb 2010 20:49:38 -0500): On Mon, 15 Feb 2010 16:20, 000.fbsd@ wrote: I think you are referring to this script: http://cuddletech.com/arc_summary/ and its FreeBSD version http://bitbucket.org/koie/arc_summary/changeset/dbe14d2cf52b/ Another useful script is arcstat.pl from http://blogs.sun.com/realneel/entry/zfs_arc_statistics There are FreeBSD version floating around but I can't find a link to it, so I am sending it as attachment. It would be nice to have some "standardized" scripts for monitoring & debugging ZFS issues attached to FreeBSD Wiki page about ZFS tuning. Then everebody will use the same scripts, same output format. It will be easier to compare results in discussions etc. So if anybody of you have write permissions to Wiki, can you add those two scripts? (or make some better ;]) It is funny that you guys are all of a sudden talking about this, as I was just working on some modifications to the arc_summary.pl script for some better formatting and inclusion of kmem statistics. Here is the URLs: http://jhell.googlecode.com/files/arc_summary.pl http://jhell.googlecode.com/files/arc_summary.pl.asc I added references to all those scripts to the wiki. I also improved (I hope) the some parts. Please have a look and feel free to submit improvements (or register with FirstnameLastname and tell me about it, this way I'm not the bottleneck for changes). Bye, Alexander. -- I'm not stupid, I'm not expendable, and I'M NOT GOING! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: ACK and RST packets sent after successfully terminating TCP connection
> Packet #9: client --> server: client requests TCP connection close (FIN+ACK) > Packet #10: server --> client: server sends ACK > > Packet #11: server --> client: server announces TCP window size of 0, > indicating TCP receive buffers are exhausted and that the > client should wait before doing anything more > Packet #12: server --> client: identical re-sent ACK of packet #10 That is exactly the point: why is server sending any packets when connection was FIN'ned successfully by both sides? To my understanding of networking protocols, packets #11 and #12 should have never been sent. > > Packet #5: server --> client: server announces TCP window size of 0, > indicating TCP receive buffers are exhausted and that the > client should wait before doing anything more > Packet #6: server --> client: identical re-sent RST of packet #4 > Packet #7: client --> server: confirms reset (RST+ACK) Actually, it seems server confirm SYN-ACK packet and not the RST (packet #7 is "ack 2849043653" which is packet #2 - I'm running tcpdump with -S to see absolute sequence numbers). > Whatever this client/server protocol is, it isn't normal/standard. It's > not something like, for example, HTTP, SSH, or FTP; It's a custom > protocol and one I haven't seen before. It is a custom protocol at the application layer, meaning that instead of HTTP payload it has a different (XML) payload, but everything below is (hopefully) standard. > Do you see the above awkward behaviour (zero-sized TCP window packets > followed by a retransmission of a prior packet) when using standardised > protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP? I'll see what I can find out. > If not, then the client/server software is probably to blame. It may be > operating on a raw socket level, populating IP and/or TCP portions of > the packet itself rather than relying on socket(2) entirely. Client software is Java on Windows, but according to the pcaps, the client is not misbehaving. On the other hand, server software is Perl IO::Socket::INET which is pretty much a standard library and shouldn't be the problem as well. > If it uses standard kernel socket(2) functionality with PF_INET and > SOCK_STREAM, then I'd ask if the source is available publicly to be > analysed to determine if this behaviour is intentional or not. If needed, posting the relevant code snippets shouldn't be a problem. > Is there VPN and/or NAT involved between the client and server > (re: NAT: particularly around the server)? No. > Finally, is it possible to get "ifconfig -a" and "netstat -m" output > from the server? Certainly. # ifconfig -a (inet addr anonymized) em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0b:db:92:51:ec inet aaa.bbb.cc.dd netmask 0xff00 broadcast aaa.bbb.cc.255 media: Ethernet autoselect (1000baseTX ) status: active rl0: flags=8802 metric 0 mtu 1500 options=8 ether 00:c0:df:06:4e:8c media: Ethernet autoselect status: no carrier plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 # netstat -m 259/1526/1785 mbufs in use (current/cache/total) 256/1360/1616/25600 mbuf clusters in use (current/cache/total/max) 256/768 mbuf+clusters out of packet secondary zone in use (current/cache) 0/552/552/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/5309K/5886K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 209 requests for I/O initiated by sendfile 0 calls to protocol drain routines Your help is really appreciated. Regards, -- Nino ___ 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: booting off a ZFS pool consisting of multiple striped mirror vdevs
> I don't know, but I plan to test that scenario in a few days. > > Matt Please share the results when you're done, I am really curious :) > It *should* work... I made changes a while back that allow for multiple > vdevs to attach to the root. In this case you should have 3 mirror > vdevs attached to the root, so as long as the BIOS can enumerate all of > the drives, we should find all of the vdevs and build the tree > correctly. It should be simple enough to test in qemu, except that the > BIOS in qemu is a little broken and might not id all of the drives. > > robert. If booting of a stripe of 3 mirrors should work assuming no BIOS bugs, can you explain why is booting off simple stripes (of any number of disks) currently unsupported? I haven't tested that myself, but everywhere I look seems to indicate that booting off a simple stripe doesn't work or is that "everywhere" also out of date after your changes? :) - Sincerely, Dan Naumov ___ 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: hardware for home use large storage
On Mon, 15 Feb 2010, jfar...@goldsword.com wrote: > > Just out of curiousity, would not an older server like this: > http://www.geeks.com/details.asp?InvtId=DL145-5R (~$75 + shipping) or > http://www.geeks.com/details.asp?invtid=DL360-6R&cat=SYS (~$190 + shipping) > > be a reasonable option? Unless you're looking to suck every last bit of speed > or energy savings out the machine, I would think bumping the memory up on one > of these, adding one or more eSATA or SAS interfaces and an external drive > rack would result in an exceptional "home" server with several TB of storage, > decent speed, still costing less than $1K usd way too noisy, even for the basement :( -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
