unknown
1970-01-01 00:00:00 UTC
I prefer idea B), I list idea A) as bad example.
The wiki update has been updated with idea B) for above sample and
comments.
How's that sounds?
I will provide a demo for lsm.MaskInfo later.
lsm.Capabilities.VOLUMES_QUICK_SEARCH
# This capability indicate plugin can perform a quick
# search without pull all data from storage system.
# Without this capability, plugin will pull all volumes from
# storage system to search given key. It only save socket data
# transfer between plugin and user API. If user want to
# do multiple search, it is suggested to query all volumes
# without 'search_key' parameter, then filter in user's code
# space.
Similar capability also added to other query methods except these two:
lsm.Client.pools()
lsm.Client.systems()
As they are mandatory, I assume no capability needed.
topic after we released 1.0 or 0.1.
I am not native English speaker with no creative mine. Do you any name
in mind?
=20
Lets go with this for now as I can't think of anything else better at
the moment. If we come up with something better before API freeze we
will do a rename.
=20
Anyone else have some suggestions?
=20
Yes, perhaps we could use FsDeltaRO, FsDeltaRW or are you suggesting we
change to single call with a copy type?
=20
I prefer 'FsReplication' containing all copy types. It provide less class a=
nd
methods.
ReplicationService.ModifyReplicaSynchronization() has this parameter:
[IN, Required] uint16 Operation,
Which was documented in PDF page 861:
* Failover
Enable the read and write operations from the host to the target elemen=
t.
This operation useful for situations when the source element is
unavailable.
* Failback
Switch the read/write activities from the host back to source
element. Update source element from target element with writes to
target during the failover period.
I chose 'giveback' as it seems more suitable.
Gris Ge
--gKMricLos+KVdGMg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTTojUAAoJEGzN5Y/kHij/pWsP/ijzvMLGTTipMmZzrgHpBtV1
ICPEXmWvB4QAA8KGKqHK/8Hwa2ChSI5fWu45AVOAY55K3Yan4zp+47WasfC/PyLd
hbUaoR1g22MY3wLxczC7zuuFoh84Hb6piBhoQZvINJdWxfu27ezxQi+wR3lwVtuP
Sfs/O7AhaUmQtZGJm7LEAhcFSK95EaoF9Th0iGSJzwtEofKCxT9M1kjtPGXwSN/p
eQ3FMO/J3IITRmO9nwj28cyy54j2OwGq3tMQR1Q/3hKgmrQXnNj4K/9W5/AoJJk2
Ev/mi0HXuOfXk+phRqVkxQ3ior734+j6kXPvMNv1bzlIrvY6WZNKcn4emy3KPj91
mHZAY59YrBQDZ1iVu2bQVTG6XO04cRIsG1GkBOVTPjJhp+chk6mQJsUzL5kvxwzS
2ZT+Ig91zNVs72Al5DiY+jINsNqtulH8aiZvAp5Z7mX1mhzR7wgDZH5nDfu2Q2nl
G6NmH6zFrYtYUzAqAHEfLA0sa7aRa5/jerBiI2ZHvHfYkHfyLezNig2GmwJVkOba
CkESWYc6HctmMeBCQJNQ2xKIM15Nn/p8kCnFrM4e5COzBqyT/31ExzK1uMri+mOq
CvjjkNQhsb4Vzklkb9Zze/95d/T4EntFhG0G/CeGhk04Ednlm5jRG0dZWqUNtFwY
5JwzBsPvOqXFUjmR7Zsx
=w+Z+
-----END PGP SIGNATURE-----
--gKMricLos+KVdGMg--
The wiki update has been updated with idea B) for above sample and
comments.
How's that sounds?
=20
If we are going to always support filtering and the plug-in cannot
offload search to array, we should provide generic filtering functions
for plug-ins writers. This will reduce traffic over the JSON RPC
interface. If you're only asking for 1 and the plugin needs to transfer
all across socket from array to plug-in, it would be better to not
transfer 100K across RPC for the client side code to search and throw
away.
Yes. Providing a plugin shared common/routine search function is better.If we are going to always support filtering and the plug-in cannot
offload search to array, we should provide generic filtering functions
for plug-ins writers. This will reduce traffic over the JSON RPC
interface. If you're only asking for 1 and the plugin needs to transfer
all across socket from array to plug-in, it would be better to not
transfer 100K across RPC for the client side code to search and throw
away.
I will provide a demo for lsm.MaskInfo later.
=20
I'm also thinking we may want to add a capability flag which denotes
array searching supported. That way a user could determine that it
would probably be faster for them to retrieve all items if they want to
do a number of different searching etc. on the data set themselves
instead of doing queries which result in the data being retrieved
multiple times.
I added this to lsm.Client.volumes():I'm also thinking we may want to add a capability flag which denotes
array searching supported. That way a user could determine that it
would probably be faster for them to retrieve all items if they want to
do a number of different searching etc. on the data set themselves
instead of doing queries which result in the data being retrieved
multiple times.
lsm.Capabilities.VOLUMES_QUICK_SEARCH
# This capability indicate plugin can perform a quick
# search without pull all data from storage system.
# Without this capability, plugin will pull all volumes from
# storage system to search given key. It only save socket data
# transfer between plugin and user API. If user want to
# do multiple search, it is suggested to query all volumes
# without 'search_key' parameter, then filter in user's code
# space.
Similar capability also added to other query methods except these two:
lsm.Client.pools()
lsm.Client.systems()
As they are mandatory, I assume no capability needed.
=20
Actually, this might be a good time to re-visit adding a generic caching
support layer, but we should probably defer that until later as it will
be hidden from user view.
=20
Since that does not change public interface, we can postpone the cacheActually, this might be a good time to re-visit adding a generic caching
support layer, but we should probably defer that until later as it will
be hidden from user view.
=20
topic after we released 1.0 or 0.1.
* VolumeReplication, wondering if we can come up with a better name?
Some document said 'Replica'.I am not native English speaker with no creative mine. Do you any name
in mind?
Lets go with this for now as I can't think of anything else better at
the moment. If we come up with something better before API freeze we
will do a rename.
=20
Anyone else have some suggestions?
=20
BTW, there is still having FsSnapshot, FsClone, should we merge them
into 'FsReplica'(need better name also)?
=20into 'FsReplica'(need better name also)?
Yes, perhaps we could use FsDeltaRO, FsDeltaRW or are you suggesting we
change to single call with a copy type?
=20
nd
methods.
So the giveback is really more than just making the data the same, it
also changes the access to the source and target volumes. Are these
directly modeled after SMI-S? I haven't explored the docs on these in
depth.
SMI-S 1.6rev 4 block book, PDF page 846:also changes the access to the source and target volumes. Are these
directly modeled after SMI-S? I haven't explored the docs on these in
depth.
ReplicationService.ModifyReplicaSynchronization() has this parameter:
[IN, Required] uint16 Operation,
Which was documented in PDF page 861:
* Failover
Enable the read and write operations from the host to the target elemen=
t.
This operation useful for situations when the source element is
unavailable.
* Failback
Switch the read/write activities from the host back to source
element. Update source element from target element with writes to
target during the failover period.
I chose 'giveback' as it seems more suitable.
=20
Thanks,
Tony
=20
--=20Thanks,
Tony
=20
Gris Ge
--gKMricLos+KVdGMg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTTojUAAoJEGzN5Y/kHij/pWsP/ijzvMLGTTipMmZzrgHpBtV1
ICPEXmWvB4QAA8KGKqHK/8Hwa2ChSI5fWu45AVOAY55K3Yan4zp+47WasfC/PyLd
hbUaoR1g22MY3wLxczC7zuuFoh84Hb6piBhoQZvINJdWxfu27ezxQi+wR3lwVtuP
Sfs/O7AhaUmQtZGJm7LEAhcFSK95EaoF9Th0iGSJzwtEofKCxT9M1kjtPGXwSN/p
eQ3FMO/J3IITRmO9nwj28cyy54j2OwGq3tMQR1Q/3hKgmrQXnNj4K/9W5/AoJJk2
Ev/mi0HXuOfXk+phRqVkxQ3ior734+j6kXPvMNv1bzlIrvY6WZNKcn4emy3KPj91
mHZAY59YrBQDZ1iVu2bQVTG6XO04cRIsG1GkBOVTPjJhp+chk6mQJsUzL5kvxwzS
2ZT+Ig91zNVs72Al5DiY+jINsNqtulH8aiZvAp5Z7mX1mhzR7wgDZH5nDfu2Q2nl
G6NmH6zFrYtYUzAqAHEfLA0sa7aRa5/jerBiI2ZHvHfYkHfyLezNig2GmwJVkOba
CkESWYc6HctmMeBCQJNQ2xKIM15Nn/p8kCnFrM4e5COzBqyT/31ExzK1uMri+mOq
CvjjkNQhsb4Vzklkb9Zze/95d/T4EntFhG0G/CeGhk04Ednlm5jRG0dZWqUNtFwY
5JwzBsPvOqXFUjmR7Zsx
=w+Z+
-----END PGP SIGNATURE-----
--gKMricLos+KVdGMg--