Renatk Dec 7 2011 at 13:15

Дистрибутив для оценки децентрализованной файловой системы Tahoe-LAFS

1 min

2.4K

Comments 7

SADKO Dec 7 2011 at 13:33

Интересно будет попробовать.
А можно ли надеяться на ускорение произвольного доступа к файлам при большой избыточности облака в локальной сети?

Renatk Dec 7 2011 at 13:42

Имеете в виду seek по файлу, или доступ к произвольным мелким файлам?

SADKO Dec 7 2011 at 15:48

Seek по большим файлам.
С мелкими всё наверное упирается в скорость поиска пиров. Но если пиры найдены, как между ними распределится нагрузка?

Renatk Dec 7 2011 at 15:55

Клиент, скачивающий файлы с пиров, определяет их доступность (по времени доступа), и старается забирать с самых быстрых серверов (нод).
Скорость поиска пиров не важна, т.к. клиент переодически опрашивает introducer (аналог торрент анонса) и получает адреса нод и затем производит к ним подключение, т.е. клиент готов в любой момент времени получать, отправлять файлы на ноды.

luckyredhot Jan 9 2013 at 15:31

А какая минимальная избыточность системы, т.е. сколько минимально процентов от изначального размера данных?

Renatk Jan 9 2013 at 15:52

Минимальная конфигурация: на 3 ноды записываются данные (т.е. чуть больше (на метаданные) от 1/3 объема от файла), и минимум 1 нода для избыточности. Т.е. при условии доступности 3х нод на чтение, файл будет прочитан.

Параметры конфигурации:

shares.needed = (int, optional) aka «k», default 3
shares.total = (int, optional) aka «N», N >= k, default 10
shares.happy = (int, optional) 1 <= happy <= N, default 7

luckyredhot Jan 9 2013 at 16:06

Спасибо, но пока не совсем могу понять!)
Насколько мне известно из архитектуры, сегменты файла и данные для восстановления распределяются между всеми доступными нодами. Интересно, сколько именно понадобится суммарного дискового пространства для хранения, скажем, файла размером 1 МБ?