| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > *nix > Модернизация файловой системы |
| Автор: Славян 16.09.18, 17:44 |
// пардон, если тема не сюда, но куда точнее не нашёл.  Скажите, а есть ли такие файловые системы (ФС) (или можно ли дособирать ФС), чтобы она автоматом (или в фоне во время безделья) считала какую-нибудь контрольную сумму (КС) всякого файла (каталога?) и хранила её в файловой записи/альтерн.потоке, дабы сравнение файлов шло в мгновение? И при копировании (перезаписи) она бы автоматом не копировала файлы с одинаковой КС (ну, накрайняк, спрашивала), ещё где-то использовала это полезное свойство?!  |
| Автор: JoeUser 16.09.18, 18:32 |
| Славян, это не относится к функциям файловой системы. Виндовс, к примеру, имеет службу индексирования для ускорения поиска. Поэтому приемлимый вариант - писать демона, который в фоне пересчитывает контрольные суммы файлов и пишет их в альтернативные потоки. Естественно, нужно реализовать два функционала: 1) Пересчет файлов в фоне, у которых не прописана контрольная сумма 2) Слежение и пересчет контрольных сумм изменившихся файлов Но ... Альтернативными потоками может пользоваться не только твоя прога. А это черевато. |
| Автор: Славян 16.09.18, 19:02 |
| Хм-м... просто если бы это провернуть даже как-то аппаратно (ЖД получает блок в 4Кб (или сколько-то) и КС), то мож и запись физическая на винт многократно ускорилась бы, не делая ненужных перезаписей одного и того же. Впрочем, мысль "относится ли сие к ФС или нет" - мне видится крайне непонятной, Joe. |
| Автор: JoeUser 16.09.18, 20:50 |
Славян, простая перезапись блока гораздо быстрее, чем поиск его содержимого на диске. Смирись!  Но вот ФС с фоновой дедупликацией, они есть, например - Btrfs или ZFS. |
| Автор: Славян 17.09.18, 01:58 |
| А при чём тут поиск? Устройство получает блок и КС, сверяется с записанным блоком и КС, и (при равных КС) забивает на запись. Явно ж быстрее будет!! |
| Автор: JoeUser 17.09.18, 10:03 |
| А ... т.е. ты хотел это реализовать на "плоских" ФС, а-ля FAT, NTFS, HPFS? Ну может быть для каких-то слишком разряженных данных это бы и прокатило, но для реальной ситуации, "бытовой" - это будет реальный ттттттттттттормоз. Ибо вероятность встретить свободный блок с одинаковым содержимым записываемому - никакущая. Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев. Добавлено ЗЫ: Вот на ФС, построенных на деревьях, можно было бы поразмышлять... И то, не думаю, что создатели, к примеру, ZFS об этом не задумывались. |
| Автор: Славян 17.09.18, 14:06 |
| Цитата JoeUser @ Да, и в этом и есть могущество и мощь Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев. |
| Автор: JoeUser 17.09.18, 14:17 |
| Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD И толика она - в результате не такая уже толика. Короч, твое предложение, чисто ИМХО, включить в ФС - функционал лотереи "Спортлото" |
| Автор: Славян 17.09.18, 14:34 |
| Цитата JoeUser @ Ну пусть не "в чих", а "на каждый шаг", не суть. Да, это преждевременный износ, но это как у вас бы из каждого дня выкрадывали секунду/атом, а спустя годы предъявили бы зато для человечества нового ребёнка/год жизни! Т.е. обираем по чуть-чуть, но в крупном это станет сильно=качественно заметно.Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD Короче, мне не видно, отчего вам не нравится сей метод. Никак не вижу.   |
| Автор: JoeUser 17.09.18, 19:21 |
| Статистика, батенька, пугает! Крадем беспощЯдно секунды постоянно ... а потом бац, в следующем тысячелетии ... спрогнозировали, что в ближайшее тысячелетии таки осилим, таки найдем заветный блок. |
| Автор: Славян 17.09.18, 19:44 |
| беспощадно по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость! Сила! |
| Автор: JoeUser 17.09.18, 21:08 |
| Не знаю как до тебя достучаться .... 1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не? |
| Автор: Славян 18.09.18, 00:57 |
| Да, разница огромна! Но я тоже не знаю как до вас "достучаться": Цитата Славян @ по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость!  |
| Автор: grgdvo 18.09.18, 12:40 |
| Прежде чем реализовывать данную фичу на уровне файловой системы, можно попробовать прикинуть реальную ее пользу достаточно простым способом. Предположим есть какая-то файловая система (реальная, гигабайт на 500). Берем для этого какой-нибудь свой раздел с документами, музыкой, фильмами и т.п. Прежположим там будет файлов, ну скажем 200000. Создаем простую базу данных хоть в mysql, хоть в postgresql, хоть sqlite, хоть.... куда в одну табличку записываем полное имя файла с абсолютным путем и считаем его хеш (например, на питоне можно написать такой скрипт). Просматриваем все 200000 файлов, считаем для каждого хеш, записываем все в базу данных. Получилась как бы некая левая файловая система, в которой записаны все файлы и хеши для каждого файла. По окончанию записи берем и спрашиваем у "файловой системы --- базы данных", а сколько у нас получилось одинаковых хешей?? Без преувеличения полагаю, ну 1, ну 2... ну максимум 5  )Об этом и говорят, что по сравнению с общей кучей в 500 гигабайт и 200000 файлов, тратить такие усилия на уровне файловой системы для 1-5 файлов, НУ КРАЙНЕ нерационально и никакого выигрыша это не даст, разве что при обращении к этим файлам. Хорошо, пусть "одинаковых" файлов будет не 5, а 500... ну хрен с ним 5000 (я слабо себе представляю зачем это мне?? и как я до этого докатился??). Можно очень долго заниматься оптимизацией баз данных, но сама по себе операция поиска одинакового хеша среди 200000 записей является весьма затратной процедурой: Надо поддерживать как-то доп. индекс, его пересчитывать, пересортировывать, чтобы поиск занимал тысяные доли секунды и меньше. На мой взгляд опять целесообразность таких затрат является сомнительной. Хорошо, пусть не одинаковые файлы, спустимся на уровень блоков файловой системы, из которых состоят все современные файловые системы. А как для блоков пересчитывать хеши?? Нет, сам счет все легко, считаем для 4096 байт, записываем в базу данных. А правильно ли в принципе пересчитывать блоки?? Каковая вероятность, что блоки будут одинаковые?? Ну допускаю, что у одинаковых файлов будут одинаковые блоки. А у разных?? Или почти разных?? В общем, надеюсь я Вас убедил, что не выглядит здравой идея считать хеши, лишь для того, чтобы экономить операции записи для очень-очень-очень малой части файлов из всей общей кучи файлов. |
| Автор: Славян 18.09.18, 14:52 |
| Раз так, то постараюсь тоже зайти с несколько боковой стороны: 1. Смотрите, пусть люди хотят сравнить картинки. Алгоритм может быстро пробежаться по файлам, посмотреть размеры картинок и выдать "не равны", если уже размеры разные. И вот тут размеры - и есть контрольная сумма, пусть и слабенькая. 2. А если ОС ставит всякие драйверы, файлы нужные для чего-то, то ей не надо было бы вскрывать файл, запись, ещё что, она бы просто сверилась с контрольной суммой и сказала: "у вас вот это установлено, а вот этого нету". И, храня такую базу MD5/иное, можно было бы в самые неожиданные моменты всюду быстро бегать, ориентироваться, а не искать "есть ли на диске такой-то файл?". Просто с записью файла пишем его КС в общий архивчик и поиск файлов будет крайне быстрым (не по названию, конечно, но всё равно). Суть, ещё раз, в том, что мы с блоком данных (большим!) храним маленькое существенное качество, кое (в некоторые неожиданные моменты) нам резко может помочь. |
| Автор: ^D^ima 24.09.18, 12:22 |
| Существует маленькая вероятность что если 2 одинаковых файла имеют одинаковый размер, дату изменения и имя то они будут различны по содержанию. |
| Автор: ЫукпШ 29.09.18, 16:46 |
| Цитата Славян @ Раз так, то постараюсь тоже зайти с несколько боковой стороны: 1. Смотрите, пусть люди хотят сравнить картинки. Алгоритм может быстро пробежаться по файлам, посмотреть размеры картинок и выдать "не равны", если уже размеры разные. Тогда давайте запустим процедуру сравнения файлов. И, скорее всего, окажется, что по-байтное сравнение быстрее, чем расчёт хеша. А если сравнивать не понадобится, а мы считаем это хеш для всех файлов.. --- Кстати, из чего следует, что не будет "коллизий" ? Файлы разные, а хеши одинаковые, и что тогда ? |
| Автор: Славян 29.09.18, 17:53 |
| Цитата ЫукпШ @ Так конечно быстрее! Но суть же в том, что хэши считаются всегда и в фоновом, а проверки нужны редко. И в эти редкие случаи будут "выстреливать" "на ура" случаи совпадения!И, скорее всего, окажется, что по-байтное сравнение быстрее, чем расчёт хеша. А если сравнивать не понадобится, а мы считаем это хеш для всех файлов.. Не следует. Сие - проблема. Тут надо додумать на каких вариантах будем пренебрегать, а когда важно. Т.е., скажем, если человек песенку сравнил и в ней коллизия, то проиграем ложную, а от него пусть придёт отчёт, что коллизия и надо почётче. А если не пришло, то наверное коллизия ушла в шумы и чёрт с ней. А вот если там какой-то важный системный файл, то можно и тщательнее смотреть. Одним словом, додумать надо детали.  |
| Автор: amk 30.09.18, 15:14 |
| Сравнение хэшей помогает, если файлов больше 2, и только если они не все одинаковые, иначе в конце концов их все равно придётся сравнивать. Или если проверяется изменение файла. Тогда можно хранить старую копию на медленном носителе, и вообще не читать его, если хэш отличается. В случае длинного хэша можно даже пренебречь малой вероятностью коллизии хэшей при изменении. Если надо сравнить несколько файлов между собой, их, в принципе, можно сравнить кусками за один проход чтения. По времени это может оказаться сравнимым с вычислением хэшей, и последующим сравнением этих кэшей, если хэши окажутся разными. Если хотя бы пара хэшей совпадут, придётся ещё раз перечитать соответствующие файлы, и вариант с хэшами окажется медленнее. |