On Jul 13, 2007, at 2:20 AM, Richard L. Hamilton wrote: >> 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.
We are busy layering pNFS on ZFS in the NFSv4.1 project and hope to allow for coordination with client access and other interesting features. Spencer _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
