Some people asked me to comment on the DISC proposal, as explained in a paper by by Dingshan He, David Du and Gary Grider. This papers describes an idea that has been around for several years: do HSM on a per OST basis. The paper explains how to manage migration status and locking and has an interesting evaluation of performance. We do not intend to pursue this, principally, for 3 reasons: - it does not plan for whole file migration of striped files, which is a requirement for several of our customers. A restriping component between Lustre and the HSM backend is important in my opinion. - it requires a tape interface for every OST node; there can be many OST''s (many 100''s now, 1000''s by 2010 - I suspect) and this could get expensive and may not scale. - the wasn''t planned to generalize to the Lustre file system being a cache for the HSM. Since caches are very desirable also, it is better to unify the two approaches. I hope this clarifies peoples questions about this option. - Peter - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.clusterfs.com/pipermail/lustre-devel/attachments/20060823/54c26969/attachment.html