On Mar 31, 2010, at 2:50 AM, Damon Atkins wrote: > Why do we still need "/etc/zfs/zpool.cache" file??? > (I could understand it was useful when zfs import was slow)
Yes. Imagine the case where your server has access to hundreds of LUs. If you must probe each one, then booting can take a long time. If you go back in history you will find many cases where probing all LUs at boot was determined to be a bad thing. > zpool import is now multi-threaded > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844191), hence a > lot faster, each disk contains the hostname > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6282725) , if a > pool contains the same hostname as the server then import it. > > ie This bug should not be a problem any more > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6737296 with a > multi-threaded zpool import. > > HA Storage should be changed to just do a zpool -h import mypool instead of > using a private zpool.cache file (-h being ignore if the pool was imported by > a different host, and maybe a noautoimport property is need on a zpool so > clustering software can decided to import it by hand as it was) > > And therefore this zpool zplit problem would be fixed. There is also a use case where the storage array makes a block-level copy of a LU. It would be a bad thing to discover that on a probe and attempt import. -- richard ZFS storage and performance consulting at http://www.RichardElling.com ZFS training on deduplication, NexentaStor, and NAS performance Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
