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." thX! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061107/5428f8cf/attachment.html>
>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."SInce it refers to iowait it must refer to Solaris 9 or earlier; since it refers to "slow inode creation" it is nearly certain it refers to pre-logging ufs, which seems the default in S8 and earlier only. Casper
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. HTH Michael -- Michael Schuster Sun Microsystems, Inc.
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
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, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
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
Paul van der Zwan <Paul.Vanderzwan at Sun.COM> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
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.
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
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, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com