Ben Rockwood wrote: > This is wonderful Dave! I love your conclusions and proposals. I'll > be the storage zealot with the following points: > > 1) On page 13 you noted iSCSI. I think that we'll continue to see > iSCSI grow in popularity and in many ways be used in the same > situations that we currently leverage NFS. For instance, I currently > use an iSCSI LUN for my Flash Archives, home directory, backups, etc. > In many cases I've already started using ZFS on iSCSI for these > purposes. I don't see that this really changes your document at all, > but just wanted to add some supporting evidence by the need you > already defined in your document. I greatly appreciate you think far > enough ahead to consider iSCSI at this early stage in the project. > > 2) Perhaps I missed it, but I see no mention of SVM. While SVM is a > powerful and useful tool, in the context of SMB/Developers, it is > extremely difficult to use. Root mirroring can be difficult and > error prone even for seasoned Solaris administrators but is > considered a standard practice throughout the industry. This is only > made worse by the fact that you must be experienced with SVM to know > that you need to set aside a small slice for the SVM MetaDB's. I've > seen plenty of users and admins get frustrated with SVM immediately > because they were unaware of this requirement untill they'd already > fully installed the system. >
Ignoring SVM is somewhat intentional, in that we'd expect ZFS to supercede it, especially in the SMB/Developer market because the simplicity of the administration model is especially attractive there. Now, that's not to say we can't architect installation in such a way that SVM or other traditional volume managers could be plugged in, and perhaps that's the way to approach the problem: storage management is a choice. Sun's likely to invest heavily in the ZFS choice and make it a default in the Solaris product, but others might choose to invest in alternatives for their own products. Thanks for raising the issue. > Most Linux administrators would take for granted the fact that > installers like Anaconda by default will setup LVM to root mirror. > By making root mirroring an option during install we can really ease > the burden on a lot of SA's and make it a non-issue for users who > just want it but don't care about SVM at all. > Our expectation is that the ZFS pools for root will be mirrored. > > As a side note, the current default partitioning scheme is really > misleading to new users. Allocating root just slightly larger than > they need and then allocating all over free space to /export > (something that Linux admins have rarely even heard of or > understand). A default of providing all space to root and then > letting uses modify from there is a much more friendly approach. > I'd probably split the difference a bit - we certainly have to allocate more for root than we do, in order to support the best practice upgrade model, but I don't think I'd put it all there. > Other issues that I find confuse new uses revolve around "strange" > Sun defaults, like AutoFS for /home (new users can't create home > directories in /home, and often don't know why) and always booting a > new system to a friendly Sendmail error because they don't provide a > FQDN for /etc/hosts. > The latter is something I expect we'll fix in the default configuration. Using autofs for /home has such a deep history with SunOS that it may have achieved sacred cow status. > I look forward to watching this project unfold. Your a brave man > Dave! Or possibly stupid. Thanks, though! Dave
