On Tue, Sep 30, 2008 at 08:54:50PM -0500, Tim wrote: > As it does in ANY fileserver scenario, INCLUDING zfs. He is building a > FILESERVER. This is not an APPLICATION server. You seem to be stuck on > this idea that everyone is using ZFS on the server they're running the > application. That does a GREAT job of creating disparate storage islands, > something EVERY enterprise is trying to get rid of. Not create more of.
First off there's an issue of design. Wherever possible end-to-end protection is better (and easier to implement and deploy) than hop-by-hop protection. Hop-by-hop protection implies a lot of trust. Yes, in a NAS you're going to have at least one hop: from the client to the server. But how does the necessity of one hop mean that N hops is fine? One hop is manageable. N hops is a disaster waiting to happen. Second, NAS is not the only way to access remote storage. There's also SAN (e.g., iSCSI). So you might host a DB on a ZFS pool backed by iSCSI targets. If you do that with a random iSCSI target implementation then you get end-to-end integrity protection regardless of what else the vendor does for you in terms of hop-by-hop integrity protection. And you can even host the target on a ZFS pool, in which case there's two layers of integrity protection, and so some waste of disk space, but you get the benefit of very flexible volume management on both, the initiator and the target. Third, who's to say that end-to-end integrity protection can't possibly be had in a NAS environment? Sure, with today's protocols you can't have it -- you can get hop-by-hop protection with at least one hop (see above) -- but having end-to-end integrity protection built-in to the filesystem may enable new NAS protocols that do provide end-to-end protection. (This is a variant of the first point above: good design decisions pay off.) Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
