Re: [zfs-discuss] linux versus sol10
On 7 Nov 2006, at 21:02, Michael Schuster wrote: listman wrote: hi, i found a comment comparing linux and solaris but wasn't sure which version of solaris was being referred. can the list confirm that this issue isn't a problem with solaris10/zfs?? Linux also supports asynchronous directory updates which can make a significant performance improvement when branching. On Solaris machines, inode creation is very slow and can result in very long iowait states. I think this cannot be commented on in a useful fashion without more information this supposed issue. AFAIK, neither ufs nor zfs create inodes (at run time), so this is somewhat hard to put into context. get a complete description of what this is about, then maybe we can give you a useful answer. This could be related to Linux trading reliability for speed by doing async metadata updates. If your system crashes before your metadata is flushed to disk your filesystem might be hosed and a restore from backups may be needed. Paul ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] linux versus sol10
Hello Paul, Wednesday, November 8, 2006, 3:23:35 PM, you wrote: PvdZ On 7 Nov 2006, at 21:02, Michael Schuster wrote: listman wrote: hi, i found a comment comparing linux and solaris but wasn't sure which version of solaris was being referred. can the list confirm that this issue isn't a problem with solaris10/zfs?? Linux also supports asynchronous directory updates which can make a significant performance improvement when branching. On Solaris machines, inode creation is very slow and can result in very long iowait states. I think this cannot be commented on in a useful fashion without more information this supposed issue. AFAIK, neither ufs nor zfs create inodes (at run time), so this is somewhat hard to put into context. get a complete description of what this is about, then maybe we can give you a useful answer. PvdZ This could be related to Linux trading reliability for speed by doing PvdZ async metadata updates. PvdZ If your system crashes before your metadata is flushed to disk your PvdZ filesystem might be hosed and a restore PvdZ from backups may be needed. you can achieve something similar with fastfs on ufs file systems and setting zil_disable to 1 on ZFS. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: Re[2]: [zfs-discuss] linux versus sol10
On 8 Nov 2006, at 16:16, Robert Milkowski wrote: Hello Paul, Wednesday, November 8, 2006, 3:23:35 PM, you wrote: PvdZ On 7 Nov 2006, at 21:02, Michael Schuster wrote: listman wrote: hi, i found a comment comparing linux and solaris but wasn't sure which version of solaris was being referred. can the list confirm that this issue isn't a problem with solaris10/zfs?? Linux also supports asynchronous directory updates which can make a significant performance improvement when branching. On Solaris machines, inode creation is very slow and can result in very long iowait states. I think this cannot be commented on in a useful fashion without more information this supposed issue. AFAIK, neither ufs nor zfs create inodes (at run time), so this is somewhat hard to put into context. get a complete description of what this is about, then maybe we can give you a useful answer. PvdZ This could be related to Linux trading reliability for speed by doing PvdZ async metadata updates. PvdZ If your system crashes before your metadata is flushed to disk your PvdZ filesystem might be hosed and a restore PvdZ from backups may be needed. you can achieve something similar with fastfs on ufs file systems and setting zil_disable to 1 on ZFS. Sure UFS and ZFS can be faster, but having fast, but possibly dangerous, defaults gives you nice benchmark figures ;-) In real life I prefer the safe, but a bit slower, defaults, as should anybody who values his data. Paul ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: Re[2]: [zfs-discuss] linux versus sol10
Paul van der Zwan [EMAIL PROTECTED] wrote: Sure UFS and ZFS can be faster, but having fast, but possibly dangerous, defaults gives you nice benchmark figures ;-) In real life I prefer the safe, but a bit slower, defaults, as should anybody who values his data. There is another point besides having dangerous defaults on Linux: People don't know what they benchmark. This is caused by the fact that people usually meter the time for a tar xf bla call, while a lot of the data is only inside the RAM when tar is finished and you would need to wait until the data is on disk. Solaris starts earlier with copying the RAM cache to disk than Linux does and Solaris usually gives you bettter I/O bandwidth than Linux. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] linux versus sol10
Robert Milkowski wrote On 11/08/06 08:16,: Hello Paul, Wednesday, November 8, 2006, 3:23:35 PM, you wrote: PvdZ On 7 Nov 2006, at 21:02, Michael Schuster wrote: listman wrote: hi, i found a comment comparing linux and solaris but wasn't sure which version of solaris was being referred. can the list confirm that this issue isn't a problem with solaris10/zfs?? Linux also supports asynchronous directory updates which can make a significant performance improvement when branching. On Solaris machines, inode creation is very slow and can result in very long iowait states. I think this cannot be commented on in a useful fashion without more information this supposed issue. AFAIK, neither ufs nor zfs create inodes (at run time), so this is somewhat hard to put into context. get a complete description of what this is about, then maybe we can give you a useful answer. PvdZ This could be related to Linux trading reliability for speed by doing PvdZ async metadata updates. PvdZ If your system crashes before your metadata is flushed to disk your PvdZ filesystem might be hosed and a restore PvdZ from backups may be needed. you can achieve something similar with fastfs on ufs file systems and setting zil_disable to 1 on ZFS. There's a difference for both of these. UFS now has logging (journalling) as the default, and so any crashes/power fails will keep the integrity of the metadata intact (ie no fsck/restore). ZFS has no problem either as its fully transacts both data and meta data and should never see corruption with intent log disabled or enabled. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] linux versus sol10
Robert Milkowski wrote: PvdZ This could be related to Linux trading reliability for speed by doing PvdZ async metadata updates. PvdZ If your system crashes before your metadata is flushed to disk your PvdZ filesystem might be hosed and a restore PvdZ from backups may be needed. you can achieve something similar with fastfs on ufs file systems and setting zil_disable to 1 on ZFS. No, zil_disable does not trade off consistency for performance the way 'fastfs' on ufs or async metadata updates on EXT do! Setting zil_disable causes ZFS to not push synchronous operations (eg, fsync(), O_DSYNC, NFS ops) to disk immediately, but it does not compromise filesystem integrity in any way. Unlike these other filesystems fast modes, ZFS (even with zil_disable=1) will not corrupt itself and send you to backup tapes. To state it another way, setting 'zil_disable=1' on ZFS will at worst cause some operations which requested synchronous semantics to not actually be on disk in the event of a crash, whereas other filesystems can corrupt themselves and lose all your data. All that said, 'zil_disable' is a completely unsupported hack, and subject to change at any time. It will probably eventually be replaced by 6280630 zil synchronicity. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] linux versus sol10
Hello Matthew, Wednesday, November 8, 2006, 5:31:28 PM, you wrote: MA Robert Milkowski wrote: PvdZ This could be related to Linux trading reliability for speed by doing PvdZ async metadata updates. PvdZ If your system crashes before your metadata is flushed to disk your PvdZ filesystem might be hosed and a restore PvdZ from backups may be needed. you can achieve something similar with fastfs on ufs file systems and setting zil_disable to 1 on ZFS. MA No, zil_disable does not trade off consistency for performance the way MA 'fastfs' on ufs or async metadata updates on EXT do! I know that. But from user perspective setting zil_disable can make many applications much faster. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Thoughts on patching + zfs root
Anxiously anticipating the ability to boot off zfs, I know there's been some talk about leveraging some of the snapshotting/cloning features in conjunction with upgrades and patches. What I am really hoping for is the ability to clone /, patch the clone, then boot off the clone (by doing a clone swap). This would minimize the downtime needed to patch (as compared to today) since the install could be done while the system is still up and running. I suspect to do this might require some interaction with things like patchadd, etc., so I am curious if such a feature is already in the works, or if perhaps an RFE should be filed. Assuming the plans are already there for this, I'd like to anticipate any gotchas with our standard install procedure, and was just wondering if any thought had been put in as to what the requirements would be. Just off the top of my head, I would guess it'd mostly revolve around making sure stuff is separated properly into different filesystems, but was curious if anyone else has thought about this. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] OpenSolaris vs. Solaris 10 11/06 (S10u3) for NFS ZFS Server
I'm in the process of building a Solaris NFS server with ZFS and was wondering if any gurus here have any comments as to choosing the upcoming Solairs 10 11/06 [presumably] or OpenSolaris bXX/Solairs Express for this use. Even with my use of OpenSolaris I maintain a service contract to show my support, so bug fixes in a static supported version shouldn't be an issue in picking a version. So, the short question is are there any super-cool must-have ZFS/NFS features in OpenSolaris now that S10u3 won't have right away? Thanks! 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] OpenSolaris vs. Solaris 10 11/06 (S10u3) for NFS ZFS Server
On Wed, 8 Nov 2006, Wes Williams wrote: [ reformatted ... ] I'm in the process of building a Solaris NFS server with ZFS and was wondering if any gurus here have any comments as to choosing the upcoming Solairs 10 11/06 [presumably] or OpenSolaris bXX/Solairs Express for this use. Even with my use of OpenSolaris I maintain a service contract to show my support, so bug fixes in a static supported version shouldn't be an issue in picking a version. So, the short question is are there any super-cool must-have ZFS/NFS features in OpenSolaris now that S10u3 won't have right away? [ Hi Wes from [EMAIL PROTECTED] ] And the smart-ask answer is: By Definition: the OpenSolaris/Solaris Express feature that is *your* must-have feature, probably won't be in Update 3! :) Since U3 is a cherry picked subset of OpenSolaris, it's difficult to predict which features made it and which did not. I know that it's a Sun decision made from a basis of (Sun) solid logic - it's just difficult to figure out this mental process, from the outside looking in. In my case, the ability to clone a zone from a zfs snapshot did'nt make it! :( I don't think that there are any ZFS NFS related fixes that did'nt make it into U3 (others will correct me if I'm wrong here). It's a tough choice to make... The huge upside is ... that there is a choice! :) Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: OpenSolaris vs. Solaris 10 11/06 (S10u3) for NFS
[ Hi Wes from [EMAIL PROTECTED] ] And the smart-ask answer is: By Definition: the OpenSolaris/Solaris Express feature that is *your* must-have feature, probably won't be in Update 3! :) Exactly, that's why I used quotes as I'm sure I'd be happy with S10u3, assuming ignorance is bliss. Then again, I've never believed ignorance is bliss. ;) I simply don't know enough about the difference between the two OS versions yet to make an educated guess as to which venue to pursue presently - especially since S10u3 isn't released at the moment and I haven't followed ZFS closely since ZFSv1 was current. snip I don't think that there are any ZFS NFS related fixes that did'nt make it into U3 (others will correct me if I'm wrong here). It's a tough choice o make... The huge upside is ... that there is a choice! :) Indeed, knowing there are no known NFS fixes omitted is great news, not that I was aware of anything in NFS needing fixing. To me this is just reassuring since my goal is to build this box and nearly forget about it while it's hidden away and 'it just works.' Since I didn't hear anything like ZFSv3 vs. ZFSv2 or some such, I'll probably just go w/ S10u3 for this project. Thanks for your feedback Al. 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] OpenSolaris vs. Solaris 10 11/06 (S10u3) for NFS ZFS Server
On 11/8/06, Al Hopper [EMAIL PROTECTED] wrote: In my case, the ability to clone a zone from a zfs snapshot did'nt make it! :( Yeah, but if you read the man page in the U3 beta, you would see that the man page changes made it over. Personally, I would have preferred the code instead of the man pages. :) Per a discussion I had with Jerry Jelinek after I brought this up as part of the beta: Jerry said... backporting this to S10 until we have the ability to upgrade zones that reside on zfs. At this time we do not recommend customers place their zones on zfs. Obviously this works and is usually ok as long as you do not care about being able to upgrade your system, but this is not something we can generally support until we have an upgrade solution. So long as upgrades are not something that I am concerned about, it seems as though the following is an approach that would work out OK. Please let me know if you concur. ### Initial setup of /zones fs # zfs create local/zones # zfs set mountpoint=/zones local/zones ### Create my full-root template zone # zonecfg -z template-full create -t SUNWblank set zonepath=/zones/template-full verify commit exit # zfs create local/zones/template-full # chmod 700 /zones/template-full # zoneadm -z template-full install # zoneadm -z template-full boot # zlogin -C template-full ### Do zone customization stuff (e.g. run JASS to harden) ### Prepare the zone for cloning # zoneadm -z template-full halt # zoneadm -z template-full detach # zfs snapshot local/zones/[EMAIL PROTECTED] ### Create a clone # zonecfg -z newzone create -t template-full set zonepath=/zones/newzone set up networks, pools, etc. verify commit exit # zfs clone local/zones/[EMAIL PROTECTED] local/zones/newzone # zoneadm attach newzone # zoneadm -z newzone boot -s # yes | zlogin newzone sys-unconfig # zoneadm -z newzone boot # zlogin -C newzone perform sysidcfg stuff Jerry later said: This is a very clever procedure. You might want to send this out to the opensolaris zones-discuss list so that others can benefit from your idea here. I don't see any problems with this procedure. However, I waited until someone else announced the features or lack thereof found in S10 11/06. :) Mike -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best Practices recommendation on x4200
Mike Gerdts wrote: On 11/7/06, Richard Elling - PAE [EMAIL PROTECTED] wrote: d10 mirror of c0t2d0s0 and c0t3d0s0swap (2+2GB, to match above) Also a waste, use a swap file. Add a dumpdev if you care about kernel dumps, no need to mirror a dumpdev. How do you figure that allocating space to a swap file is less of a waste than adding space to a swap device? If you ever guess wrong (which you will), you can just make another swap file or redo the existing swap file. If you carve out a slice, then reclaiming the space is much more difficult. Creating more slices tends to also be difficult, so when you quess wrong you may still end up swapping to files. Simple /. Make it big enough to be useful. Keep its changes to a minimum. Make more than one, so that you can use LiveUpgrade. For consistency, you could make each disk look the same. s0 / 10G s6 zpool free s7 metadb 100M Since ZFS can get performance boosts from enabling the disk write cache if it has the whole disk, you may want to consider something more like the following for two of the disks (assumes mirroring rather than raidz in the zpool): s0 / 10G s1 swap pick your size s3 alt / 10G s6 zpool free s7 metadb 100M The other pair of disks are given entirely to the zpool. Use two disks for your BE, the other two for your ABE (assuming all are bootable). In any case, be sure that your root slices do not start at cylinder 0 (hmmm... maybe this is SPARC-specific advice...). I think this is folklore. Can you cite a reference? NB. traditionally, block 0 contains the vtoc and for SPARC systems, blocks 1-15 contain the bootblocks, see installboot(1M). Cylinder 0 may contain thousands of blocks for modern disks. It is a waste not to use them. AFAIK, all Sun software which deals with raw devices is aware of this. One way to populate an ABE is to mirror slices. However, you cannot mirror between a device that starts at cylinder 0 and one that does not. Where is this restriction documented? It doesn't make sense to me. Maybe you have a scar from running Sybase in a previous life? ;-) -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
Torrey McMahon wrote: Jason King wrote: Anxiously anticipating the ability to boot off zfs, I know there's been some talk about leveraging some of the snapshotting/cloning features in conjunction with upgrades and patches. What I am really hoping for is the ability to clone /, patch the clone, then boot off the clone (by doing a clone swap). I'm pretty sure we already have what you are looking for. Check out Live Upgrade on docs.sun.com. Right now, liveupgrade makes lots of assumptions about boot environments being in ufs file systems, but fixing that is part of the zfs-boot plan. So yes, the kinds of things you can do with liveupgrade, such as cloning environments and then patching or upgrading them, and then activating them, will be possible with zfs bootable environments (and will be a lot faster and easier, since cloning will be almost instantaneous and will not require a preallocated slice). I'm not sure what will turn out to be a gotcha for you, so let me just describe the basics of how zfs booting will work. Some storage pools will be designated as root pools, which means that they contain at least one dataset that contains a bootable root file system. There will be some restrictions on root pools (the only allowed configuration is an n-way mirror of single disks or slices, each of which must be accessible from the boot prom or BIOS), so best practice will be to keep data (such as database tables) in a pool separate from the root pool. (The separation isn't required but will probably turn out to be best for ease of management.) Some datasets will be designated as bootable, which means that they contain a root file system. A bootable environment (BE, in LiveUpgrade terminology) can consist of several datasets, exactly one of which is bootable. For example, it will be desirable in many cases to put each zone root in a separate dataset. Each of those zone root datasets will be subordinate to a bootable dataset which contains the root of the BE. Cloning a BE means cloning each dataset in the BE. We in the zfs-boot project owe the community more information about how the work is progressing. I hope we can get more of that information out fairly soon. Lori ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best Practices recommendation on x4200
On Thu, 2006-11-09 at 10:21, Richard Elling - PAE wrote: One way to populate an ABE is to mirror slices. However, you cannot mirror between a device that starts at cylinder 0 and one that does not. Where is this restriction documented? It doesn't make sense to me. Maybe you have a scar from running Sybase in a previous life? ;-) IIRC, that's a part of the history of disksuite / SVM. Moreover, it was that you cannot mirror a slice that has a VTOC label on it to one that does not... (hence the understanding of it being a cylinder 0 issue). http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/lvm/mirror/mirror_ioctl.c#887 Or, perhaps I need more coffee... Cheers! Nathan. ;) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] OpenSolaris vs. Solaris 10 11/06 (S10u3) for NFS ZFS Server
For me, it came down to - Do I want to patch, or upgrade? My gateway to the internet is a solaris 10 box, patched whenever required. I like that as soon as a security patch is available, I can apply it and reboot. Simple. My laptop runs nevada. I upgrade from network / dvd when I see a new feature that excites me. As far as whiz-bang things that would excite you, only you will know that for sure. :) Cheers! Nathan. On Thu, 2006-11-09 at 08:58, Wes Williams wrote: I'm in the process of building a Solaris NFS server with ZFS and was wondering if any gurus here have any comments as to choosing the upcoming Solairs 10 11/06 [presumably] or OpenSolaris bXX/Solairs Express for this use. Even with my use of OpenSolaris I maintain a service contract to show my support, so bug fixes in a static supported version shouldn't be an issue in picking a version. So, the short question is are there any super-cool must-have ZFS/NFS features in OpenSolaris now that S10u3 won't have right away? Thanks! 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] Is there inotify for ZFS?
Hi all, As inotify for Linux, is there same mechanism in Solaris for ZFS? I think this functionality is helpful for desktop search engine. I know one engineer of Sun is working on file event monitor, which will provide some information of file events, but is not for search purpose because it might has problem while monitoring a large system. Regards, Lingbo ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
