ZPOOL import failure due to multiple pool IDs?
I have trouble with a ZFS pool after interrupted scrubbing on FreeBSD 10-CURREN (10.0-CURRENT #1 r253579: Tue Jul 23 20:31:59 CEST 2013 amd64). After I shut down the box while the ZFS pool in question was still in scrubbing, after a reboot the system marked that pool as defect. I tried to clean the reported data corruption by adding the -F flag to the import, but surprisingly, the pool has ambigious IDs confusing the system (and me): pool: BACKUP00 id: 257822624560506537 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-72 config: BACKUP00FAULTED corrupted data ada3p1ONLINE pool: BACKUP00 id: 9337833315545958689 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: BACKUP00 FAULTED corrupted data 8544670861382329237 UNAVAIL corrupted data I do not know what happens here. The pool has been upgraded twice as far as I remember, since the disk/device is used as a compressed backup device and only used for that purpose. But for a couple of time now with FreeBSD 10, it starts to fail when the scrubbing is interrupted by a shutdown. I remember that scrubbing of pools sesumed after the next reboot - but I realised that this seems to be a problem now for some reason on FreeBSD 10. I had a situation like this earlier this year with the same device - amongst another pool after scrubbing didn't resumed as expected. The import of the pool above in question works by using the very first id: id: 257822624560506537. But what is with the other IDs? What are those IDs and labels doing here? Is it possible that ZFS has some bugs revealing older labels/GUIDs of the device from a earlier configuration than the last one configured and prepared for? How can I get rid of those fake/phantom id? Rgards, Oliver signature.asc Description: PGP signature
Re: ZPOOL import failure due to multiple pool IDs?
What does zdb on each device report? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r253070 and disappearing zpool
on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: I think that this setup (on ZFS level) is quite untypical, although not impossible on FreeBSD (and perhaps only FreeBSD). It's untypical because you have separate boot pool (where loader, loader.conf and kernel are taken from) and root pool (where / is mounted from). As I said elsewhere, it is pretty typical when full disk encryption is used. I am judging by the number of reports / amount of feedback so far. The /boot/ has to be unencrypted and can be stored on eg. USB pendrive which is never left unattended, unlike laptop which can be left in eg. a hotel room, but with entire disk encrypted. As we discussed elsewhere, there are many options of configuring full disk encryption. Including decisions whether root filesystem should be separate from boot filesystem, choice of filesystem type for boot fs, ways of tying various pieces together, and many more. I do not believe that my change is incompatible with full disk encryption in general. So, I see three ways of resolving the problem that my changes caused for your configuration. 1. [the easiest] Put zpool.cache loading instructions that used to be in defaults/loader.conf into your loader.conf. This way everything should work as before -- zpool.cache would be loaded from your boot pool. 2. Somehow (I don't want to go into any technical details here) arrange that your root pool has /boot/zfs/zpool.cache that describes your boot pool. This is probably hard given that your /boot is a symlink at the moment. This probably would be easier to achieve if zpool.cache lived in /etc/zfs. 3. [my favorite] Remove an artificial difference between your boot and root pools, so that they are a single root+boot pool (as zfs gods intended). As far as I understand your setup, you use GELI to protect some sensitive data. Apparently your kernel is not sensitive data, so I wonder if your /bin/sh or /sbin/init are really sensitive either. So perhaps you can arrange your unencrypted pool to hold all of the base system (boot + root) and put all your truly sensitive filesystems (like e.g. /home or /var/data or /opt/xyz) onto your encrypted pool. If all you care about is laptop being stolen, then that would work. If you however want to be protected from someone replacing your /sbin/init with something evil then you use encryption or even better integrity verification also supported by GELI. There are different ways to ensure that. Including storing cryptographic checksums in a safe place or keeping init in the same place where kernel is kept. And probably many more. Remember, tools not policies. I am not trying to enforce any policy on end-users here. There is also option number 4 - backing out your commit. That's definitely an option. I'll discuss it a few lines below. When I saw your commit removing those entries from defaults/loader.conf, I thought it is fine, as we now don't require zpool.cache to import the root pool, which was, BTW, very nice and handy improvement. Now that we know it breaks existing installations I'd prefer the commit to be backed out. breaks sounds dramatic, but let's take a step back and see what exactly is broken. The system in question still can boot without a problem, it is fully usable and it is possible to change its configuration without any hassle. The only thing that changed is that its boot pool is not imported automatically. Let's also recall that the system was not created / configured by any of the existing official or semi-official tools and thus it does not represent any recommended way of setting up such systems. Glen configured it this way, but it doesn't mean that that is the way. I think that there are many of ways of changing configuration of that system to make behave as before again. Three I mentioned already. Another is to add rc script to import the boot pool, given that it is a special, designated pool. Yet another is to place zpool.cache onto the root pool and use nullfs (instead of a symlink) to make /boot be from the boot pool but /boot/zfs be from the root pool. This is because apart from breaking some existing installations it doesn't gain us anything. I think I addressed the breaking part, as to the gains - a few lines below. So I understand that my change causes a problem for a setup like yours, but I believe that the change is correct. The change is clearly incorrect or incomplete as it breaks existing installations and doesn't allow for full disk encryption configuration on ZFS-only systems. I think I addressed the breaking part and also addressed your overly general statement about full disk encryption. So I don't think that my change is clearly incorrect, otherwise that would be clear even to me. BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's fine by me, although the migration
Re: Panic at USB drive plugging in
On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin m...@freebsd.org wrote: cam.k kernel module includes all existing periph drivers in one bundle. Loading cam.ko you are probably getting sg driver also, that triggers reported issue. You may try to rip out sg with single line hack to module's Makefile. The real fix require looking closer on sg, which I never used. Indeed. Test result did confirm that if sg is not included in cam.ko USB drives will not cause kernel to panic. Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FUSE not work.
20.07.2013 18:02, Pedro Giffuni пишет: On 19.07.2013 23:42, Kevin Oberman wrote: ... fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. I reverted my incompatible changes and will try to see if upstream wants to adopt something compatible for birthtime support. I do agree that fuse needs a lot of work. I wonder if NetBSD's puffs/libperfuse is any better. Pedro. Can we expect in the near future a working version of FUSE to FreeBSD 10? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FUSE not work.
On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni p...@freebsd.org wrote: On 19.07.2013 12:07, Alexander Panyushkin wrote: 19.07.2013 19:42, Pedro Giffuni пишет: (re-posting since the original response didn't make it through) On 19.07.2013 10:29, Alexander Panyushkin wrote: 19.07.2013 17:36, Pedro Giffuni пишет: Hello; The internal data structures in the FUSE kernel module have been updated to be more compatible with MacFUSE and the linux FUSE. This basically means you have to rebuild your fuse modules (including NTFS). We should not really update the FUSE_KERNEL_MINOR_VERSION yet. I will add a note to UPDATING. Pedro. Unfortunately the port is not build in FreeBSD 10 === Starting build for sysutils/fusefs-kmod === fusefs-kmod is not needed on -current. I meant you have to rebuild and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. Since this is a ports issue I will not update the UPDATING file. Developers that need to know should use __FreeBSD_version 138 as a reference. I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. sysctl kern.osreldate kern.osreldate: 137 ntfs-3g /dev/ad10s1 /mnt/ntfs_0 mount ... /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) ls -la /mnt/ntfs_0 unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 getattr / unique: 18, success, outsize: 112 fuse: writing device: Invalid argument ls: /mnt/ntfs_0: Input/output error fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. This is fixed now. btw this problem is/was not related to fuse on current but rather to fusefs-libs. Bapt pgpEeB1tpnkMj.pgp Description: PGP signature
Re: FUSE not work.
24.07.2013 18:22, Baptiste Daroussin пишет: On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni p...@freebsd.org wrote: On 19.07.2013 12:07, Alexander Panyushkin wrote: 19.07.2013 19:42, Pedro Giffuni пишет: (re-posting since the original response didn't make it through) On 19.07.2013 10:29, Alexander Panyushkin wrote: 19.07.2013 17:36, Pedro Giffuni пишет: Hello; The internal data structures in the FUSE kernel module have been updated to be more compatible with MacFUSE and the linux FUSE. This basically means you have to rebuild your fuse modules (including NTFS). We should not really update the FUSE_KERNEL_MINOR_VERSION yet. I will add a note to UPDATING. Pedro. Unfortunately the port is not build in FreeBSD 10 === Starting build for sysutils/fusefs-kmod === fusefs-kmod is not needed on -current. I meant you have to rebuild and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. Since this is a ports issue I will not update the UPDATING file. Developers that need to know should use __FreeBSD_version 138 as a reference. I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. sysctl kern.osreldate kern.osreldate: 137 ntfs-3g /dev/ad10s1 /mnt/ntfs_0 mount ... /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) ls -la /mnt/ntfs_0 unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 getattr / unique: 18, success, outsize: 112 fuse: writing device: Invalid argument ls: /mnt/ntfs_0: Input/output error fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. This is fixed now. btw this problem is/was not related to fuse on current but rather to fusefs-libs. Bapt I am rebuilding now world uname -a FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul 24 20:34:19 EEST 2013 r...@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel amd64 and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 Problem not fixed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
poudriere problems with fuse?
Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. What's the story here? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: poudriere problems with fuse?
On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. Nah poudriere does not use yet fuse :) What's the story here? I was about to mail you :) It is broken since r248084 apparently the update on the fuse_kernel.h you did is not in sync with fusefs-libs, resulting in no filesystem to properly work. Do you have any insight on the reason of the changes? and I should look at? regards, Bapt pgpwF9O7B_NYc.pgp Description: PGP signature
Re: poudriere problems with fuse?
Hi; El 24/07/2013 1:22 p. m., Adrian Chadd escribió: Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. What's the story here? I reverted all my birthtime changes, the remaining change is only a header update from upstream that helps things get in line with the header included in the port. I have no idea what may be broken but it predates my short involvement with fuse. Sorry that I have no responsible answer :(. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FUSE not work.
On Wed, Jul 24, 2013 at 09:16:44PM +0300, Alexander Panyushkin wrote: 24.07.2013 18:22, Baptiste Daroussin пишет: On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni p...@freebsd.org wrote: On 19.07.2013 12:07, Alexander Panyushkin wrote: 19.07.2013 19:42, Pedro Giffuni пишет: (re-posting since the original response didn't make it through) On 19.07.2013 10:29, Alexander Panyushkin wrote: 19.07.2013 17:36, Pedro Giffuni пишет: Hello; The internal data structures in the FUSE kernel module have been updated to be more compatible with MacFUSE and the linux FUSE. This basically means you have to rebuild your fuse modules (including NTFS). We should not really update the FUSE_KERNEL_MINOR_VERSION yet. I will add a note to UPDATING. Pedro. Unfortunately the port is not build in FreeBSD 10 === Starting build for sysutils/fusefs-kmod === fusefs-kmod is not needed on -current. I meant you have to rebuild and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. Since this is a ports issue I will not update the UPDATING file. Developers that need to know should use __FreeBSD_version 138 as a reference. I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. sysctl kern.osreldate kern.osreldate: 137 ntfs-3g /dev/ad10s1 /mnt/ntfs_0 mount ... /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) ls -la /mnt/ntfs_0 unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 getattr / unique: 18, success, outsize: 112 fuse: writing device: Invalid argument ls: /mnt/ntfs_0: Input/output error fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. This is fixed now. btw this problem is/was not related to fuse on current but rather to fusefs-libs. Bapt I am rebuilding now world uname -a FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul 24 20:34:19 EEST 2013 r...@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel amd64 and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 Problem not fixed. Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version and it will work, I'm investigating. What I fix is the umount umounting all the FS. regards, Bapt pgpBsJYlDxe6n.pgp Description: PGP signature
Re: FUSE not work.
On Wed, Jul 24, 2013 at 08:36:10PM +0200, Baptiste Daroussin wrote: On Wed, Jul 24, 2013 at 09:16:44PM +0300, Alexander Panyushkin wrote: 24.07.2013 18:22, Baptiste Daroussin пишет: On Fri, Jul 19, 2013 at 09:42:41PM -0700, Kevin Oberman wrote: On Fri, Jul 19, 2013 at 6:22 PM, Pedro Giffuni p...@freebsd.org wrote: On 19.07.2013 12:07, Alexander Panyushkin wrote: 19.07.2013 19:42, Pedro Giffuni пишет: (re-posting since the original response didn't make it through) On 19.07.2013 10:29, Alexander Panyushkin wrote: 19.07.2013 17:36, Pedro Giffuni пишет: Hello; The internal data structures in the FUSE kernel module have been updated to be more compatible with MacFUSE and the linux FUSE. This basically means you have to rebuild your fuse modules (including NTFS). We should not really update the FUSE_KERNEL_MINOR_VERSION yet. I will add a note to UPDATING. Pedro. Unfortunately the port is not build in FreeBSD 10 === Starting build for sysutils/fusefs-kmod === fusefs-kmod is not needed on -current. I meant you have to rebuild and reinstall fusefs-* ; in particular fusesfs-libs and ntfs. Since this is a ports issue I will not update the UPDATING file. Developers that need to know should use __FreeBSD_version 138 as a reference. I rebuild sysutils/fusefs-ntfs with Clang and GCC, but this has no effect. sysctl kern.osreldate kern.osreldate: 137 ntfs-3g /dev/ad10s1 /mnt/ntfs_0 mount ... /dev/fuse on /mnt/ntfs_0 (fusefs, local, synchronous) ls -la /mnt/ntfs_0 unique: 18, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 47053 getattr / unique: 18, success, outsize: 112 fuse: writing device: Invalid argument ls: /mnt/ntfs_0: Input/output error fuse is at least partly broken in -current. I discovered that if you mount two devices that use fuse, when you umount any of them, ll are marked as not mounted and disappear from df(1) or mount(8) output, but only one is actually cleanly unmounted and, if it has been written to, will likely be corrupt. This applies to at least ntfs. ATM no one is supporting fuse in current, so this may become a serious issue before long. This is fixed now. btw this problem is/was not related to fuse on current but rather to fusefs-libs. Bapt I am rebuilding now world uname -a FreeBSD scorpion.kiev.ua 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Wed Jul 24 20:34:19 EEST 2013 r...@scorpion.kiev.ua:/usr/obj/usr/src/sys/Kernel amd64 and ports fusefs-libs-2.9.3 and fusefs-ntfs-2012.1.15 Problem not fixed. Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version and it will work, I'm investigating. What I fix is the umount umounting all the FS. regards, Bapt Forgot to say r248084 is the last working revision. regards, Bapt pgpwYmRLYOH4M.pgp Description: PGP signature
Re: poudriere problems with fuse?
On 24.07.2013 13:34, Baptiste Daroussin wrote: On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. Nah poudriere does not use yet fuse :) What's the story here? I was about to mail you :) It is broken since r248084 apparently the update on the fuse_kernel.h you did is not in sync with fusefs-libs, resulting in no filesystem to properly work. Do you have any insight on the reason of the changes? and I should look at? The change came from upstream. Does it help to revert it all? Another option could be to teach the port to use the kernel header but it doesn't look like that would work either :(. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: poudriere problems with fuse?
On Wed, Jul 24, 2013 at 01:55:21PM -0500, Pedro Giffuni wrote: On 24.07.2013 13:34, Baptiste Daroussin wrote: On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. Nah poudriere does not use yet fuse :) What's the story here? I was about to mail you :) It is broken since r248084 apparently the update on the fuse_kernel.h you did is not in sync with fusefs-libs, resulting in no filesystem to properly work. Do you have any insight on the reason of the changes? and I should look at? The change came from upstream. Does it help to revert it all? Another option could be to teach the port to use the kernel header but it doesn't look like that would work either :(. Yes reverting will help r248084 is the last known working revision. Updating the header should be done with modification on the code itself to implement the missing bits. has some things has changed, I have seen some interesting things https://github.com/bfleischer/fuse-macosx I might probably have a look at it later. Thank you for fast reply, regards, Bapt pgpO2I1da2nei.pgp Description: PGP signature
Re: poudriere problems with fuse?
On 24.07.2013 14:07, Baptiste Daroussin wrote: On Wed, Jul 24, 2013 at 01:55:21PM -0500, Pedro Giffuni wrote: On 24.07.2013 13:34, Baptiste Daroussin wrote: On Wed, Jul 24, 2013 at 11:22:57AM -0700, Adrian Chadd wrote: Hi Pedro, Bapt tells me that there are FUSE issues in the most recent -HEAD and it's stopping poudriere from running. Nah poudriere does not use yet fuse :) What's the story here? I was about to mail you :) It is broken since r248084 apparently the update on the fuse_kernel.h you did is not in sync with fusefs-libs, resulting in no filesystem to properly work. Do you have any insight on the reason of the changes? and I should look at? The change came from upstream. Does it help to revert it all? Another option could be to teach the port to use the kernel header but it doesn't look like that would work either :(. Yes reverting will help r248084 is the last known working revision. I am perfectly OK with reverting, of course. Updating the header should be done with modification on the code itself to implement the missing bits. has some things has changed, I have seen some interesting things https://github.com/bfleischer/fuse-macosx I might probably have a look at it later. I see, there are least two macosx fuse forks but it appears they were merged into osxfuse. Things become rather confusing since we are using the linux fuse-libs with yet another header and NetBSD has a completely different implementation using puffs with librefuse/libperfuse. For now let's just fix things :). Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FUSE not work.
On 24.07.2013 13:49, Baptiste Daroussin wrote: ... Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version and it will work, I'm investigating. What I fix is the umount umounting all the FS. regards, Bapt Forgot to say r248084 is the last working revision. Sorry for the delay, OK, I reverted the kernel header update in revision 253619 hopefully this will save everyone affected some pain ... Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FUSE not work.
On Wed, Jul 24, 2013 at 03:27:07PM -0500, Pedro Giffuni wrote: On 24.07.2013 13:49, Baptiste Daroussin wrote: ... Yes fuse in base is broken since r248084 downgrade sys/fs/fuse to that version and it will work, I'm investigating. What I fix is the umount umounting all the FS. regards, Bapt Forgot to say r248084 is the last working revision. Sorry for the delay, OK, I reverted the kernel header update in revision 253619 hopefully this will save everyone affected some pain ... Thank you very much ! regards, Bapt pgph3aIp6U2z3.pgp Description: PGP signature
Kern.hz= +1 hertz at anything 2500 and above.
http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers Current: What's the chance that the default rate limit can be raised to 5k? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Kern.hz= +1 hertz at anything 2500 and above.
Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit superbisq...@gmail.com wrote: http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers Current: What's the chance that the default rate limit can be raised to 5k? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Kern.hz= +1 hertz at anything 2500 and above.
When I started with FreeBSD on a G3 BW, I noticed that the performance improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may work for other architectures. 4. Some applications may be ran from within a jail. On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd adr...@freebsd.org wrote: Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit superbisq...@gmail.com wrote: http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers Current: What's the chance that the default rate limit can be raised to 5k? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
