На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
! Правила трёх "С"
Пожалуйста,
1. Соблюдайте правила Форума.
2. Слушайте советы Модераторов.
(например, http://forum.sources.ru/index.php?act=ST&f=7&t=80382 )
3. Сверяйтесь с учебником по Великому и Могучему
Модераторы: JoeUser
  
> Модернизация файловой системы, Встроенный MD5 или подобное
// пардон, если тема не сюда, но куда точнее не нашёл. :blush:
Скажите, а есть ли такие файловые системы (ФС) (или можно ли дособирать ФС), чтобы она автоматом (или в фоне во время безделья) считала какую-нибудь контрольную сумму (КС) всякого файла (каталога?) и хранила её в файловой записи/альтерн.потоке, дабы сравнение файлов шло в мгновение? И при копировании (перезаписи) она бы автоматом не копировала файлы с одинаковой КС (ну, накрайняк, спрашивала), ещё где-то использовала это полезное свойство?!
:thanks:
Славян, это не относится к функциям файловой системы. Виндовс, к примеру, имеет службу индексирования для ускорения поиска. Поэтому приемлимый вариант - писать демона, который в фоне пересчитывает контрольные суммы файлов и пишет их в альтернативные потоки. Естественно, нужно реализовать два функционала:

1) Пересчет файлов в фоне, у которых не прописана контрольная сумма
2) Слежение и пересчет контрольных сумм изменившихся файлов

Но ... Альтернативными потоками может пользоваться не только твоя прога. А это черевато.
Мои программные ништякиhttp://majestio.info
Хм-м... просто если бы это провернуть даже как-то аппаратно (ЖД получает блок в 4Кб (или сколько-то) и КС), то мож и запись физическая на винт многократно ускорилась бы, не делая ненужных перезаписей одного и того же.

Впрочем, мысль "относится ли сие к ФС или нет" - мне видится крайне непонятной, Joe.
Славян, простая перезапись блока гораздо быстрее, чем поиск его содержимого на диске. Смирись! :lol:
Но вот ФС с фоновой дедупликацией, они есть, например - Btrfs или ZFS.
Мои программные ништякиhttp://majestio.info
А при чём тут поиск? Устройство получает блок и КС, сверяется с записанным блоком и КС, и (при равных КС) забивает на запись. Явно ж быстрее будет!!
А ... т.е. ты хотел это реализовать на "плоских" ФС, а-ля FAT, NTFS, HPFS? Ну может быть для каких-то слишком разряженных данных это бы и прокатило, но для реальной ситуации, "бытовой" - это будет реальный ттттттттттттормоз. Ибо вероятность встретить свободный блок с одинаковым содержимым записываемому - никакущая. Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев.

Добавлено
ЗЫ: Вот на ФС, построенных на деревьях, можно было бы поразмышлять... И то, не думаю, что создатели, к примеру, ZFS об этом не задумывались.
Мои программные ништякиhttp://majestio.info
Цитата JoeUser @
Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев.
Да, и в этом и есть могущество и мощь социа... принципа "с миру по нитке, - голому рубаха"! Т.е. вы тратите в каждый чих ещё толику чтений-сравнений, но зато на огромном пришедшем куске оказывается многократно/ощутимо/весомо выигрываете, когда он равен имеющемуся такому же!!
Цитата Славян @
Т.е. вы тратите в каждый чих ещё толику чтений-сравнений

Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD :lol: И толика она - в результате не такая уже толика. Короч, твое предложение, чисто ИМХО, включить в ФС - функционал лотереи "Спортлото" :lol:
Мои программные ништякиhttp://majestio.info
Цитата JoeUser @
Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD
Ну пусть не "в чих", а "на каждый шаг", не суть. Да, это преждевременный износ, но это как у вас бы из каждого дня выкрадывали секунду/атом, а спустя годы предъявили бы зато для человечества нового ребёнка/год жизни! Т.е. обираем по чуть-чуть, но в крупном это станет сильно=качественно заметно.
Короче, мне не видно, отчего вам не нравится сей метод. Никак не вижу. :-? :no-sad:
Цитата Славян @
Короче, мне не видно, отчего вам не нравится сей метод. Никак не вижу.

Статистика, батенька, пугает! Крадем беспощЯдно секунды постоянно ... а потом бац, в следующем тысячелетии ... спрогнозировали, что в ближайшее тысячелетии таки осилим, таки найдем заветный блок.
Мои программные ништякиhttp://majestio.info
беспощадно по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость! Сила!
Не знаю как до тебя достучаться .... 1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не?
Мои программные ништякиhttp://majestio.info
Цитата JoeUser @
1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не?
Да, разница огромна! Но я тоже не знаю как до вас "достучаться":
Цитата Славян @
по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость!
:whistle:
Цитата Славян @
Да, разница огромна! Но я тоже не знаю как до вас "достучаться":

Прежде чем реализовывать данную фичу на уровне файловой системы, можно попробовать прикинуть реальную ее пользу достаточно простым способом.
Предположим есть какая-то файловая система (реальная, гигабайт на 500).
Берем для этого какой-нибудь свой раздел с документами, музыкой, фильмами и т.п.
Прежположим там будет файлов, ну скажем 200000.
Создаем простую базу данных хоть в mysql, хоть в postgresql, хоть sqlite, хоть....
куда в одну табличку записываем полное имя файла с абсолютным путем и считаем его хеш
(например, на питоне можно написать такой скрипт).
Просматриваем все 200000 файлов, считаем для каждого хеш, записываем все в базу данных.
Получилась как бы некая левая файловая система, в которой записаны все файлы и хеши для каждого файла.
По окончанию записи берем и спрашиваем у "файловой системы --- базы данных", а сколько у нас получилось одинаковых хешей??

Без преувеличения полагаю, ну 1, ну 2... ну максимум 5 :))

Об этом и говорят, что по сравнению с общей кучей в 500 гигабайт и 200000 файлов, тратить такие усилия на уровне файловой системы для 1-5 файлов, НУ КРАЙНЕ нерационально и никакого выигрыша это не даст, разве что при обращении к этим файлам.

Хорошо, пусть "одинаковых" файлов будет не 5, а 500... ну хрен с ним 5000 (я слабо себе представляю зачем это мне?? и как я до этого докатился??). Можно очень долго заниматься оптимизацией баз данных, но сама по себе операция поиска одинакового хеша среди 200000 записей является весьма затратной процедурой: Надо поддерживать как-то доп. индекс, его пересчитывать, пересортировывать, чтобы поиск занимал тысяные доли секунды и меньше.

На мой взгляд опять целесообразность таких затрат является сомнительной.

Хорошо, пусть не одинаковые файлы, спустимся на уровень блоков файловой системы, из которых состоят все современные файловые системы. А как для блоков пересчитывать хеши?? Нет, сам счет все легко, считаем для 4096 байт, записываем в базу данных. А правильно ли в принципе пересчитывать блоки?? Каковая вероятность, что блоки будут одинаковые?? Ну допускаю, что у одинаковых файлов будут одинаковые блоки. А у разных?? Или почти разных??

В общем, надеюсь я Вас убедил, что не выглядит здравой идея считать хеши, лишь для того, чтобы экономить операции записи для очень-очень-очень малой части файлов из всей общей кучи файлов.
Раз так, то постараюсь тоже зайти с несколько боковой стороны:
1. Смотрите, пусть люди хотят сравнить картинки. Алгоритм может быстро пробежаться по файлам, посмотреть размеры картинок и выдать "не равны", если уже размеры разные. И вот тут размеры - и есть контрольная сумма, пусть и слабенькая.
2. А если ОС ставит всякие драйверы, файлы нужные для чего-то, то ей не надо было бы вскрывать файл, запись, ещё что, она бы просто сверилась с контрольной суммой и сказала: "у вас вот это установлено, а вот этого нету". И, храня такую базу MD5/иное, можно было бы в самые неожиданные моменты всюду быстро бегать, ориентироваться, а не искать "есть ли на диске такой-то файл?". Просто с записью файла пишем его КС в общий архивчик и поиск файлов будет крайне быстрым (не по названию, конечно, но всё равно).

Суть, ещё раз, в том, что мы с блоком данных (большим!) храним маленькое существенное качество, кое (в некоторые неожиданные моменты) нам резко может помочь.
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:


Рейтинг@Mail.ru
[ Script Execution time: 0,1404 ]   [ 19 queries used ]   [ Generated: 23.09.18, 14:16 GMT ]