pNFS is NFS-centric of course and it is not yet stable, isn't it? btw, what is the ETA for pNFS putback?
On Thu, 2008-10-16 at 12:20 -0700, Marion Hakanson wrote: > [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 > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
