Re: [zfs-discuss] ZFS ARC DNLC Limitation
Hi Jason, This should have helped.
6542676 ARC needs to track meta-data memory overhead
Some of the lines to arc.c:
1551 1.36 if (arc_meta_used = arc_meta_limit) {
1552/*
1553 * We are exceeding our meta-data cache limit.
1554 * Purge some DNLC entries to release holds on
meta-data.
1555 */
1556dnlc_reduce_cache((void
*)(uintptr_t)arc_reduce_dnlc_percent);
1557}
-r
Jason J. W. Williams writes:
Hello All,
Awhile back (Feb '07) when we noticed ZFS was hogging all the memory
on the system, y'all were kind enough to help us use the arc_max
tunable to attempt to limit that usage to a hard value. Unfortunately,
at the time a sticky problem was that the hard limit did not include
DNLC entries generated by ZFS.
I've been watching the list since then and trying to watch the Nevada
commits. I haven't noticed that anything has been committed back so
that arc_max truly enforces the max amount of memory ZFS is allowed to
consume (including DNLC entries). Has this been corrected and I just
missed it? Thank you in advance for you any help.
Best Regards,
Jason
___
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 speed degraded in S10U4 ?
On 9/25/07 3:37 AM, Sergiy Kolodka [EMAIL PROTECTED] wrote: Hi Guys, I'm playing with Blade 6300 to check performance of compressed ZFS with Oracle database. After some really simple tests I noticed that default (well, not really default, some patches applied, but definitely noone bother to tweak disk subsystem or something else) installation of S10U3 is actually faster than S10U4, and a lot faster. Actually it's even faster on compressed ZFS with S10U3 than on uncompressed with S10U4. My configuration - default Update 3 LiveUpgraded to Update 4 with ZFS filesystem on dedicated disk, and I'm working with same files which are on same physical cylinders, so it's not likely a problem with HDD itself. Did you do a 'zpool upgrade -a'? I'm doing as simple as just $time dd if=file.dbf of=/dev/null in few parallel tasks. On Update3 it's somewhere close to 11m32s and on Update 4 it's around 12m6s. And it's both reading from compressed or uncompressed ZFS, numbers a little bit higher with compressed, couple of seconds more, which impressive by itself, but difference is the same, and strangest part is that reading file from compressed ZFS on U3 is faster than reading uncompressed with U4. I'm really surprised by this results, anyone else noticed that ? I'm running a 'motley group of disks' on an e450 acting as our jumpstart server and server build times are noticeably quicker since u4. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -Andy -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] enterprise scale redundant Solaris 10/ZFS server providing NFSv4/CIFS
Paul B. Henson wrote: But all quotas were set in a single flat text file. Anytime you added a new quota, you needed to turn off quotas, then turn them back on, and quota enforcement was disabled while it recalculated space utilization. I believe in later versions of the OS 'quota resize' did this without the massive recalculation. Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS array NVRAM cache?
Where is ZFS with regards to the NVRAM cache present on arrays? I have a pile of 3310 with 512 megs cache, and even some 3510FC with 1-gig cache. It seems silly that it's going to waste. These are dual-controller units so I have no worry about loss of cache information. It looks like OpenSolaris has a way to force arguably correct behavior, but Solaris 10u3/4 do not. I see some threads from early this year about it, and nothing since. 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 array NVRAM cache?
On Tue, Sep 25, 2007 at 10:14:57AM -0700, Vincent Fox wrote: Where is ZFS with regards to the NVRAM cache present on arrays? I have a pile of 3310 with 512 megs cache, and even some 3510FC with 1-gig cache. It seems silly that it's going to waste. These are dual-controller units so I have no worry about loss of cache information. It looks like OpenSolaris has a way to force arguably correct behavior, but Solaris 10u3/4 do not. I see some threads from early this year about it, and nothing since. Made some simple tests wrt. cont. seq. writes/reads for a 3510 (singl. controller), single Host (v490) with 2 FC-HBAs - so, yes - I'm running now ZFS single disk over HW Raid10 (10disks) ... Haven't had the time, to test all combinations or mixed load cases, however, in case you wanna check, what I got: http://iws.cs.uni-magdeburg.de/~elkner/3510.txt Have fun, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS array NVRAM cache?
On Tue, 2007-09-25 at 10:14 -0700, Vincent Fox wrote: Where is ZFS with regards to the NVRAM cache present on arrays? I have a pile of 3310 with 512 megs cache, and even some 3510FC with 1-gig cache. It seems silly that it's going to waste. These are dual-controller units so I have no worry about loss of cache information. I've done a few experiments with using small LUNs from a surplus 3510 raid unit for a separate intent log while putting the main body of the pool in directly connected 3510 JBOD arrays. Seems to work well; writes to the intent log device show a much lower asvc_t (average service time) value in iostat than writes to the main pool disks, and NFS performance in a few completely unscientific and uncontrolled tests that are vaguely representative of our workload seems to be better. The behavior I'm seeing is consistent with the 3510 raid controller ignoring the synchronize cache command. I haven't put this into production just yet. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] enterprise scale redundant Solaris 10/ZFS server providing NFSv4/CIFS
On 9/24/07, Paul B. Henson [EMAIL PROTECTED] wrote: On Sat, 22 Sep 2007, Peter Tribble wrote: filesystem per user on the server, just to see how it would work. While managing 20,00 filesystems with the automounter was trivial, the attempt to manage 20,000 zfs filesystems wasn't entirely successful. In fact, based on that experience I simply wouldn't go down the road of one user per filesystem. Really? Could you provide further detail about what problems you experienced? Our current filesystem based on DFS effectively utilizes a separate filesystem per user (although in DFS terminology they are called filesets), and we've never had a problem managing them. This was some time ago (a very long time ago, actually). There are two fundamental problems: 1. Each zfs filesystem consumes kernel memory. Significant amounts, 64K is what we worked out at the time. For normal numbers of filesystems that's not a problem; multiply it by tens of thousands and you start to hit serious resource usage. 2. The zfs utilities didn't scale well as the number of filesystems increased. I just kept on issuing zfs create until the machine had had enough. It got through the first 10,000 without too much difficulty (as I recall that took several hours), but soon got bogged down after that, to the point where it took a day to do anything. At which point (at about 15000 filesystems on a 1G system) it ran out of kernel memory and died. At this point it wouldn't even boot. I know that some work has gone into improving the performance of the utilities, and things like in-kernel sharetab (we never even tried to share all those filesystems) are there to improve scalability. Perhaps I should find a spare machine and try repeating the experiment. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] device alias
Hi. I'd like to request a feature be added to zfs. Currently, on SAN attached disk, zpool shows up with a big WWN for the disk. If ZFS (or the zpool command, in particular) had a text field for arbitrary information, it would be possible to add something that would indicate what LUN on what array the disk in question might be. This would make troubleshooting and general understanding of the actual storage layout much simpler, as you'd know something about any disks that are encountering problems. Something like: zpool status pool: local state: ONLINE scrub: scrub completed with 0 errors on Sun Sep 23 04:16:33 2007 config: NAMESTATE READ WRITE CKSUM NOTE local ONLINE 0 0 0 raidz1ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 Internal SATA on left side c2t2d0 ONLINE 0 0 0 Internal SATA on right side c2t3d0 ONLINE 0 0 0 External SATA disk 1 in box on top c2t4d0 ONLINE 0 0 0 External SATA disk 2 in box on top spares c2t5d0AVAIL External SATA disk 3 in box on top errors: No known data errors The above would be very useful should a disk fail to identify what device is what. Thanks! - Gregory Shaw, IT Architect IT CTO Group, Sun Microsystems Inc. Phone: (303)-272-8817 (x78817) 500 Eldorado Blvd, UBRM02-157 [EMAIL PROTECTED] (work) Broomfield, CO 80021 [EMAIL PROTECTED] (home) When Microsoft writes an application for Linux, I've won. - Linus Torvalds ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
Gregory Shaw wrote: Hi. I'd like to request a feature be added to zfs. Currently, on SAN attached disk, zpool shows up with a big WWN for the disk. If ZFS (or the zpool command, in particular) had a text field for arbitrary information, it would be possible to add something that would indicate what LUN on what array the disk in question might be. This would make troubleshooting and general understanding of the actual storage layout much simpler, as you'd know something about any disks that are encountering problems. Something like: zpool status pool: local state: ONLINE scrub: scrub completed with 0 errors on Sun Sep 23 04:16:33 2007 config: NAMESTATE READ WRITE CKSUM NOTE local ONLINE 0 0 0 raidz1ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 Internal SATA on left side c2t2d0 ONLINE 0 0 0 Internal SATA on right side c2t3d0 ONLINE 0 0 0 External SATA disk 1 in box on top c2t4d0 ONLINE 0 0 0 External SATA disk 2 in box on top spares c2t5d0AVAIL External SATA disk 3 in box on top errors: No known data errors The above would be very useful should a disk fail to identify what device is what. How would you gather that information? How would you ensure that it stayed accurate in a hotplug world? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
James C. McPherson wrote: Gregory Shaw wrote: Hi. I'd like to request a feature be added to zfs. Currently, on SAN attached disk, zpool shows up with a big WWN for the disk. If ZFS (or the zpool command, in particular) had a text field for arbitrary information, it would be possible to add something that would indicate what LUN on what array the disk in question might be. This would make troubleshooting and general understanding of the actual storage layout much simpler, as you'd know something about any disks that are encountering problems. Something like: zpool status pool: local state: ONLINE scrub: scrub completed with 0 errors on Sun Sep 23 04:16:33 2007 config: NAMESTATE READ WRITE CKSUM NOTE local ONLINE 0 0 0 raidz1ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 Internal SATA on left side c2t2d0 ONLINE 0 0 0 Internal SATA on right side c2t3d0 ONLINE 0 0 0 External SATA disk 1 in box on top c2t4d0 ONLINE 0 0 0 External SATA disk 2 in box on top spares c2t5d0AVAIL External SATA disk 3 in box on top errors: No known data errors The above would be very useful should a disk fail to identify what device is what. How would you gather that information? How would you ensure that it stayed accurate in a hotplug world? If it is stored on the device itself it would keep the description with the same device. In the case of iSCSI, it would be nice to keep lun info instead of having to correlate the drive id to the iqn to the lun, especially when working with luns in one place and drive ids in another. -Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
Tim Spriggs wrote: James C. McPherson wrote: Gregory Shaw wrote: ... The above would be very useful should a disk fail to identify what device is what. How would you gather that information? How would you ensure that it stayed accurate in a hotplug world? If it is stored on the device itself it would keep the description with the same device. What about when you replace a disk in an array? What process would go and write the appropriate information? How about a bootstrap for this? What would accomplish it? What if you moved your entire system and re-cabled your arrays slightly different? We have the beauty of devids to make sure that the pools still work, but the physical information Greg is talking about would almost certainly be incorrect. In the case of iSCSI, it would be nice to keep lun info instead of having to correlate the drive id to the iqn to the lun, especially when working with luns in one place and drive ids in another. When I was playing around with iscsi a few months back, I used 1gb files on zfs which I then exported because I could. What sort of lun info do you want in that sort of use case? Position would be quite useless in some respects. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] enterprise scale redundant Solaris 10/ZFS server providing NFSv4/CIFS
On Mon, 24 Sep 2007, Dale Ghent wrote: Not to sway you away from ZFS/NFS considerations, but I'd like to add that people who in the past used DFS typically went on to replace it with AFS. Have you considered it? You're right, AFS is the first choice coming to mind when replacing DFS. We actually implemented an OpenAFS prototype last year and have been running it for internal use only since then. Unfortunately, like almost everything we've looked at, AFS is a step backwards from DFS. As the precursor to DFS, AFS has enough similarities to DFS to make the features it lacks almost more painful. No per file access control lists is a serious bummer. Integration with Kerberos 5 rather than the internal kaserver is still at a bit of a duct tape level, and only support DES. Having to maintain an additional repository of user/group information (pts) is a bit of a pain, while there are long-term goals to replace that with some type of LDAP integration I don't see that anytime soon. One of the most annoying things is that AFS requires integration at the kernel level, yet is not maintained by the same people that maintain the kernel. Frequently a Linux kernel upgrade will break AFS, and the developers need to scramble to release a patch or update to resolve it. While we are not currently using AFS under Solaris, based on mailing list traffic similar issues arise. One of the benefits of NFSv4 is that it is a core part of the operating system, unlikely to be lightly broken during updates. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
On Wed, 2007-09-26 at 08:26 +1000, James C. McPherson wrote: How would you gather that information? the tools to use would be dependant on the actual storage device in use. luxadm for A5x00 and V8x0 internal storage, sccli for 3xxx, etc., etc., How would you ensure that it stayed accurate in a hotplug world? See above. I'm told that with many jbod arrays, SES has the information. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] enterprise scale redundant Solaris 10/ZFS server providing NFSv4/CIFS
On Tue, 25 Sep 2007, Peter Tribble wrote: This was some time ago (a very long time ago, actually). There are two fundamental problems: 1. Each zfs filesystem consumes kernel memory. Significant amounts, 64K is what we worked out at the time. For normal numbers of filesystems that's not a problem; multiply it by tens of thousands and you start to hit serious resource usage. Every server we've bought for about the last year came with 4 GB of memory, the servers we would deploy for this would have at least 8 if not 16GB. Given the downtrend in memory prices, hopefully memory would not be an issue. 2. The zfs utilities didn't scale well as the number of filesystems increased. [...] share all those filesystems) are there to improve scalability. Perhaps I should find a spare machine and try repeating the experiment. There have supposedly been lots of improvements in scalability, based on my review of mailing list archives. If you do find the time to experiment again, I'd appreciate hearing what you find... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] io:::start and zfs filenames?
io:::start probe does not seem to get zfs filenames in args[2]-fi_pathname. Any ideas how to get this info? -neel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
Bill Sommerfeld wrote: On Wed, 2007-09-26 at 08:26 +1000, James C. McPherson wrote: How would you gather that information? the tools to use would be dependant on the actual storage device in use. luxadm for A5x00 and V8x0 internal storage, sccli for 3xxx, etc., etc., No consistent interface to use, then, unless another tool or cruft gets added to ZFS to make this happen. That would seem to defeat one of the major wins of ZFS - storage neutrality. How would you ensure that it stayed accurate in a hotplug world? See above. I'm told that with many jbod arrays, SES has the information. True, but that's still many, but not all. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
It would be a manual process. As with any arbitrary name, it's a useful tag, not much more. James C. McPherson wrote: Gregory Shaw wrote: Hi. I'd like to request a feature be added to zfs. Currently, on SAN attached disk, zpool shows up with a big WWN for the disk. If ZFS (or the zpool command, in particular) had a text field for arbitrary information, it would be possible to add something that would indicate what LUN on what array the disk in question might be. This would make troubleshooting and general understanding of the actual storage layout much simpler, as you'd know something about any disks that are encountering problems. Something like: zpool status pool: local state: ONLINE scrub: scrub completed with 0 errors on Sun Sep 23 04:16:33 2007 config: NAMESTATE READ WRITE CKSUM NOTE local ONLINE 0 0 0 raidz1ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 Internal SATA on left side c2t2d0 ONLINE 0 0 0 Internal SATA on right side c2t3d0 ONLINE 0 0 0 External SATA disk 1 in box on top c2t4d0 ONLINE 0 0 0 External SATA disk 2 in box on top spares c2t5d0AVAIL External SATA disk 3 in box on top errors: No known data errors The above would be very useful should a disk fail to identify what device is what. How would you gather that information? How would you ensure that it stayed accurate in a hotplug world? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ 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] device alias
James C. McPherson wrote: Bill Sommerfeld wrote: On Wed, 2007-09-26 at 08:26 +1000, James C. McPherson wrote: How would you gather that information? the tools to use would be dependant on the actual storage device in use. luxadm for A5x00 and V8x0 internal storage, sccli for 3xxx, etc., etc., No consistent interface to use, then, unless another tool or cruft gets added to ZFS to make this happen. That would seem to defeat one of the major wins of ZFS - storage neutrality. I'd be happy with an arbitrary field that could be assigned via a command. Intelligence could be added later if appropriate, but at this point, figuring out what-is-where on a big list of disk IDs on a SAN device is very difficult. So, aiming low, a text field that could be assigned. In the future, perhaps something that would associate a serial number of something similar to that name? How would you ensure that it stayed accurate in a hotplug world? See above. I'm told that with many jbod arrays, SES has the information. True, but that's still many, but not all. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ 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] device alias
Greg Shaw wrote: James C. McPherson wrote: Bill Sommerfeld wrote: On Wed, 2007-09-26 at 08:26 +1000, James C. McPherson wrote: How would you gather that information? the tools to use would be dependant on the actual storage device in use. luxadm for A5x00 and V8x0 internal storage, sccli for 3xxx, etc., etc., No consistent interface to use, then, unless another tool or cruft gets added to ZFS to make this happen. That would seem to defeat one of the major wins of ZFS - storage neutrality. I'd be happy with an arbitrary field that could be assigned via a command. Intelligence could be added later if appropriate, but at this point, figuring out what-is-where on a big list of disk IDs on a SAN device is very difficult. So, aiming low, a text field that could be assigned. In the future, perhaps something that would associate a serial number of something similar to that name? That sounds like an ok RFE to me. For some of the arrays (eg HDS) that we come into contact with, it's possible to decode the device guid into something meaningful to a human, but that's generally closed information. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
Dale Ghent wrote: On Sep 25, 2007, at 7:48 PM, Richard Elling wrote: The problem with this is that wrong information is much worse than no information, there is no way to automatically validate the information, and therefore people are involved. If people were reliable, then even a text file would work. If it can't be automatic and reliable, then it isn't worth doing. I dunno if I think we have to think this far into it. Consider the Clearview project and their implementation of vanity names for network interfaces. Conceivably, such a feature is useful to admins as they can set the name to be a particular vlan number, or the switch/blade/port where the other end of the ethernet line is terminated. Or their ex-girlfriend's name if it's a particular troublesome interface. The point is, it allows arbitrary naming of something so that the admin(s) can associate with it better as an object. Most importantly, there's a distinction here. Solaris provides the facility. It's up to the admin to maintain it. That's as far as it should go. Actually, you can use the existing name space for this. By default, ZFS uses /dev/dsk. But everything in /dev is a symlink. So you could setup your own space, say /dev/myknowndisks and use more descriptive names. You might need to hack on the startup service to not look at /dev, but that shouldn't be too hard. In other words, if the answer is let the sysadmin do it then it can be considered solved. The stretch goal is to make some sort of reasonable name service. At this point I'll note the the FC folks envisioned something like that, but never implemented it. # ramdiskadm -a BrownDiskWithWhiteHat 150m /dev/ramdisk/BrownDiskWithWhiteDot # zpool create zwimming /dev/ramdisk/BrownDiskWithWhiteDot # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zwimming ONLINE 0 0 0 /dev/ramdisk/BrownDiskWithWhiteDot ONLINE 0 0 0 errors: No known data errors # ls -l /dev/ramdisk/BrownDiskWithWhiteHat lrwxrwxrwx 1 root root 55 Sep 25 17:59 /dev/ramdisk/BrownDiskWithWhiteDot - ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteDot # zpool export zwimming # mkdir /dev/whee # cd /dev/whee # ln -s ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteHat YellowDiskUnderPinkBox # zpool import -d /dev/whee zwimming # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM zwimmingONLINE 0 0 0 /dev/whee/YellowDiskUnderPinkBox ONLINE 0 0 0 errors: No known data errors -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
On Sep 25, 2007, at 7:09 PM, Richard Elling wrote: Dale Ghent wrote: On Sep 25, 2007, at 7:48 PM, Richard Elling wrote: The problem with this is that wrong information is much worse than no information, there is no way to automatically validate the information, and therefore people are involved. If people were reliable, then even a text file would work. If it can't be automatic and reliable, then it isn't worth doing. I dunno if I think we have to think this far into it. Consider the Clearview project and their implementation of vanity names for network interfaces. Conceivably, such a feature is useful to admins as they can set the name to be a particular vlan number, or the switch/blade/port where the other end of the ethernet line is terminated. Or their ex-girlfriend's name if it's a particular troublesome interface. The point is, it allows arbitrary naming of something so that the admin(s) can associate with it better as an object. Most importantly, there's a distinction here. Solaris provides the facility. It's up to the admin to maintain it. That's as far as it should go. Actually, you can use the existing name space for this. By default, ZFS uses /dev/dsk. But everything in /dev is a symlink. So you could setup your own space, say /dev/myknowndisks and use more descriptive names. You might need to hack on the startup service to not look at /dev, but that shouldn't be too hard. In other words, if the answer is let the sysadmin do it then it can be considered solved. The stretch goal is to make some sort of reasonable name service. At this point I'll note the the FC folks envisioned something like that, but never implemented it. # ramdiskadm -a BrownDiskWithWhiteHat 150m /dev/ramdisk/ BrownDiskWithWhiteDot # zpool create zwimming /dev/ramdisk/BrownDiskWithWhiteDot # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zwimming ONLINE 0 0 0 /dev/ramdisk/BrownDiskWithWhiteDot ONLINE 0 0 0 errors: No known data errors # ls -l /dev/ramdisk/BrownDiskWithWhiteHat lrwxrwxrwx 1 root root 55 Sep 25 17:59 /dev/ramdisk/ BrownDiskWithWhiteDot - ../../devices/pseudo/ [EMAIL PROTECTED]:BrownDiskWithWhiteDot # zpool export zwimming # mkdir /dev/whee # cd /dev/whee # ln -s ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteHat YellowDiskUnderPinkBox # zpool import -d /dev/whee zwimming # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM zwimmingONLINE 0 0 0 /dev/whee/YellowDiskUnderPinkBox ONLINE 0 0 0 errors: No known data errors -- richard But nobody would actually do this. If the process can't be condensed into a single step (e.g. a single command), people won't bother. Besides, who would take the chance that a 'boot -r' would keep their elaborate symbolic link tree intact? I wouldn't. I've learned that you can't count on anything in /dev remaining over 'boot -r', patches, driver updates, san events, etc. - Gregory Shaw, IT Architect IT CTO Group, Sun Microsystems Inc. Phone: (303)-272-8817 (x78817) 500 Eldorado Blvd, UBRM02-157 [EMAIL PROTECTED] (work) Broomfield, CO 80021 [EMAIL PROTECTED] (home) When Microsoft writes an application for Linux, I've won. - Linus Torvalds ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
On 9/25/07, Gregory Shaw [EMAIL PROTECTED] wrote: On Sep 25, 2007, at 7:09 PM, Richard Elling wrote: Dale Ghent wrote: On Sep 25, 2007, at 7:48 PM, Richard Elling wrote: The problem with this is that wrong information is much worse than no information, there is no way to automatically validate the information, and therefore people are involved. If people were reliable, then even a text file would work. If it can't be automatic and reliable, then it isn't worth doing. I dunno if I think we have to think this far into it. Consider the Clearview project and their implementation of vanity names for network interfaces. Conceivably, such a feature is useful to admins as they can set the name to be a particular vlan number, or the switch/blade/port where the other end of the ethernet line is terminated. Or their ex-girlfriend's name if it's a particular troublesome interface. The point is, it allows arbitrary naming of something so that the admin(s) can associate with it better as an object. Most importantly, there's a distinction here. Solaris provides the facility. It's up to the admin to maintain it. That's as far as it should go. Actually, you can use the existing name space for this. By default, ZFS uses /dev/dsk. But everything in /dev is a symlink. So you could setup your own space, say /dev/myknowndisks and use more descriptive names. You might need to hack on the startup service to not look at /dev, but that shouldn't be too hard. In other words, if the answer is let the sysadmin do it then it can be considered solved. The stretch goal is to make some sort of reasonable name service. At this point I'll note the the FC folks envisioned something like that, but never implemented it. # ramdiskadm -a BrownDiskWithWhiteHat 150m /dev/ramdisk/BrownDiskWithWhiteDot # zpool create zwimming /dev/ramdisk/BrownDiskWithWhiteDot # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zwimming ONLINE 0 0 0 /dev/ramdisk/BrownDiskWithWhiteDot ONLINE 0 0 0 errors: No known data errors # ls -l /dev/ramdisk/BrownDiskWithWhiteHat lrwxrwxrwx 1 root root 55 Sep 25 17:59 /dev/ramdisk/BrownDiskWithWhiteDot - ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteDot # zpool export zwimming # mkdir /dev/whee # cd /dev/whee # ln -s ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteHat YellowDiskUnderPinkBox # zpool import -d /dev/whee zwimming # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM zwimmingONLINE 0 0 0 /dev/whee/YellowDiskUnderPinkBox ONLINE 0 0 0 errors: No known data errors -- richard But nobody would actually do this. If the process can't be condensed into a single step (e.g. a single command), people won't bother. Besides, who would take the chance that a 'boot -r' would keep their elaborate symbolic link tree intact? I wouldn't. I've learned that you can't count on anything in /dev remaining over 'boot -r', patches, driver updates, san events, etc. - Gregory Shaw, IT Architect IT CTO Group, Sun Microsystems Inc. Phone: (303)-272-8817 (x78817) 500 Eldorado Blvd, UBRM02-157 [EMAIL PROTECTED] (work) Broomfield, CO 80021 [EMAIL PROTECTED] (home) When Microsoft writes an application for Linux, I've won. - Linus Torvalds ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss I've actually contemplated requesting such a feature for /dev (creating vanity aliases that are presistant) as it would also be useful for things like databases that use raw disk (i.e. Oracle ASM). ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS array NVRAM cache?
On Tue, Sep 25, 2007 at 06:01:00PM -0700, Vincent Fox wrote: I don't understand. How do you setup one LUN that has all of the NVRAM on the array dedicated to it I'm pretty familiar with 3510 and 3310. Forgive me for being a bit thick here, but can you be more specific for the n00b? If you're using CAM, disable NVRAM on all of your LUNs. Then, create another LUN equivalent to the size of your NVRAM. Assign the ZIL to this LUN. You'll then have an NVRAM-backed ZIL. I posted a question along these lines to storage-discuss: http://mail.opensolaris.org/pipermail/storage-discuss/2007-July/003080.html You'll need to determine the performance impact of removing NVRAM from your data LUNs. Don't blindly do it. -- albert chin ([EMAIL PROTECTED]) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] device alias
Please don't do this as a rule, it makes for horrendous support issues and breaks a lot of health check tools. Actually, you can use the existing name space for this. By default, ZFS uses /dev/dsk. But everything in /dev is a symlink. So you could setup your own space, say /dev/myknowndisks and use more descriptive names. You might need to hack on the startup service to not look at /dev, but that shouldn't be too hard. In other words, if the answer is let the sysadmin do it then it can be considered solved. The stretch goal is to make some sort of reasonable name service. At this point I'll note the the FC folks envisioned something like that, but never implemented it. # ramdiskadm -a BrownDiskWithWhiteHat 150m /dev/ramdisk/BrownDiskWithWhiteDot # zpool create zwimming /dev/ramdisk/BrownDiskWithWhiteDot # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zwimming ONLINE 0 0 0 /dev/ramdisk/BrownDiskWithWhiteDot ONLINE 0 0 0 errors: No known data errors # ls -l /dev/ramdisk/BrownDiskWithWhiteHat lrwxrwxrwx 1 root root 55 Sep 25 17:59 /dev/ramdisk/BrownDiskWithWhiteDot - ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteDot # zpool export zwimming # mkdir /dev/whee # cd /dev/whee # ln -s ../../devices/pseudo/[EMAIL PROTECTED]:BrownDiskWithWhiteHat YellowDiskUnderPinkBox # zpool import -d /dev/whee zwimming # zpool status zwimming pool: zwimming state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM zwimmingONLINE 0 0 0 /dev/whee/YellowDiskUnderPinkBox ONLINE 0 0 0 errors: No known data errors -- richard But nobody would actually do this. If the process can't be condensed into a single step (e.g. a single command), people won't bother. Besides, who would take the chance that a 'boot -r' would keep their elaborate symbolic link tree intact? I wouldn't. I've learned that you can't count on anything in /dev remaining over 'boot -r', patches, driver updates, san events, etc. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] RAID-Z in ZFS
Anybody can tell me about RAID-Z architecture , cuz i tried to understand it by seach in google but it doesn't clear. I don't know why it can beat raid-5. I know it can prove about RAID-5 Write Hole cuz it has copy-on-write feature for data intigrity. But i don't understand about write full stripe for RAID-Z cus raid-5 when it write , it must create parity for recover. Does anyone can clear it for me? Thank in advance Ko This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
