Is there any way to freeze/thaw the zfs file system on solaris as any other traditional file system provides this functionality. I needed this to take the hardware (EMC Symmetrix Arrays) snapshots.
I’m aware of the fact that ZFS provides the snapshot/restore functionality but our requirement is to take the hardware snapshots.
@AndrewHenle's response is correct -- today you have to unmount / export the pool to successfully pause new IOs. fsfreeze is supported by most of the other widely-used filesystems in Linux, so I don't think it's unreasonable to hope that ZFS will support something similar someday. In fact, there is a feature request to support fsfreeze in ZFS on Linux here, and it doesn't even look that hard to implement (just hard to test ;-)).
That said, most people probably don't need to use fsfreeze before taking storage-level snapshots, since it's not required for crash consistency -- if your application running on top of ZFS can't deal with a snapshot being taken without freezing the filesystem, it also can't deal with your machine doing an unexpected hard reboot. ZFS is a bit better than other filesystems in this regard because it doesn't need to replay a transaction log or run fsck after a hard reboot to ensure correctness. Maybe this performance hit (having to replay the log) is why this is more important on other filesystems.
--- EDIT ----
I remembered a recent feature which could be used to implement something like this, called zpool checkpoint. A former colleague implemented this and wrote a brief article about it here.
For your use case, the idea is that when you're taking a hardware snapshot:
zpool checkpoint, which syncs all in-flight IOs to disk and stores a copy of the pool's uberblock (highest-level block in the filesystem tree) containing all those changes. This is similar to how ZFS snapshots an individual filesystem, but works for the entire pool. This creates a serialization point like the one you would use fsfreeze to create, where all IOs started before the checkpoint must finish and all IOs started after it are not captured in the checkpoint.zpool checkpoint --discard on the live system so that ZFS can continue freeing space on disk as it's overwritten (which is not possible while the checkpoint is active since that data may still be referenced by something in the checkpoint).zpool import --rewind-to-checkpoint instead of the normal zpool import to roll the pool's state back to the checkpoint, and then discard the checkpoint with zpool checkpoint --discard since you don't plan to roll the pool back to that point again once it's running (and you want to be able to free the space consumed by the checkpoint).This has the added advantage over fsfreeze that it does not pause IOs while the checkpoint is taken. However, it also has the disadvantages that (a) it's not used in other filesystems and is therefore a little more complex, and (b) you can't easily synchronize it with other application-level events, since it just happens "sometime" while the CLI command is running.