From: Ross S. W. W. <RW...@me...> - 2012-04-20 16:39:32
|
Yucong Sun (叶雨飞) [mailto:sun...@gm...] wrote: > > well for ietd we can't rely on zfs, I'm looking into > implementing ATS as next step and we may just rely on kernel atomics. Disregarding the whole ZFS stuff of course. Using the kernel atomics is a given, but it should also be compatible with reserve/release and persistent reservations, which can be tricky. > XCOPY maybe done with same logic too, but without a > copy-on-write implementation it will be worthless except for > save some small back-and-forth bandwidth and STUN won't work > on raw block device anyway. For XCOPY it would save transfer to/from initiator of the data which could be significant. It would be difficult to implement though given IET's architecture. STUN/QUOTA only apply to thin provisioned backing stores which could be LVM volumes OR sparse files. COW isn't a requirement here, only thin provisioned. This feature can be piggy backed on detecting backing store geometry changes since both require polling the backing store for information on a schedule or using some sort of notification system. > So I don't foresee on implementing latter two, just the ATS > and WRITE_SAME_16. ATS is of course a no-brainer, but XCOPY/STUN/QUOTA can also be useful as there are users using sparse files and LVM snapshots/clones for backing stores. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. |