> Bringing this back towards ZFS-land, I think that > there are some clever > things we can do with snapshots and clones. But the > age-old problem > of arbitration rears its ugly head. I think I could > write an option to expose > ZFS snapshots to read-only clients. But in doing so, > I don't see how to > prevent an ill-behaved client from clobbering the > data. To solve that > problem, an arbiter must decide who can write where. > The SCSI > rotocol has almost nothing to assist us in this > cause, but NFS, QFS, > and pxfs do. There is room for cleverness, but not > at the SCSI or block > level. > -- richard
Yeah; ISTR that IBM mainframe complexes with what they called "shared DASD" (DASD==Direct Access Storage Device, i.e. disk, drum, or the like) depended on extent reserves. IIRC, SCSI dropped extent reserve support, and indeed it was never widely nor reliably available anyway. AFAIK, all SCSI offers is reserves of an entire LUN; that doesn't even help with slices, let alone anything else. Nor (unlike either the VTOC structure on MVS nor VxFS) is ZFS extent-based anyway; so even if extent reserves were available, they'd only help a little. Which means, as he says, some sort of arbitration. I wonder whether the hooks for putting the ZIL on a separate device will be of any use for the cluster filesystem problem; it almost makes me wonder if there could be any parallels between pNFS and a refactored ZFS. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
