Исходное сообщение
"Facebook открыл код распределённой системы хранения LogDevic..." Отправлено Аноним, 13-Сен-18 22:21
> поищите на досуге ранние тесты производительности ntfs-3g. Они, по-моему, сохранились уже только в виде копипасты, но их много накопипастили, гугль найдет. https://web.archive.org/web/20080516235826/http://www.csamue.../ > fuse там дала прогадиться так, что Линус и компания в панике перерыли > код ext2/3 (устранив таки приличное количество узких мест) - конечно не Берем шаблонный хелловрот для фузе, тупо отдающий файл c tmpfs. Можно даже нагуглить "со всеми оптимизациями". Сравниваем с tmpfs, чешем репу. То, что оно на харде вполне может быть сопоставимо с нативом, никто не спорит, но попытка прокачивать большие файлы будет обломна (пару лет назад пытался свелосипедить мульти-медиа ФС на базе фузе - прилетела птица обломинго). > 8632910 kilobytes, 342 seconds > - уперлось во вполне себе in-kernel mirror на том конце где c > - при том что это запись/создание мелких файликов, оно у ntfs > медленное by design, а тут еще и context-switching, с модным kpti, поди ;-) ; 8632910/342/1024     ~24.65080752010233918129 25 MB/s - очешуительная скорость, ага. Особенно когда распаковываешь с NTFS-изошки на SSD в натив (тоже SSD). Оно, кстати, при монтировании без max_read еще и после пары десятков тысяч файлов зависнуть норовит.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> поищите на досуге ранние тесты производительности ntfs-3g. Они, по-моему, сохранились уже только в виде копипасты, но их много накопипастили, гугль найдет. > https://web.archive.org/web/20080516235826/http://www.csamuel.org/2007/04/25/comparing-ntfs-3g-to-zfs-fuse-for-fuse-performance/ >> fuse там дала прогадиться так, что Линус и компания в панике перерыли >> код ext2/3 (устранив таки приличное количество узких мест) - конечно не > Берем шаблонный хелловрот для фузе, тупо отдающий файл c tmpfs. > Можно даже нагуглить "со всеми оптимизациями". > Сравниваем с tmpfs, чешем репу. > То, что оно на харде вполне может быть сопоставимо с нативом, никто > не спорит, но попытка прокачивать большие файлы будет обломна (пару лет > назад пытался свелосипедить мульти-медиа ФС на базе фузе - прилетела птица > обломинго). >> 8632910 kilobytes, 342 seconds >> - уперлось во вполне себе in-kernel mirror на том конце где c >> - при том что это запись/создание мелких файликов, оно у ntfs >> медленное by design, а тут еще и context-switching, с модным kpti, поди ;-) > ; 8632910/342/1024 > ~24.65080752010233918129 > 25 MB/s - очешуительная скорость, ага. > Особенно когда распаковываешь с NTFS-изошки на SSD в натив (тоже SSD). Оно, > кстати, при монтировании без max_read еще и после пары десятков тысяч > файлов зависнуть норовит.
	Введите код, изображенный на картинке: