[Lustre-devel] Wide striping

David Dillow dillowda at ornl.gov
Wed Oct 5 16:56:54 PDT 2011

On Wed, 2011-10-05 at 19:31 -0400, Oleg Drokin wrote:
> Hello!
> On Oct 5, 2011, at 3:44 PM, wangdi wrote:
> >> Since the FID -> Objid mapping is performed locally, it doesn't
> need to be assigned until the first write.  This is not integral to
> the design, just a side effect.
> > Ah, you mean the object ID can be assigned during the first access,
> instead of FID? This is indeed an interesting idea, and do not need
> extra space. But this may add some limits of the future. (what if we
> decides to store some small file data in MDT directly?) And also it
> will add another difference between MDT and OST, probably it conflicts
> with the efforts of unifying MDT and OST?  I still prefer to have real
> OST FID, i.e. every object has its own identification in the cluster.
> Please correct me if I miss the point of your suggestion.
> Another problems I see here are similar to create on write.
> Say if we delete a file, do we purge this mapping table too? and then
> when stale client comes we recreate an orphan object?
> Or we don't purge the table and let it grow indefinitely using more
> and more space and eventually slowing down lookups?
> Or do we purge really old objects from it only, what triggers it, what
> failure scenarios are there for this process?
> How do we recover from disasters that happened to this table?

Wouldn't the online lfsck work being done for OpenSFS catch and correct
these types of problems?

It seems like it could provide a base for purging/compacting the table
as well, but that's obviously going to be a complicated endeavor....
Dave Dillow
National Center for Computational Science
Oak Ridge National Laboratory
(865) 241-6602 office

More information about the lustre-devel mailing list