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

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

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

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

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

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

                      Статистика, батенька, пугает! Крадем беспощЯдно секунды постоянно ... а потом бац, в следующем тысячелетии ... спрогнозировали, что в ближайшее тысячелетии таки осилим, таки найдем заветный блок.
                        беспощадно по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость! Сила!
                          Не знаю как до тебя достучаться .... 1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не?
                            Цитата 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/иное, можно было бы в самые неожиданные моменты всюду быстро бегать, ориентироваться, а не искать "есть ли на диске такой-то файл?". Просто с записью файла пишем его КС в общий архивчик и поиск файлов будет крайне быстрым (не по названию, конечно, но всё равно).

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


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0358 ]   [ 16 queries used ]   [ Generated: 28.03.24, 16:37 GMT ]