Re: ZFS Boot Menu
06.10.2013 08:54, Teske, Devin wrote: On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: 29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. Cool; to start with, do you have a virtual appliance software like VMware or VirtualBox? Experience with generating ZFS pools in said software? VirtualBox/Qemu, Qemu is able to emulate boot to serial for example. And yes I tried working with ZFS in VMs. I think that we may have something to test next month. Right now, we're working on the ability of bsdinstall(8) to provision Boot on ZFS as a built-in functionality. That sounds cool. -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS Boot Menu
On Sep 30, 2013, at 6:20 AM, Volodymyr Kostyrko wrote: 29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. Cool; to start with, do you have a virtual appliance software like VMware or VirtualBox? Experience with generating ZFS pools in said software? I think that we may have something to test next month. Right now, we're working on the ability of bsdinstall(8) to provision Boot on ZFS as a built-in functionality. This feature (when in; projected for 10.0-BETA1) will make testing the Forth enhancements easier (IMHO). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS Boot Menu
Am 28.09.2013 23:30, schrieb Teske, Devin: In my recent interview on bsdnow.tv, I was pinged on BEs in Forth. I'd like to revisit this. Back on Sept 20th, 2012, I posted some pics demonstrating what exactly code that was in HEAD (at the time) was/is capable of. These three pictures (posted the same day) tell a story: 1. You boot to the menu: http://twitpic.com/b1eswi/full 2. You select option #5 to get here: http://twitpic.com/b1etyb/full 3. You select option #2 to get here: http://twitpic.com/b1ew47/full I've just (today) uploaded the /boot/menu.rc file(s) that I used to create those pictures: http://druidbsd.cvs.sf.net/viewvc/druidbsd/zfsbeastie/ NB: There's a README file to go along with the files. HINT: diff -pu menu.rc.1.current-head menu.rc.2.cycler HINT: diff -pu menu.rc.1.current-head menu.rc.2.dynamic-submenu Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Woohoo! Great! I am using ZFS boot environments with beadm, so I can test a bit. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS Boot Menu
29.09.2013 00:30, Teske, Devin wrote: Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. Sign me in, I'm not fluent with forth but testing something new is always fun. -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ZFS Boot Menu
In my recent interview on bsdnow.tv, I was pinged on BEs in Forth. I'd like to revisit this. Back on Sept 20th, 2012, I posted some pics demonstrating what exactly code that was in HEAD (at the time) was/is capable of. These three pictures (posted the same day) tell a story: 1. You boot to the menu: http://twitpic.com/b1eswi/full 2. You select option #5 to get here: http://twitpic.com/b1etyb/full 3. You select option #2 to get here: http://twitpic.com/b1ew47/full I've just (today) uploaded the /boot/menu.rc file(s) that I used to create those pictures: http://druidbsd.cvs.sf.net/viewvc/druidbsd/zfsbeastie/ NB: There's a README file to go along with the files. HINT: diff -pu menu.rc.1.current-head menu.rc.2.cycler HINT: diff -pu menu.rc.1.current-head menu.rc.2.dynamic-submenu Interested in feedback, but moreover I would like to see who is interested in tackling this with me? I can't do it alone... I at least need testers whom will provide feedback and edge-case testing. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS boot
On Sat, Oct 11, 2008 at 04:21:55PM -0700, Nate Eldredge wrote: On Sat, 11 Oct 2008, Pegasus Mc Cleaft wrote: FWIW, my system is amd64 with 1 G of memory, which the page implies is insufficient. Is it really? This may be purely subjective, as I have never bench marked the speeds, but when I was first testing zfs on a i386 machine with 1gig ram, I thought the performance was mediocre. However, when I loaded the system on a quad core - core2 with 8 gigs ram, I was quite impressed. I put localized changes in my /boot/loader.conf to give the kernel more breathing room and disabled the prefetch for zfs. #more loader.conf vm.kmem_size_max=1073741824 vm.kmem_size=1073741824 vfs.zfs.prefetch_disable=1 I was somewhat confused by the suggestions on the wiki. Do the kmem_size sysctls affect the allocation of *memory* or of *address space*? The Wiki is somewhat vague and doesn't give you all the knowledge you need. The kmem_* sysctls do not define pre-allocated amounts. They define the amount of memory which can be used by the kernel for allocation. I strongly advocate tuning two other sysctls, which can help greatly in ensuring no system lock-ups and no kmem exhaustion panics: vfs.zfs.arc_min vfs.zfs.arc_max The following values are what I use, but others have reported better performance with arc_max set to 128M: vfs.zfs.arc_min=16M vfs.zfs.arc_max=64M It seems a bit much to reserve 1 G of memory solely for the use of the kernel, expecially in my case when that's all I have :) But on amd64, it's welcome to have terabytes of address space if it will help. ZFS is a memory hog, period. That's just the nature of the beast. You probably should not be using it on a system with 1GB. I'll remind you that memory right now is *incredibly* cheap; you can get 4GB of brand-name lifetime-warranty RAM for around US$40-50. Secondly, with regards to amd64: RELENG_6 and RELENG_7 amd64 cannot handle more than 2GB of kmem. Yes, you read that correct; it's not a typo. It's an implementation issue which cannot be easily solved on those releases. CURRENT can address up to 512GB. I've fully documented this on my Wiki, see section Kernel. http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | Jeremy Chadwickjdc at 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
It seems a bit much to reserve 1 G of memory solely for the use of the kernel, expecially in my case when that's all I have :) But on amd64, it's welcome to have terabytes of address space if it will help. ZFS is a memory hog, period. That's just the nature of the beast. You probably should not be using it on a system with 1GB. I'll remind you that memory right now is *incredibly* cheap; you can get 4GB of brand-name lifetime-warranty RAM for around US$40-50. I am running FreeBSD-7 with the following: m.kmem_size=512M vm.kmem_size_max=512M vfs.zfs.arc_max=256M vfs.zfs.arc_min=32M vfs.zfs.prefetch_disable=1 on a i386 machine with 1 Gig memory (now upgraded to 1.5 Gig) and i have not experienced, up to now, any lockup problem. Apparently the kernel effectively uses around 500M memory, indeed. Performance seems reasonable to me, not worse than with UFS. -- Michel TALON ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
:To Matt: : since 'small' nowadays is big enough to hold /, what advantages are there :in having root split up? :also, having this split personality, what if the disk goes? the hammer/zfs :is probably raided ... You mean /boot + root , or do you mean /root vs /usr vs /home? I'll answer both. With regards to /boot + root. A small separate /boot partition (256m) allows your root filesystem to use an arbitrarily complex topology. e.g. multiple geom layers, weird zfs setups, etc. So you get flexibility that you would otherwise not have if you went with a directly-bootable ZFS root. /boot can be as complex as boot2 allows. There's nothing preventing it from being RAIDed if boot2 supported that, and there's nothing preventing it (once you had ZFS boot capabilities) from being ZFS using a topology supported by boot2. Having a sparate /boot allows your filesystem root to use topologues boot2 would otherwise not support. With regards to the traditional BSD partitioning scheme, having a separate /usr, /home, /tmp, etc... there's no reason to do that stuff any more with ZFS (or HAMMER). You just need one, and can break it down into separate management domains within the filesystem (e.g. HAMMER PFS's). That's a generic statement of course, there will always be situations where you might want to partition things out separately. Most linux dists don't bother with multiple partitions any more. They just have '/' and maybe a small boot partition, and that's it. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
On 10/11/08, Matthew Dillon [EMAIL PROTECTED] wrote: With regards to the traditional BSD partitioning scheme, having a separate /usr, /home, /tmp, etc... there's no reason to do that stuff any more with ZFS (or HAMMER). As separate partitions, no. As separate filesystems, definitely. While HAMMER PFSes may not support these things yet, ZFS allows you to tailor each filesystem to its purpose. For example, you can enable compression on /usr/ports, but have a separate /usr/ports/distfilles and /usr/ports/work that aren't compressed. Or /usr/src compressed and /usr/obj not. Have a small record (block) size for /usr/src, but a larger one for /home. Give each user a separate filesystem for their /home/username, with separate snapshot policies, quotas, and reservations (initial filesystem size). Creating new filesystems with ZFS is as simple as zfs create -o mountpoint=/wherever pool/fsname. If you put a little time into planning the hierarchy/structure, you can take advantage off the properties inheritance features of ZFS as well. You just need one, and can break it down into separate management domains within the filesystem (e.g. HAMMER PFS's). Similar kind of idea. Most linux dists don't bother with multiple partitions any more. They just have '/' and maybe a small boot partition, and that's it. Heh, that's more proof of the difficulties inherent with old-school disk partitioning, compared to pooled storage setups, than an endorsement of using a single partition/filesystem. :) -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Matt, Matthew Dillon wrote: [...] /boot can be as complex as boot2 allows. There's nothing preventing it from being RAIDed if boot2 supported that, and there's nothing preventing it (once you had ZFS boot capabilities) from being ZFS using a topology supported by boot2. Having a sparate /boot allows your filesystem root to use topologues boot2 would otherwise not support. I believe that it's a good idea to separate / from the zpool for other file systems, or even use a UFS /. My experience with ZFS on my laptop shows that disk failures can be more easily fixed if there are some utilities available in the UFS /, even when ZFS is used as /. Another issue with a ZFS / is that the snapshot rollback feature generally does not work on / since it needs the mountpoint to be unmounted. One thing that I found very useful is the new GPT boot feature on 8.0, which also works on older BIOS because the protected MBR would deal with the bootstrap to the actual GPT boot. Now we have a 15-block sized gptboot that can boot FreeBSD from UFS, however this 'boot' can be in virtually any size that the BIOS supports, so we can embed more logic there. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjxHV0ACgkQi+vbBBjt66CpXgCfWstsxNc3B4xOzNTxz9/kdl3Y /WYAnjqiV5H8xQYxGgZTnwWieuG6ZZij =LH+x -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS boot
On Sat, 11 Oct 2008, Pegasus Mc Cleaft wrote: FWIW, my system is amd64 with 1 G of memory, which the page implies is insufficient. Is it really? This may be purely subjective, as I have never bench marked the speeds, but when I was first testing zfs on a i386 machine with 1gig ram, I thought the performance was mediocre. However, when I loaded the system on a quad core - core2 with 8 gigs ram, I was quite impressed. I put localized changes in my /boot/loader.conf to give the kernel more breathing room and disabled the prefetch for zfs. #more loader.conf vm.kmem_size_max=1073741824 vm.kmem_size=1073741824 vfs.zfs.prefetch_disable=1 I was somewhat confused by the suggestions on the wiki. Do the kmem_size sysctls affect the allocation of *memory* or of *address space*? It seems a bit much to reserve 1 G of memory solely for the use of the kernel, expecially in my case when that's all I have :) But on amd64, it's welcome to have terabytes of address space if it will help. The best advice I can give is for you to find an old machine and test-bed zfs for yourself. I personally have been pleased with it and It has saved my machines data 4 times already (dieing hardware, unexpected power bounces, etc) Sure, but if my new machine isn't studly enough to run it, there's no hope for an old machine. So I'm trying to figure out what I actually need. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
