[EMAIL PROTECTED] said: > It's interesting how the speed and optimisation of these maintenance > activities limit pool size. It's not just full scrubs. If the filesystem is > subject to corruption, you need a backup. If the filesystem takes two months > to back up / restore, then you need really solid incremental backup/restore > features, and the backup needs to be a cold spare, not just a > backup---restoring means switching the roles of the primary and backup > system, not actually moving data.
I'll chime in here with feeling uncomfortable with such a huge ZFS pool, and also with my discomfort of the ZFS-over-ISCSI-on-ZFS approach. There just seem to be too many moving parts depending on each other, any one of which can make the entire pool unavailable. For the stated usage of the original poster, I think I would aim toward turning each of the Thumpers into an NFS server, configure the head-node as a pNFS/NFSv4.1 metadata server, and let all the clients speak parallel-NFS to the "cluster" of file servers. You'll end up with a huge logical pool, but a Thumper outage should result only in loss of access to the data on that particular system. The work of scrub/resilver/replication can be divided among the servers rather than all living on a single head node. Regards, Marion _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
