Thanks for the feedback Zesheng Wu. My responses are below.
1. About the storage type, because I didn't participate the discussion in
HDFS-2832, I am confused by the current storage type DISK and SSD. I think SSD is also one type of disk, DISK and SSD are not orthogonal. Can we change storage type to HDD and SDD, this will be more straightforward?
Good point, I'll look into making the names clearer. In a subsequent revision of the API we would like to eliminate the hard-coded names from code altogether.
2. About setStorageTypeSpaceQuota/getStorageTypeSpaceQuota, these two names are not very natural. From the literal meaning, it sounds like setting/getting space quota on some storage type other than some type of storage. I would suggest that setStorageSpaceQuota/getStorageSpaceQuota will be better. I am not a native English speaker, if I were wrong, just ignore this.
The function name should communicate that this is disk space quota for a specific storage type, as opposed to the overall quotas which are set with setQuota. If the proposed name is hard to follow, how about get/setsetQuotaByStorageType?
3. About the command line, hdfs dfsadmin -get(set)StorageTypeSpaceQuota, I think get(set) one storage type once is simple and straightforward, if we get(set) more than one once, because there's no atomicity guarantee, it's complicated to handle failure.
Yes I think we can simplify the command line as you suggested.
4. About the StoragePreference class, as you said in the design doc in
HDFS-2832, in the future HDFS will support place replicas on different storages, such as 1 on SSD, and 2 on HDD. I would suggest that StoragePerference class can support specifying storage type of each replica now, in this way, we can easily support the above feature in the future.
Let's defer this for now. The API and protocol can both be easily extended in a backwards compatible manner in the future without affecting existing applications.
5. About the create file sematics, as you said in the doc "During file creation there must be sufficient quota to place at least one block times the replication factor on the target storage type, otherwise the request is falied immediately with QuotaExceededException", I think it will be more natural and friendly that first create the file on the default storage(HDD) if there's not enough space of desired storage type , and than let the namenode replicate the block to desired storage lazily when there's enough space available.
We have to differentiate between quota unavailability vs disk space availability. The former will result in a quota violation exception, the latter will result in the behavior you described. We discuss the reasons for this in the
HDFS-2832 design doc.