[Lustre-devel] storing SOM epoch in EA

[Yuriy Umanets]

Alex Zhuravlev wrote:
> I guess there is some sort of misunderstanding here.
>
> we don't need fid->epoch mapping. we only need epoch along with other
> inode attributes. epoch is fixed size (8 bytes, probably few more for
> flags in future)
>
>   
Alex,

Yes, this is what I understand as well. And we were discussing that EA 
approach has some downsides. In fact what you propose, that is, store it 
in EA is logical taking into account that epoch is kind of extension to 
inode fields. It is property of inode-object. It is logical to store it 
with inode, I see your point. But as we saw, this has/may have some 
downsides which may be solved with IAM. Just take this in mind when you 
think/work on it. I do not see why IAM is such a bad here.

Thanks.
> thanks, Alex
>
>
> Yuriy Umanets wrote:
>   
>> Alex Zhuravlev wrote:
>>     
>>> Yuriy Umanets wrote:
>>>   
>>>       
>>>> EA is separate block is evil. It makes things slow.
>>>>     
>>>>         
>>> we have fast EAs (stored in inode, this is why we make them large) for years.
>>>   
>>>       
>> Well, people used horses for ages but this did not stop them from 
>> building cars :) Guys, I gave you idea, not worse than using EAs. I will 
>> not insist it is great. If you can't estimate its value yourself, well, 
>> let it be. We have such a nice thing as IAM and you keep talking about 
>> EAs...
>>
>> Seriously, IMHO what is bad about EAs:
>>
>> 1. You need to control their size, you need to bother;
>> 2. Large-fast inodes make create/lookup slow. You need to load this 
>> thing to memory after all. I think this is complement to additional 
>> seeks caused by IAM;
>> 3. Storing epoch in EA makes you use this chain to access epoch: 
>> fid->inode->epoch (in EA), IAM makes it shorter: fid->epoch (in IAM);
>> 4. Large inodes consume more RAM;
>> 5. There others...  but they are less related to technical 
>> downsides/advantages so I will omit them.
>>
>> Thanks.
>>
>>     
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>   


-- 
umka