Do we still need the zpool.cache still. I believe early versions of zpool used the cache to remember what zpools to import at boot. I understand newer versions of zfs still use the cache but also check to see if the pool contains the correct host name of the server, and will only import if the hostname matches. I suggest ZFS at boot should (multi-threaded) scan every disk for ZFS disks, and import the ones with the correct host name and with a import flag set, without using the cache file. Maybe just use the cache file for non-EFI disk/partitions, but without the storing the pool name, but you should be able to tell ZFS to do a full scan which includes partition disk. Cheers -------- Original Message --------> ZFS maintains a cache of what pools were imported so that at boot time, > it will automatically try to re-import the pool. The file is > /etc/zfs/zpool.cache > and you can view its contents by using "zdb -C" > > If the current state of affairs does not match the cache, then you can > export the pool, which will clear its entry in the cache. Then retry the > import. > -- richard
Damon Atkins wrote:> Do we still need the zpool.cache still. I believe early versions of > zpool used the cache to remember what zpools to import at boot.Yes.> I understand newer versions of zfs still use the cache but also check > to see if the pool contains the correct host name of the server, and > will only import if the hostname matches.This serves a different function.> > I suggest ZFS at boot should (multi-threaded) scan every disk for ZFS > disks, and import the ones with the correct host name and with a > import flag set, without using the cache file. Maybe just use the > cache file for non-EFI disk/partitions, but without the storing the > pool name, but you should be able to tell ZFS to do a full scan which > includes partition disk.Full scans are a bad thing, because they cannot scale. This is one good reason why zpool.cache exists. What problem are you trying to solve? -- richard
>> I suggest ZFS at boot should (multi-threaded) scan every disk for ZFS >> disks, and import the ones with the correct host name and with a import flag >> set, without using the cache file. Maybe just use the cache file for non-EFI >> disk/partitions, but without the storing the pool name, but you should be >> able to tell ZFS to do a full scan which includes partition disk. > > Full scans are a bad thing, because they cannot scale. This is one > good reason why zpool.cache exists.What do you mean by cannot scale? Is it common to not use the majority of disks available to a system? If you "taste" all buses in parallel there should not be a scalability problem.> > What problem are you trying to solve?It would be nice to be able to move disks around when a system is powered off and not have to worry about a "cache" when I boot.
Mattias Pantzare wrote:>>> I suggest ZFS at boot should (multi-threaded) scan every disk for ZFS >>> disks, and import the ones with the correct host name and with a import flag >>> set, without using the cache file. Maybe just use the cache file for non-EFI >>> disk/partitions, but without the storing the pool name, but you should be >>> able to tell ZFS to do a full scan which includes partition disk. >>> >> Full scans are a bad thing, because they cannot scale. This is one >> good reason why zpool.cache exists. >> > > What do you mean by cannot scale? Is it common to not use the majority > of disks available to a system? >No, it is uncommon.> If you "taste" all buses in parallel there should not be a scalability problem. >Don''t think "busses," think "networks." NB, busses are on the way out, most modern designs are point-to-point (SAS, SATA, USB) or networked (iSCSI, SAN, NAS). Do you want to scan the internet for LUNs? :-)>> What problem are you trying to solve? >> > > It would be nice to be able to move disks around when a system is > powered off and not have to worry about a "cache" when I boot.Why are you worrying about it? -- richard
On Mon, Mar 23, 2009 at 22:15, Richard Elling <richard.elling at gmail.com> wrote:> Mattias Pantzare wrote: >>>> >>>> I suggest ZFS at boot should (multi-threaded) scan every disk for ZFS >>>> disks, and import the ones with the correct host name and with a import >>>> flag >>>> set, without using the cache file. Maybe just use the cache file for >>>> non-EFI >>>> disk/partitions, but without the storing the pool name, but you should >>>> be >>>> able to tell ZFS to do a full scan which includes partition disk. >>>> >>> >>> Full scans are a bad thing, because they cannot scale. This is one >>> good reason why zpool.cache exists. >>> >> >> What do you mean by cannot scale? Is it common to not use the majority >> of disks available to a system? >> > > No, it is uncommon.So, what do you mean by cannot scale?>> If you "taste" all buses in parallel there should not be a scalability >> problem. >> > > Don''t think "busses," think "networks." > > NB, busses are on the way out, most modern designs are point-to-point (SAS, > SATA, > USB) or networked (iSCSI, SAN, NAS). ?Do you want to scan the internet for > LUNs?Du you know how a device is made available to zfs, cache or no cache? All busses has to be probed when you do a reconfigure boot or run devfsadm. zfs will only se the devices that you se in /dev. If I can run zpool import in a reasonable amount of time the cahe is not needed. Are there cases where I can''t run zpool import?> >>> What problem are you trying to solve? >>> >> >> It would be nice to be able to move disks around when a system is >> powered off and not have to worry about a "cache" when I boot. > > Why are you worrying about it?If I put my disks on a diffrent controler zfs won''t find them when I boot. That is bad. It is also an extra level of complexity.
On Mon, Mar 23, 2009 at 4:45 PM, Mattias Pantzare <pantzare at gmail.com>wrote:> > > If I put my disks on a diffrent controler zfs won''t find them when I > boot. That is bad. It is also an extra level of complexity. >Correct me if I''m wrong, but wading through all of your comments, I believe what you would like to see is zfs automatically scan if the cache is invalid vs. requiring manual intervention, no? It would seem to me this would be rather sane behavior and a legitimate request to add this as an option. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090323/9b9dc92c/attachment.html>
On Tue, Mar 24, 2009 at 00:21, Tim <tim at tcsac.net> wrote:> > > On Mon, Mar 23, 2009 at 4:45 PM, Mattias Pantzare <pantzare at gmail.com> > wrote: >> >> >> If I put my disks on a diffrent controler zfs won''t find them when I >> boot. That is bad. It is also an extra level of complexity. > > Correct me if I''m wrong, but wading through all of your comments, I believe > what you would like to see is zfs automatically scan if the cache is invalid > vs. requiring manual intervention, no?That would be nice, but if there really is a problem with a scan that would not be good as that would trigger the very problem that the cache is supposed to avoid. But I don''t understand why we need it in the first place, except as a list of pools to import at boot.
Damon Atkins
2009-Mar-24 00:43 UTC
[zfs-discuss] Zpools on USB & zpool.cache & zpool import
The zpool.cache file makes clustering complex. {Assume the man page is still correct} From the zpool man page: cachefile=path | "none" Controls the location of where the pool configuration is cached. Discovering all pools on system startup requires a cached copy of the configuration data that is stored on the root file system. All pools in this cache are automatically imported when the system boots. **** Some environments, such as install and clustering, need to cache this information in a different location so that pools are not automatically imported. ***** Setting this property caches the pool configuration in a different location that can later be imported with "zpool import -c". ....... When the last pool using a cache file is exported or destroyed, the file is removed. zpool import [-d dir | -c cachefile] [-D] Lists pools available to import. If the -d option is not specified, this command searches for devices in "/dev/dsk". -- A truss of zpool import indicates that it is not multi-threaded when scanning for disks. ie. it scans 1 at a time instead of X at a time. So it does take a while to run. Would be nice if this was multi-threaded. If the cache file is to stay, it should do a scan of /dev to fix itself at boot if something is wrong, and report it is doing a scan to the console. esp if it is not multi-threaded. PS it would be nice to have a zpool diskinfo <devicepath> reports if the device belongs to a zpool imported or not, and all the details about any zpool it can find on the disk. e.g. file-systems (zdb is only for ZFS "engineers" says the man page). ''zpool import'' needs an option to list the file systems of a pool which is not yet imported and its properties so you can have more information about it before importing it. Cheers -------- Original Message --------> > > On Mon, Mar 23, 2009 at 4:45 PM, Mattias Pantzare <pantzare at gmail.com > <mailto:pantzare at gmail.com>> wrote: > > > > If I put my disks on a diffrent controler zfs won''t find them when I > boot. That is bad. It is also an extra level of complexity. > > > Correct me if I''m wrong, but wading through all of your comments, I > believe what you would like to see is zfs automatically scan if the > cache is invalid vs. requiring manual intervention, no? > > It would seem to me this would be rather sane behavior and a > legitimate request to add this as an option. > > --Tim
Damon Atkins
2009-Mar-24 00:45 UTC
[zfs-discuss] Zpools on USB & zpool.cache & zpool import
The zpool.cache file makes clustering complex. {Assume the man page is still correct} From the zpool man page: cachefile=path | "none" Controls the location of where the pool configuration is cached. Discovering all pools on system startup requires a cached copy of the configuration data that is stored on the root file system. All pools in this cache are automatically imported when the system boots. **** Some environments, such as install and clustering, need to cache this information in a different location so that pools are not automatically imported. ***** Setting this property caches the pool configuration in a different location that can later be imported with "zpool import -c". ....... When the last pool using a cache file is exported or destroyed, the file is removed. zpool import [-d dir | -c cachefile] [-D] Lists pools available to import. If the -d option is not specified, this command searches for devices in "/dev/dsk". -- A truss of zpool import indicates that it is not multi-threaded when scanning for disks. ie. it scans 1 at a time instead of X at a time. So it does take a while to run. Would be nice if this was multi-threaded. If the cache file is to stay, it should do a scan of /dev to fix itself at boot if something is wrong, and report it is doing a scan to the console. esp if it is not multi-threaded. PS it would be nice to have a zpool diskinfo <devicepath> reports if the device belongs to a zpool imported or not, and all the details about any zpool it can find on the disk. e.g. file-systems (zdb is only for ZFS "engineers" says the man page). ''zpool import'' needs an option to list the file systems of a pool which is not yet imported and its properties so you can have more information about it before importing it. Cheers -------- Original Message --------> > > On Mon, Mar 23, 2009 at 4:45 PM, Mattias Pantzare <pantzare at gmail.com > <mailto:pantzare at gmail.com>> wrote: > > > > If I put my disks on a diffrent controler zfs won''t find them when I > boot. That is bad. It is also an extra level of complexity. > > > Correct me if I''m wrong, but wading through all of your comments, I > believe what you would like to see is zfs automatically scan if the > cache is invalid vs. requiring manual intervention, no? > > It would seem to me this would be rather sane behavior and a > legitimate request to add this as an option. > > --Tim
Richard Elling
2009-Mar-24 14:26 UTC
[zfs-discuss] Zpools on USB & zpool.cache & zpool import
Damon Atkins wrote:> The zpool.cache file makes clustering complex. {Assume the man page is > still correct}The man page is correct. zpool.cache helps make clustering feasible because it differentiates those file systems which are of interest from those which are not. This is particularly important for environments where storage is shared: SAN, NAS, etc.> > From the zpool man page: > > cachefile=path | "none" > > Controls the location of where the pool configuration is cached. > Discovering all pools on system startup requires a cached copy of the > configuration data that is stored on the root file system. All > pools in this cache are automatically imported when the system > boots. > > **** Some environments, such as install and clustering, need to > cache this information in a different location so that pools are not > automatically imported. ***** > > Setting this property caches the pool configuration in a different > location that can later be imported with "zpool import -c". > ....... When the last pool using a cache file is exported or > destroyed, the file is removed. > > zpool import [-d dir | -c cachefile] [-D] > > Lists pools available to import. If the -d option is not > specified, this command searches for devices in > "/dev/dsk". > -- > A truss of zpool import indicates that it is not multi-threaded when > scanning for disks. ie. it scans 1 at a time instead of X at a time. So > it does take a while to run. Would be nice if this was multi-threaded.But you are complaining about removable media, so there is a timing issue. The "fixed" device locations are known early in the boot, as they are part of the boot archive. Removable devices are enumerated later. What I think you are complaining about is that if you have a zpool on a removable device, you want it to import when you plug it in. That functionality exists elsewhere -- not needed in ZFS, per se.> > If the cache file is to stay, it should do a scan of /dev to fix itself > at boot if something is wrong, and report it is doing a scan to the > console. esp if it is not multi-threaded. > > PS it would be nice to have a zpool diskinfo <devicepath> reports if > the device belongs to a zpool imported or not, and all the details about > any zpool it can find on the disk. e.g. file-systems (zdb is only for > ZFS "engineers" says the man page). ''zpool import'' needs an option to > list the file systems of a pool which is not yet imported and its > properties so you can have more information about it before importing it.Good idea. Please file an RFE. http://bugs.opensolaris.org category solaris/kernel/zfs -- richard
Hello Mattias, Monday, March 23, 2009, 9:08:53 PM, you wrote: MP> It would be nice to be able to move disks around when a system is MP> powered off and not have to worry about a "cache" when I boot. You don''t have to unless you are talking about share disks and importing a pool on another system while the original is powered off and the pool was not exported... For a configuration when disks are not shared among different systems you can move disk around without worrying about zpool.cache -- Best regards, Robert Milkowski http://milek.blogspot.com
> MP> It would be nice to be able to move disks around when a system is > MP> powered off and not have to worry about a "cache" when I boot. > > You don''t have to unless you are talking about share disks and > importing a pool on another system while the original is powered off > and the pool was not exported... > > For a configuration when disks are not shared among different systems > you can move disk around without worrying about zpool.cacheSo , what you are saying is that I can power off my computer, move my zfs-disks to a different controller and then power on my computer and the zfs file systems will show up? zpool export is not always practical, especially on a root pool.
+1 On Mon, Mar 23, 2009 at 8:43 PM, Damon Atkins <Damon.Atkins at yahoo.com.au> wrote:> PS it would be nice to have a zpool diskinfo <devicepath> reports ?if the > device belongs to a zpool imported or not, and all the details about any > zpool it can find on the disk. e.g. file-systems (zdb is only for ZFS > "engineers" says the man page). ''zpool import'' needs an option to list the > file systems of a pool which is not yet imported and its properties so you > can have more information about it before importing it.