Ironically It's nfs exporting that is the real hog, cifs shares seem to come up pretty fast. The fact that cifs shares can be fast makes it hard for me to understand why Sun/Oracle seem to be making such a meal of this bug. Possibly because it only critically affects poor universities and not clients with the budget to throw hardware at the problem.
On Fri, Feb 26, 2010 at 11:59 PM, Richard Elling <richard.ell...@gmail.com>wrote: > On Feb 26, 2010, at 8:25 PM, Eric D. Mudama wrote: > > On Thu, Feb 25 at 20:21, Bob Friesenhahn wrote: > >> On Thu, 25 Feb 2010, Alastair Neil wrote: > >> > >>> I do not know and I don't think anyone would deploy a system in that > way with UFS. > >>> This is the model that is imposed in order to take full advantage of > zfs advanced > >>> features such as snapshots, encryption and compression and I know many > universities > >>> in particular are eager to adopt it for just that reason, but are > stymied by this > >>> problem. > >> > >> It was not really a serious question but it was posed to make a point. > However, it would be interesting to know if there is another type of > filesystem (even on Linux or some other OS) which is able to reasonably and > efficiently support 16K mounted and exported file systems. > >> > >> Eventually Solaris is likely to work much better for this than it does > today, but most likely there are higher priorities at the moment. > > > > I agree with the above, but the best practices guide: > > > > > http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#ZFS_file_service_for_SMB_.28CIFS.29_or_SAMBA > > > > states in the SAMBA section that "Beware that mounting 1000s of file > > systems, will impact your boot time". I'd say going from a 2-3 minute > > boot time to a 4+ hour boot time is more than just "impact". That's > > getting hit by a train. > > The shares are more troublesome than the mounts. > > > > > Might be useful for folks, if the above document listed a few concrete > > datapoints of boot time scaling with the number of filesystems or > > something similar. > > Gory details and timings are available in the many references to CR 6850837 > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6850837 > -- richard > > ZFS storage and performance consulting at http://www.RichardElling.com > ZFS training on deduplication, NexentaStor, and NAS performance > http://nexenta-atlanta.eventbrite.com (March 16-18, 2010) > > > > > _______________________________________________ > 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
