File sharing software

Yariv Sadan <>
Mon May 22 19:57:26 CEST 2006


On May 3, 2006, at 6:18 PM, Claes Wikstrom wrote:

> Yariv Sadan wrote:
>
>> Maybe it's possible to develop for Mnesia an alternative disc  
>> only  storage engine designed for storing large blobs. It wouldn't  
>> have to  be an Oracle killer. It would just have to handle very  
>> large data  sets, have decent performance, and avoid the  
>> rebuilding cost  associated with broken dets tables. Such a  
>> solution would make Mnesia  more versatile and therefore more  
>> appealing for applications for  which it makes sense to sacrifice  
>> soft real-time performance for  large storage capacity. What do  
>> you think?
>>
>
>
> This is certainly possible, I wrote dets some 15 years ago, and
> it high time to rewrite completely. It's been through several
> enhancements within the OTP group, but the original ideas are still
> there. Linear (P.A Larsson algorithm) hashing for indexing and
> a buddy allocator for space on the file.
>
> Two major problems with dets as of today (and of yeasterday)
>
> 1. 64 bit indexing - really easy to fix
> 2. repair time - this is a bit harder to fix, but one solution
>    could be along the following lines.
>
>   a) keep the index and the freelist in a different file,
>   b) have a file soley for the data. This file could be as easily
>      repaired as a disklog file. One could just chunk through it, one
>      term at a time, this way even large files will be fast to repair.
>   c) when an object is put on the freelist, it needs also to be
>      overwriten
>
>
> My daily 2c :-)
>
>
> /klacke

Hi list,

I have a few questions following up on Claes's comments. I'm still an  
Erlang newbie (hopefully not for too long), so please bear with me if  
they sound simple :)

- I'm a little confused about the 32 bit file offset issue. Integers  
in Erlang can be greater than 2^32, so how come dets offsets are  
limited to 32 bits? Is this a limitation of BEAM's native file IO code?
- Is dets limited to 32 bit offsets even if you run Erlang on 64 bit  
architectures?
- Is anybody planning on implementing Claes's solution to the repair  
time issue described above?

Your answers are appreciated!

Thanks,
Yariv





More information about the erlang-questions mailing list