Re: PCIe SATA HBA for ZFS on -STABLE
On 7 June 2011 12:03, Matthew Dillon dil...@apollo.backplane.com wrote: The absolute cheapest solution is to buy a Sil-3132 PCIe card (providing 2 E-SATA ports), and then connect an external port multiplier to each port. External port multiplier enclosures typically support 5 drives each so that would give you your 10 drives. I've decided to avoid issues with port multiplication by going for a Supermicro AOC-USAS2-L8i and then to flash it to IT (as opposed to IR) mode to make it run as a standard non-RAID HBA. As I've got 8 x 2 TB drives for the ZFS raidz2 I'll put them all on the AOC-USAS2-L8i and save my onboard SATA-II ports for my 2 x 1TB drives for the FreeBSD O.S. and any eSATA use. Now the only remaining issue is whether to go with the Supermicro firmware or the generic Lsi Logic firmware as some have reported better performance with the version 9 Lsi Logic firmware. I'll report on my experiences (as I keep a record of the revision of my -STABLE build this should actually be useful!). ___ 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
v4l2 8-stable MFC: testers needed
Hi, at http://www.Leidinger.net/test/v4l2-stable8.diff I have the v4l2 code I want to commit to 8-stable. Can someone please compile it, test it and give feedback? Bye, Alexander. -- How many people work here? Oh, about half. 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: hast syncronization speed issue
On Thu, 2 Jun 2011 11:47:26 +0300 Yurius Radomskyi wrote: YR Hi, YR I have a HAST device set up between two systems. I experience very low YR speed with dirty blocks synchronization after split-brain condition YR been recovered: it's 200KB/s average on 1Gbit link. On the other side, YR when i copy a big file to the zfs partition that is created on top of YR the hast device the synchronization speed between the host is 50MB/s YR (wich is not too high for 1Gbit link, but acceptable.) Could you please try the patch (the kernel needs rebuilding)? http://people.freebsd.org/~trociny/uipc_socket.c.patch The patch was committed to current (r222454) and is going to be MFCed after some time. -- Mikolaj Golub ___ 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: Unusable hastd in FreeBSD 8.2
Hi, On Mon, 6 Jun 2011 16:46:55 +0200 Victor Balada Diaz wrote: VBD Hello, VBD Hastd in it's current form is not usable on FreeBSD 8.2-RELEASE or in 8-STABLE. You VBD can see why in this thread: VBD http://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010752.html VBD You can see the committed fix in: VBD http://svnweb.freebsd.org/base?view=revisionrevision=219721 VBD But it's never been MFCd. Is it possible to MFC it to 8-STABLE and maybe VBD do an errata notice for RELENG_8_2? Actually, it was MFCed. In r220151. Also, I don't think this is an issue that makes hastd unusable in FreeBSD 8.2 :-). The issue is the following. Before switching the node to primary the failover (third-party) script is checking if secondary process is still alive (assuming that in this case the primary on another node is still alive too) and fails if it is -- some protection against split brain. But before r219721 secondary might not die automatically when primary host was down. This can be workarounded. E.g. by removing the check in the script :-). Or setting net.inet.tcp.keepidle to some small value (e.g. 10 seconds) -- this should make secondary notice that another end is dead after this interval. -- Mikolaj Golub ___ 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
labelling root file system (RELENG_8)
Greetings, I've tried to re-label an existing (and up to date) 8-STABLE installation's root partition. This failed, tunefs reports it cannot write the super block. I have attempted this sequence: 1. reboot (through BIOS and loader) directly into single-user mode (boot -s) 2. sysctl kern.geom.debugflags=16 3. tunefs -L root /dev/ada0s4a# that's the dev I mount the root # partition from Still no joy = tunefs cannot update the super block. Remounting / as rw doesn't help, as expected. The root fs uses softupdates but no journalling -- what other hoops do I need to jump through to create labels for my root ufs file system? Thanks. Best regards, Matthias ___ 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: labelling root file system (RELENG_8)
1. Change your root fstab record to /dev/ada0s4a (not label!), reboot to single mode and try to re-label partition. 2. Try boot from live CD or installation CD (fixup console) and label file system without mounting 2011/6/8 Matthias Andree matthias.and...@gmx.de: Greetings, I've tried to re-label an existing (and up to date) 8-STABLE installation's root partition. This failed, tunefs reports it cannot write the super block. I have attempted this sequence: 1. reboot (through BIOS and loader) directly into single-user mode (boot -s) 2. sysctl kern.geom.debugflags=16 3. tunefs -L root /dev/ada0s4a # that's the dev I mount the root # partition from Still no joy = tunefs cannot update the super block. Remounting / as rw doesn't help, as expected. The root fs uses softupdates but no journalling -- what other hoops do I need to jump through to create labels for my root ufs file system? Thanks. Best regards, Matthias ___ 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 --- wbr, Nickolas ___ 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
Renaming ZFS datasets without unmount.
When I try to rename a mounted dataset with open files, I get the following error : [carenath] /home/tzim# zfs rename unsafe/tmp unsafe/temp cannot unmount '/tmp': Device busy The mountpoint property is set locally : [carenath] /home/tzim# zfs get mountpoint unsafe/tmp NAMEPROPERTYVALUE SOURCE unsafe/tmp mountpoint /tmplocal zfs(1M) says : Renamed file systems can inherit new mount points, in which case they are unmounted and remounted at the new mount point. But here, the mountpoint should not change. So the file system does not need to be remounted ... Either I don't understand something, or there's an error in the man, or a bug in zfs rename. It could be great if zfs allowed live renaming of mounted filesystem, as It can avoid headaches... Thanks Arnaud Houdelette ___ 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
[SOLVED] Re: labelling root file system (RELENG_8)
Am 08.06.2011 15:11, schrieb nickolas...@gmail.com: 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot to single mode and try to re-label partition. Indeed not mounting from the label was (apparently) the key to solve this. Thank you. In fact the successful procedure was: - from boot menu, escape to loader prompt - set vfs.root.mountfrom=ufs:/dev/ada0s4a - boot -s - tunefs -L mylabel /dev/ada0s4a - mount -a - edit /etc/fstab to use /dev/ufs/mylabel as device for / - shutdown -r now Best regards, Matthias ___ 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: v4l2 8-stable MFC: testers needed
Quoting Alexander Leidinger alexan...@leidinger.net (from Wed, 08 Jun 2011 14:01:10 +0200): at http://www.Leidinger.net/test/v4l2-stable8.diff I have the v4l2 code I want to commit to 8-stable. Can someone please compile it, test it and give feedback? It looks like svn does not take added files into account, so everyone who wants to give it a try should take linux_videodev2.h and linux_videodev2_compat.h from -current. Bye, Alexander. -- I need a guy I can trust. Yeah, OK, let me think about it. -- Johnny Fontane and Nino Valenti, Chapter 12, page 177 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: [SOLVED] Re: labelling root file system (RELENG_8)
On Wed, Jun 08, 2011 at 04:02:43PM +0200, Matthias Andree wrote: Am 08.06.2011 15:11, schrieb nickolas...@gmail.com: 1. Change your root fstab record to /dev/ada0s4a (not label!), reboot to single mode and try to re-label partition. Indeed not mounting from the label was (apparently) the key to solve this. Thank you. In fact the successful procedure was: - from boot menu, escape to loader prompt - set vfs.root.mountfrom=ufs:/dev/ada0s4a - boot -s - tunefs -L mylabel /dev/ada0s4a - mount -a - edit /etc/fstab to use /dev/ufs/mylabel as device for / - shutdown -r now I have the exact same question except not with regards to labels but toggling TRIM capability on the root filesystem. - Start system - At loader, boot single-user (option 4) - At prompt choose /bin/sh - mount -a - tunefs -t enable /dev/ada0s1a --- fails - sysctl kern.geom.debugflags=16 - tunefs -t enable /dev/ada0s1a --- works - tunefs -p /dev/ada0s1a -- shows TRIM enabled - reboot - Boot into single-user, multi-user, whatever - tunefs -p /dev/ada0s1a -- shows TRIM disabled -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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: [SOLVED] Re: labelling root file system (RELENG_8)
on 08/06/2011 19:26 Jeremy Chadwick said the following: I have the exact same question except not with regards to labels but toggling TRIM capability on the root filesystem. - Start system - At loader, boot single-user (option 4) - At prompt choose /bin/sh - mount -a I think that this is a culprit. - tunefs -t enable /dev/ada0s1a --- fails Shouldn't you have / mounted r/o here? BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never been mounted r/w. - sysctl kern.geom.debugflags=16 - tunefs -t enable /dev/ada0s1a --- works - tunefs -p /dev/ada0s1a -- shows TRIM enabled - reboot I think that at this step your superblock on disk gets re-written with its copy in memory which has never been updated. But not sure. - Boot into single-user, multi-user, whatever - tunefs -p /dev/ada0s1a -- shows TRIM disabled -- 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: [SOLVED] Re: labelling root file system (RELENG_8)
On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote: on 08/06/2011 19:26 Jeremy Chadwick said the following: I have the exact same question except not with regards to labels but toggling TRIM capability on the root filesystem. - Start system - At loader, boot single-user (option 4) - At prompt choose /bin/sh - mount -a I think that this is a culprit. I'll try removing this step. - tunefs -t enable /dev/ada0s1a --- fails Shouldn't you have / mounted r/o here? BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never been mounted r/w. I'm a little confused by this sentence, so my apologise in advance. / is mounted read-only in single-user by default. Did you mean I should make it r/w by doing mount -u -o rw / ? I may have omitted this step. I will re-verify the exact procedure and exact steps in a moment, and reply here. - sysctl kern.geom.debugflags=16 - tunefs -t enable /dev/ada0s1a --- works - tunefs -p /dev/ada0s1a -- shows TRIM enabled - reboot I think that at this step your superblock on disk gets re-written with its copy in memory which has never been updated. But not sure. Hmm, I sure hope that isn't the case. That would mean the only time a person can use tunefs on a root filesystem is when they either do it manually during the FreeBSD installation (adding -t to the list of newfs flags in the filesystem creation UI), or if they boot off of some other medium (USB flash drive, CD, PXE, etc.). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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: [SOLVED] Re: labelling root file system (RELENG_8)
On Wed, Jun 08, 2011 at 09:55:15AM -0700, Jeremy Chadwick wrote: On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote: on 08/06/2011 19:26 Jeremy Chadwick said the following: I have the exact same question except not with regards to labels but toggling TRIM capability on the root filesystem. - Start system - At loader, boot single-user (option 4) - At prompt choose /bin/sh - mount -a I think that this is a culprit. I'll try removing this step. - tunefs -t enable /dev/ada0s1a --- fails Shouldn't you have / mounted r/o here? BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never been mounted r/w. I'm a little confused by this sentence, so my apologise in advance. / is mounted read-only in single-user by default. Did you mean I should make it r/w by doing mount -u -o rw / ? I may have omitted this step. I will re-verify the exact procedure and exact steps in a moment, and reply here. - sysctl kern.geom.debugflags=16 - tunefs -t enable /dev/ada0s1a --- works - tunefs -p /dev/ada0s1a -- shows TRIM enabled - reboot I think that at this step your superblock on disk gets re-written with its copy in memory which has never been updated. But not sure. Hmm, I sure hope that isn't the case. That would mean the only time a person can use tunefs on a root filesystem is when they either do it manually during the FreeBSD installation (adding -t to the list of newfs flags in the filesystem creation UI), or if they boot off of some other medium (USB flash drive, CD, PXE, etc.). Interestingly enough, the long procedure I originally described is probably what was causing the problem. Not sure how to phrase it. The exact procedure which worked was: - Start system - Boot into single-user - Hit enter at prompt (choose /bin/sh) - mount --- shows root filesystem mounted read-only (normal) - tunefs -t enable /dev/ada0s1a --- says it enabled TRIM support - tunefs -p /dev/ada0s1a --- shows TRIM support enabled - reboot - After system starts, as root: tunefs -p /dev/ada0s1a --- shows TRIM enabled So the extra rigmarole I was doing somehow caused the problem. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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: [SOLVED] Re: labelling root file system (RELENG_8)
On Wed, Jun 8, 2011 at 10:05 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: Interestingly enough, the long procedure I originally described is probably what was causing the problem. Not sure how to phrase it. I don't have a reference for this, but I'm pretty sure it was on one of the mailing lists at some point. The kernel reads the super-block into memory and uses that copy when the file system is mounted. If you have the it mounted rw, then at unmount it is written back out to the disk. If it's mounted ro, the in-memory copy is thrown out and the disk isn't changed. If you upgrade a file system from ro to rw, it does not re-read the on disk copy. tunefs directly modifies on the on-disk copy regardless of mount status, so when you unmount a rw file system, anything it has done is overwritten. The only way to modify / (without alternate boot media) is what you've described below: boot single user, leave it ro, tunefs, then reboot while still ro. Also, I've seen the sysctl kern.geom.debugflags=16 thing in zfs tutorials and such, but haven't seen where it's actually necessary. I think this is outdated and changed circa 8.0. -- Rob Farmer The exact procedure which worked was: - Start system - Boot into single-user - Hit enter at prompt (choose /bin/sh) - mount --- shows root filesystem mounted read-only (normal) - tunefs -t enable /dev/ada0s1a --- says it enabled TRIM support - tunefs -p /dev/ada0s1a --- shows TRIM support enabled - reboot - After system starts, as root: tunefs -p /dev/ada0s1a --- shows TRIM enabled So the extra rigmarole I was doing somehow caused the problem. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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: [SOLVED] Re: labelling root file system (RELENG_8)
on 08/06/2011 19:55 Jeremy Chadwick said the following: On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote: on 08/06/2011 19:26 Jeremy Chadwick said the following: I have the exact same question except not with regards to labels but toggling TRIM capability on the root filesystem. - Start system - At loader, boot single-user (option 4) - At prompt choose /bin/sh - mount -a I think that this is a culprit. I'll try removing this step. - tunefs -t enable /dev/ada0s1a --- fails Shouldn't you have / mounted r/o here? BTW, AFAIR, *re*-mounting root read-only won't help; it needs to have never been mounted r/w. I'm a little confused by this sentence, so my apologise in advance. / is mounted read-only in single-user by default. Did you mean I should make it r/w by doing mount -u -o rw / ? I may have omitted this step. No. My English is not perfect it seems - my point was that you should never mount your root fs r/w if you want to do tunefs on it. I will re-verify the exact procedure and exact steps in a moment, and reply here. - sysctl kern.geom.debugflags=16 - tunefs -t enable /dev/ada0s1a --- works - tunefs -p /dev/ada0s1a -- shows TRIM enabled - reboot I think that at this step your superblock on disk gets re-written with its copy in memory which has never been updated. But not sure. Hmm, I sure hope that isn't the case. I think that this is the case. That would mean the only time a person can use tunefs on a root filesystem is when they either do it manually during the FreeBSD installation (adding -t to the list of newfs flags in the filesystem creation UI), or if they boot off of some other medium (USB flash drive, CD, PXE, etc.). Or when your root fs is mounted r/o, which is not as bad as what you listed above. -- 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: v4l2 8-stable MFC: testers needed
On Wed, Jun 08, 2011 at 04:38:22PM +0200, Alexander Leidinger wrote: Quoting Alexander Leidinger alexan...@leidinger.net (from Wed, 08 Jun 2011 14:01:10 +0200): at http://www.Leidinger.net/test/v4l2-stable8.diff I have the v4l2 code I want to commit to 8-stable. Can someone please compile it, test it and give feedback? It looks like svn does not take added files into account, so everyone who wants to give it a try should take linux_videodev2.h and linux_videodev2_compat.h from -current. Looking good... skype at least works. :) Thanx, Juergen ___ 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: [SOLVED] Re: labelling root file system (RELENG_8)
That would mean the only time a person can use tunefs on a root filesystem is when they either do it manually during the FreeBSD installation (adding -t to the list of newfs flags in the filesystem creation UI), or if they boot off of some other medium (USB flash drive, CD, PXE, etc.). Or when your root fs is mounted r/o, which is not as bad as what you listed above. Perhaps I'm doing something wrong, but in my experience, at least with glabel, the label will not stick even if you have the root fs mounted ro. I have had to boot from an alternative media (boot cd, alternate root fs, etc) in order to create a label for the root fs with glabel. To be specific, I'm talking about the automatic labels created with glabel label name dev. I just tested this again in a VM, and sure enough if I boot single user mode but use ad0s1a as the ro root file system during single user mode, it still doesn't stick and upon reboot I don't have a /dev/label entry. Here is the exact sequence I used: 1. boot single user with the default root fs (ad0s1a). 2. leave / mounted read only 3. glabel label -v root ad0s1a # reports successful addition of metadata 4. /dev/label/root exists as expected 5. reboot 6. /dev/label/root does not exist If I boot from a boot cd for example and do it from there, it works fine. So it seems (at least for glabel) that you can't have the fs mounted at all when adding a glabel. If that's the expected behavior, perhaps we can add a mention of this in the man page(s)? Otherwise, I'm curious what I'm doing wrong and how I can get it to stick and still not need a boot CD/etc. Thanks, Josh ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication - triple parity RAIDZ (RAIDZ3) - zfs diff - zpool split - snapshot holds - zpool import -F. Allows to rewind corrupted pool to earlier transaction group - possibility to import pool in read-only mode For updating, there is a compatibility layer so that in the update phase most functionality of the new zfs binaries can be used with the old kernel module and old zfs binaries with the new kernel module. Beware that the compatibility layer is known broken on big-endian architectures, i.e. powerpc64 and sparc64. If upgrading your boot pool to version 28, please don't forget to read UPDATING and properly update your boot code. Thanks to everyone working on the ZFS port, especially to Pawel Jakub Dawidek (pjd) for doing most of the work! Marius ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Thu, Jun 09, 2011 at 12:46:19AM +0200, C. P. Ghost wrote: On Wed, Jun 8, 2011 at 11:12 PM, Marius Strobl mar...@alchemy.franken.de wrote: On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication - triple parity RAIDZ (RAIDZ3) - zfs diff - zpool split - snapshot holds - zpool import -F. Allows to rewind corrupted pool to earlier ? transaction group - possibility to import pool in read-only mode For updating, there is a compatibility layer so that in the update phase most functionality of the new zfs binaries can be used with the old kernel module and old zfs binaries with the new kernel module. Beware that the compatibility layer is known broken on big-endian architectures, i.e. powerpc64 and sparc64. Thanks for the heads-up! I was just about to update a couple of sparc64 machines here. Fortunately, the only ZFS file systems there are external file systems (no /, /usr, /var etc...), so it's gonna be painless, I suppose. But what about other layouts? Does it mean that an installkernel, reboot, and installworld won't work? No, using the old zfs binaries with the new kernel module triggers the problem. Using the new zfs binaries with the new kernel module works (at least with CURRENT) so you'd need disregard everything that is documented and do what is not guaranteed to work but usually also does, i.e. do installkernel, installworld and then reboot. If upgrading your boot pool to version 28, please don't forget to read UPDATING and properly update your boot code. Thanks to everyone working on the ZFS port, especially to Pawel Jakub Dawidek (pjd) for doing most of the work! Marius ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Thu, Jun 9, 2011 at 12:55 AM, Marius Strobl mar...@alchemy.franken.de wrote: On Thu, Jun 09, 2011 at 12:46:19AM +0200, C. P. Ghost wrote: On Wed, Jun 8, 2011 at 11:12 PM, Marius Strobl mar...@alchemy.franken.de wrote: On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication - triple parity RAIDZ (RAIDZ3) - zfs diff - zpool split - snapshot holds - zpool import -F. Allows to rewind corrupted pool to earlier ? transaction group - possibility to import pool in read-only mode For updating, there is a compatibility layer so that in the update phase most functionality of the new zfs binaries can be used with the old kernel module and old zfs binaries with the new kernel module. Beware that the compatibility layer is known broken on big-endian architectures, i.e. powerpc64 and sparc64. Thanks for the heads-up! I was just about to update a couple of sparc64 machines here. Fortunately, the only ZFS file systems there are external file systems (no /, /usr, /var etc...), so it's gonna be painless, I suppose. But what about other layouts? Does it mean that an installkernel, reboot, and installworld won't work? No, using the old zfs binaries with the new kernel module triggers the problem. Using the new zfs binaries with the new kernel module works (at least with CURRENT) so you'd need disregard everything that is documented and do what is not guaranteed to work but usually also does, i.e. do installkernel, installworld and then reboot. Ah, yes, that's what I expected. Thank you! -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: HEADS UP: ZFS v28 merged to 8-STABLE
On Wed, Jun 8, 2011 at 11:12 PM, Marius Strobl mar...@alchemy.franken.de wrote: On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication - triple parity RAIDZ (RAIDZ3) - zfs diff - zpool split - snapshot holds - zpool import -F. Allows to rewind corrupted pool to earlier transaction group - possibility to import pool in read-only mode For updating, there is a compatibility layer so that in the update phase most functionality of the new zfs binaries can be used with the old kernel module and old zfs binaries with the new kernel module. Beware that the compatibility layer is known broken on big-endian architectures, i.e. powerpc64 and sparc64. Thanks for the heads-up! I was just about to update a couple of sparc64 machines here. Fortunately, the only ZFS file systems there are external file systems (no /, /usr, /var etc...), so it's gonna be painless, I suppose. But what about other layouts? Does it mean that an installkernel, reboot, and installworld won't work? If upgrading your boot pool to version 28, please don't forget to read UPDATING and properly update your boot code. Thanks to everyone working on the ZFS port, especially to Pawel Jakub Dawidek (pjd) for doing most of the work! Marius Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
