Re: [zfs-discuss] Re: Re: Re: ZFS causes panic on import
Stuart, Issuing a 'zpool import' will show all the pools which are accessible for import and that's why you are seeing them. The fact that a forced import gives results in a panic is indicative of pool corruption that resulted from being imported on more than one host. Thanks, George Stuart Low wrote: [EMAIL PROTECTED] ~]$ zpool status -v no pools available [EMAIL PROTECTED] ~]$ [EMAIL PROTECTED] ~]$ zpool status -v no pools available [EMAIL PROTECTED] ~]$ It's like it's "not there" but when I do a zpool import it reports it as there and available just that I need to use -f. Use -f gives me instareboot. :) Stuart This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: Re: ZFS causes panic on import
[EMAIL PROTECTED] ~]$ zpool status -v no pools available [EMAIL PROTECTED] ~]$ [EMAIL PROTECTED] ~]$ zpool status -v no pools available [EMAIL PROTECTED] ~]$ It's like it's "not there" but when I do a zpool import it reports it as there and available just that I need to use -f. Use -f gives me instareboot. :) Stuart This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs panic: assertion failed: zp_error != 0 && dzp_error != 0
Jürgen Keil wrote On 09/04/06 05:24,: I made some powernow experiments on a dual core amd64 box, running the 64-bit debug on-20060828 kernel. At some point the kernel seemed to make no more progress (probably a bug in the multiprocessor powernow code), the gui was stuck, so I typed (blind) F1-A + $ ::status debugging crash dump vmcore.12 (32-bit) from moritz operating system: 5.11 wos_b48_2_debug (i86pc) panic message: assertion failed: zp_error != 0 && dzp_error != 0, file: ../../common/fs/zfs/zfs_acl.c, line: 1537 dump content: kernel pages only ::stack vpanic(fea6bfa4, f85a5984, f85a5964, 601) assfail+0x5a(f85a5984, f85a5964, 601) zfs_zaccess_delete+0x13a(ca45a790, ca45a670, cd1f1e78) zfs_remove+0x88(ca453340, caa5b028, cd1f1e78) fop_remove+0x1e(ca453340, caa5b028, cd1f1e78) zfs_replay_remove+0x57(c94172c0, caa5b000, 0) zil_replay_log_record+0x256(c9da24c0, ca9e2708, ca6ded54, 70cf, 0) zil_parse+0x374(c9da24c0, 0, f8568188, ca6ded54, 70cf, 0) zil_replay+0xba(ca454f88, c94172c0, c94172e4, c50b2c6c, f8572ba0) zfs_domount+0x24a(c58cbf00, c79e89c0, cd1f1588) zfs_mount+0x109(c58cbf00, ca6e4c00, ca6def84, cd1f1588) fsop_mount+0x1a(c58cbf00, ca6e4c00, ca6def84, cd1f1588) domount+0x8ad(0, ca6def84, ca6e4c00, cd1f1588, ca6def48) mount+0x6f(ca6def84, ca6def68) syscall_ap+0x4d() sys_sysenter+0x1a2() Now I see that exactly the same panic with identical stack backtrace has already filed as bug 6466374, http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6466374 But why is bug 6466374 closed as a duplicate of bug 6413510? Only because that bug contained the fix for the problem as during testing I also found the bug. In retrospect we should have opened a new bug for this zfs_zaccess_delete() bug, but chose just to fix it immediately. I'd say that bugs 6466374 and 6413510 are about completely different issues... Yes, indeed. When looking at the code in zfs_zaccess_delete() and zfs_zaccess_common(), it seems that when replaying a "remove" from the log, a debug version of the zfs filesystem module always panics with the "zp_error != 0 && dzp_error != 0" failed assertion. Agreed. Sorry about the problems. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Neil ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Recommendation ZFS on StorEdge 3320
Depends on the workload. (Did I miss that email?) Peter Sundstrom wrote: Hmm. Appears to be differing opinions. Another way of putting my question is can anyone guarantee that ZFS will not perform worse that UFS on the array? High speed performance is not really an issue, hence the reason the disks are mirrored rather than striped. The client is more concerned with redundancy (hence the cautious approach of having 3 hot spares). ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: Recommendation ZFS on StorEdge 3320
Hmm. Appears to be differing opinions. Another way of putting my question is can anyone guarantee that ZFS will not perform worse that UFS on the array? High speed performance is not really an issue, hence the reason the disks are mirrored rather than striped. The client is more concerned with redundancy (hence the cautious approach of having 3 hot spares). This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Recommendation ZFS on StorEdge 3320
UNIX admin wrote: My question is how efficient will ZFS be, given that it will be layered on top of the hardware RAID and write cache? ZFS delivers best performance when used standalone, directly on entire disks. By using ZFS on top of a HW RAID, you make your data susceptible to HW errors caused by the storage subsystem's RAID algorithm, and slow down the I/O. This is simply not true. ZFS would protect against the same type of errors seen on an individual drive as it would on a pool made of HW raid LUN(s). It might be overkill to layer ZFS on top of a LUN that is already protected in some way by the devices internal RAID code but it does not "make your data susceptible to HW errors caused by the storage subsystem's RAID algorithm, and slow down the I/O". True, ZFS can't manage past the LUN into the array. Guess what? ZFS can't get past the disk drive firmware eitherand thats a good thing for all parties involved. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: ZFS uses 1.1GB more space, reports conflicting information...
> Is this really how you set the sharenfs option? If It would certainly appear so. It took me a while to figure out the syntax though; the manpage is ambigous on that. It would be excellent if the manpage had more EXAMPLES. And if the EXAMPLES section was actually named that instead of "Examples" (to be consistent with other man pages, the unwritten convention and other system V UNIXes as well). > so, this will > default to exporting it read-write to everyone, even > though the "rw" > does not show up in the share command output. Yes, I am aware of that; but this was almost a one-time shot, where only I have access to both systems which are in the inner sanctum, so it mattered but little. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: ZFS causes panic on import
Stuart, Given that the pool was imported on both nodes simultaneously may have corrupted it beyond repair. I'm assuming that the "same problem" is a system panic? If so, can you send the panic string from that node? Thanks, George Stuart Low wrote: I thought that might work too but having tried the move of zpool.cache alas same problem. :( Stuart This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: ZFS causes panic on import
Stuart, Can you send the output of 'zpool status -v' from both nodes? Thanks, George Stuart Low wrote: Nada. [EMAIL PROTECTED] ~]$ zpool export -f ax150s cannot open 'ax150s': no such pool [EMAIL PROTECTED] ~]$ I wonder if it's possible to force the pool to be marked as inactive? Ideally all I want to do is get it back online then scrub it for errors. :-| Stuart This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS causes panic on import
Stuart, Is it possible that you ran 'zpool import' on node1 and then failed it over to the other node which ran 'zpool import' on node2? If so, then the pool configuration was automatically added to zpool.cache so that the pool could be automatically loaded upon reboot. This may result in the pool being imported on both node at the same time. What you need to do is run 'zpool import -R ' instead as this prevent the pool from being added to the cache. You should also ensure that the zpool.cache file does not exist on either node and that the import is driven by your failover scripts only. Thanks, George Stuart Low wrote: Hi there, We've been working with ZFS at an initial setup stage hoping to eventually integrate with Sun Cluster 3.2 and create a failover fs. Somehow between my two machines I managed to get the file system mounted on both. On reboot of both machines I can now no longer import my ZFS file systems. ZFS reports they're online (which they were, albeit before the reboot) but when I perform an import I'm told the pool "may be active". When trying a zpool import -f the machine kernel panics and instantly reboots. I'm at a loss as to how to mount this file system properly again. Please help! :-| [EMAIL PROTECTED] ~]$ zpool import pool: ax150s id: 1586873787799685 state: ONLINE action: The pool can be imported using its name or numeric identifier. The pool may be active on on another system, but can be imported using the '-f' flag. config: ax150s ONLINE mirror ONLINE c4t6006016071851800B86C8EE05831DB11d0 ONLINE c4t6006016031E0180032F8E9868E30DB11d0 ONLINE mirror ONLINE c4t6006016071851800CA1D94EF5831DB11d0 ONLINE c4t6006016031E0180026057F9B8E30DB11d0 ONLINE mirror ONLINE c4t6006016031E018003810E7AC8E30DB11d0 ONLINE c4t60060160718518009A7926FF5831DB11d0 ONLINE mirror ONLINE c4t6006016031E01800AC7E34918E30DB11d0 ONLINE c4t600601607185180010A65FE75831DB11d0 ONLINE mirror ONLINE c4t6006016031E018005A9B74A48E30DB11d0 ONLINE c4t600601607185180064063BF85831DB11d0 ONLINE [EMAIL PROTECTED] ~]$ zpool import ax150s cannot import 'ax150s': pool may be in use from other system use '-f' to import anyway [EMAIL PROTECTED] ~]$ zpool import -f ax150s Read from remote host solaris1: Connection reset by peer Connection to solaris1 closed. [EMAIL PROTECTED] ~]$ Any pointers muchly appreciated! :-| Stuart This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS uses 1.1GB more space, reports conflicting information...
On 9/4/06, UNIX admin <[EMAIL PROTECTED]> wrote:
[Solaris 10 6/06 i86pc]
I recently used a set of 6 disks in a MultiPack to create a RAIDZ volume. Then I
proceeded to do zfs set sharenfs=root=a.b.c.d:a.b.c.e space ("space" is how I
named the ZFS pool).
Is this really how you set the sharenfs option? If so, this will
default to exporting it read-write to everyone, even though the "rw"
does not show up in the share command output.
To get the behavior you probably want, you should use
zfs set sharenfs=root=a.b.c.d:a.b.c.e,rw=a.b.c.d:a.b.c.e space
instead. You must also specify a "ro=" or "rw=", as the "root="
option is only used for mapping. With the "root=access_list" syntax
and the wording of the share_nfs manual page this is easily confused.
I have reported these issues to the nfs-discuss@ list, and they will
be filed as bugs.
Chris
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: ZFS Web administration interface
> My question is not related directly to ZFS but maybe > you know the answer. > Currently I can run the ZFS Web administration > interface only locally - by pointing my browser to > [i]https://localhost:6789/zfs/[/i] > What should be done to enable an access to > [i]https://zfshost:6789/zfs/[/i] for other hosts ? > > TIA, > -- Leon This command did the job: [b]netservices open[/b] (see Secure-by-Default info for explanation http://www.opensolaris.org/os/community/security/projects/sbd/ ) Thanks to Detlef for his help. -- leon This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Recommendation ZFS on StorEdge 3320 - offtopic
On Mon, Sep 04, 2006 at 01:59:53AM -0700, UNIX admin wrote: > > My question is how efficient will ZFS be, given that > > it will be layered on top of the hardware RAID and > > write cache? > > ZFS delivers best performance when used standalone, directly on entire disks. > By using ZFS on top of a HW RAID, you make your data susceptible to HW errors > caused by the storage subsystem's RAID algorithm, and slow down the I/O. > > You should see much better performance by not creating a HW RAID, then adding > all the disks in the 3320' enclosures to a ZFS RAIDZ pool. This is the case where I don't understand Sun's politics at all: Sun doesn't offer really cheap JBOD which can be bought just for ZFS. And don't even tell me about 3310/3320 JBODs - they are horrible expansive :-( If Sun wants ZFS to be absorbed quicker it should have such _really_ cheap JBOD. przemol ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs panic: assertion failed: zp_error != 0 && dzp_error != 0
I made some powernow experiments on a dual core amd64 box, running the 64-bit debug on-20060828 kernel. At some point the kernel seemed to make no more progress (probably a bug in the multiprocessor powernow code), the gui was stuck, so I typed (blind) F1-A + $ ::status debugging crash dump vmcore.12 (32-bit) from moritz operating system: 5.11 wos_b48_2_debug (i86pc) panic message: assertion failed: zp_error != 0 && dzp_error != 0, file: ../../common/fs/zfs/zfs_acl.c, line: 1537 dump content: kernel pages only > ::stack vpanic(fea6bfa4, f85a5984, f85a5964, 601) assfail+0x5a(f85a5984, f85a5964, 601) zfs_zaccess_delete+0x13a(ca45a790, ca45a670, cd1f1e78) zfs_remove+0x88(ca453340, caa5b028, cd1f1e78) fop_remove+0x1e(ca453340, caa5b028, cd1f1e78) zfs_replay_remove+0x57(c94172c0, caa5b000, 0) zil_replay_log_record+0x256(c9da24c0, ca9e2708, ca6ded54, 70cf, 0) zil_parse+0x374(c9da24c0, 0, f8568188, ca6ded54, 70cf, 0) zil_replay+0xba(ca454f88, c94172c0, c94172e4, c50b2c6c, f8572ba0) zfs_domount+0x24a(c58cbf00, c79e89c0, cd1f1588) zfs_mount+0x109(c58cbf00, ca6e4c00, ca6def84, cd1f1588) fsop_mount+0x1a(c58cbf00, ca6e4c00, ca6def84, cd1f1588) domount+0x8ad(0, ca6def84, ca6e4c00, cd1f1588, ca6def48) mount+0x6f(ca6def84, ca6def68) syscall_ap+0x4d() sys_sysenter+0x1a2() Now I see that exactly the same panic with identical stack backtrace has already filed as bug 6466374, http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6466374 But why is bug 6466374 closed as a duplicate of bug 6413510? I'd say that bugs 6466374 and 6413510 are about completely different issues... When looking at the code in zfs_zaccess_delete() and zfs_zaccess_common(), it seems that when replaying a "remove" from the log, a debug version of the zfs filesystem module always panics with the "zp_error != 0 && dzp_error != 0" failed assertion. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Recommendation ZFS on StorEdge 3320
> My question is how efficient will ZFS be, given that > it will be layered on top of the hardware RAID and > write cache? ZFS delivers best performance when used standalone, directly on entire disks. By using ZFS on top of a HW RAID, you make your data susceptible to HW errors caused by the storage subsystem's RAID algorithm, and slow down the I/O. You should see much better performance by not creating a HW RAID, then adding all the disks in the 3320' enclosures to a ZFS RAIDZ pool. Additionally, given enough disks, it might be possible to squeeze even better performance by creating several RAIDZ vdevs and striping them. For a discussion on this aspect, please see "WHEN TO (AND NOT TO) USE RAID-Z" treatise at http://blogs.sun.com/roch/entry/when_to_and_not_to. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: ZFS causes panic on import
Ok. Can you post the panic stack backtrace? Perhaps it's a known problem... Stuart Low wrote: Heya, SC3.1 until we can get our hands on SC3.2 beta. Realistically the Cluster itself is operating independent of the ZFS pools (we do manual failover). Stu This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Zoram Thanga, Sun Cluster Development. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: ZFS causes panic on import
Heya, SC3.1 until we can get our hands on SC3.2 beta. Realistically the Cluster itself is operating independent of the ZFS pools (we do manual failover). Stu This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS causes panic on import
Hi Stuart, Stuart Low wrote: Hi there, We've been working with ZFS at an initial setup stage hoping to eventually integrate with Sun Cluster 3.2 and create a failover fs. Somehow between my two machines I managed to get the file system mounted on both. On reboot of both machines I can now no longer import my ZFS file systems. ZFS reports they're online (which they were, albeit before the reboot) but when I perform an import I'm told the pool "may be active". Just curious: Are you seeing this problem with SC3.2, or just plain Solaris? Thanks, Zoram -- Zoram Thanga, Sun Cluster Development. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
