Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.240.142] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
// пардон, если тема не сюда, но куда точнее не нашёл.
Скажите, а есть ли такие файловые системы (ФС) (или можно ли дособирать ФС), чтобы она автоматом (или в фоне во время безделья) считала какую-нибудь контрольную сумму (КС) всякого файла (каталога?) и хранила её в файловой записи/альтерн.потоке, дабы сравнение файлов шло в мгновение? И при копировании (перезаписи) она бы автоматом не копировала файлы с одинаковой КС (ну, накрайняк, спрашивала), ещё где-то использовала это полезное свойство?! |
Сообщ.
#2
,
|
|
|
Славян, это не относится к функциям файловой системы. Виндовс, к примеру, имеет службу индексирования для ускорения поиска. Поэтому приемлимый вариант - писать демона, который в фоне пересчитывает контрольные суммы файлов и пишет их в альтернативные потоки. Естественно, нужно реализовать два функционала:
1) Пересчет файлов в фоне, у которых не прописана контрольная сумма 2) Слежение и пересчет контрольных сумм изменившихся файлов Но ... Альтернативными потоками может пользоваться не только твоя прога. А это черевато. |
Сообщ.
#3
,
|
|
|
Хм-м... просто если бы это провернуть даже как-то аппаратно (ЖД получает блок в 4Кб (или сколько-то) и КС), то мож и запись физическая на винт многократно ускорилась бы, не делая ненужных перезаписей одного и того же.
Впрочем, мысль "относится ли сие к ФС или нет" - мне видится крайне непонятной, Joe. |
Сообщ.
#4
,
|
|
|
Сообщ.
#5
,
|
|
|
А при чём тут поиск? Устройство получает блок и КС, сверяется с записанным блоком и КС, и (при равных КС) забивает на запись. Явно ж быстрее будет!!
|
Сообщ.
#6
,
|
|
|
А ... т.е. ты хотел это реализовать на "плоских" ФС, а-ля FAT, NTFS, HPFS? Ну может быть для каких-то слишком разряженных данных это бы и прокатило, но для реальной ситуации, "бытовой" - это будет реальный ттттттттттттормоз. Ибо вероятность встретить свободный блок с одинаковым содержимым записываемому - никакущая. Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев.
Добавлено ЗЫ: Вот на ФС, построенных на деревьях, можно было бы поразмышлять... И то, не думаю, что создатели, к примеру, ZFS об этом не задумывались. |
Сообщ.
#7
,
|
|
|
Цитата JoeUser @ Да, и в этом и есть могущество и мощь Но к каждой операции поиска свободного блока будет добавляться операции чтения CRC + записи нового CRC. И это будет в стопицот процентов случаев. |
Сообщ.
#8
,
|
|
|
Цитата Славян @ Т.е. вы тратите в каждый чих ещё толику чтений-сравнений Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD И толика она - в результате не такая уже толика. Короч, твое предложение, чисто ИМХО, включить в ФС - функционал лотереи "Спортлото" |
Сообщ.
#9
,
|
|
|
Цитата JoeUser @ Ну пусть не "в чих", а "на каждый шаг", не суть. Да, это преждевременный износ, но это как у вас бы из каждого дня выкрадывали секунду/атом, а спустя годы предъявили бы зато для человечества нового ребёнка/год жизни! Т.е. обираем по чуть-чуть, но в крупном это станет сильно=качественно заметно.Это не чих! Это преждевременный износ устройства позиционирования считывающих головок HDD Короче, мне не видно, отчего вам не нравится сей метод. Никак не вижу. |
Сообщ.
#10
,
|
|
|
Цитата Славян @ Короче, мне не видно, отчего вам не нравится сей метод. Никак не вижу. Статистика, батенька, пугает! Крадем беспощЯдно секунды постоянно ... а потом бац, в следующем тысячелетии ... спрогнозировали, что в ближайшее тысячелетии таки осилим, таки найдем заветный блок. |
Сообщ.
#11
,
|
|
|
беспощадно по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость! Сила!
|
Сообщ.
#12
,
|
|
|
Не знаю как до тебя достучаться .... 1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не?
|
Сообщ.
#13
,
|
|
|
Цитата JoeUser @ Да, разница огромна! Но я тоже не знаю как до вас "достучаться":1* 1 000 000 000 (почти всегда) и 4096 * 1 (иногда) - есть разница? Не? Цитата Славян @ по чуть-чуть = незаметно, а вот кому попадётся заветный блок - сразу прочухает скорость! |
Сообщ.
#14
,
|
|
|
Цитата Славян @ Да, разница огромна! Но я тоже не знаю как до вас "достучаться": Прежде чем реализовывать данную фичу на уровне файловой системы, можно попробовать прикинуть реальную ее пользу достаточно простым способом. Предположим есть какая-то файловая система (реальная, гигабайт на 500). Берем для этого какой-нибудь свой раздел с документами, музыкой, фильмами и т.п. Прежположим там будет файлов, ну скажем 200000. Создаем простую базу данных хоть в mysql, хоть в postgresql, хоть sqlite, хоть.... куда в одну табличку записываем полное имя файла с абсолютным путем и считаем его хеш (например, на питоне можно написать такой скрипт). Просматриваем все 200000 файлов, считаем для каждого хеш, записываем все в базу данных. Получилась как бы некая левая файловая система, в которой записаны все файлы и хеши для каждого файла. По окончанию записи берем и спрашиваем у "файловой системы --- базы данных", а сколько у нас получилось одинаковых хешей?? Без преувеличения полагаю, ну 1, ну 2... ну максимум 5 ) Об этом и говорят, что по сравнению с общей кучей в 500 гигабайт и 200000 файлов, тратить такие усилия на уровне файловой системы для 1-5 файлов, НУ КРАЙНЕ нерационально и никакого выигрыша это не даст, разве что при обращении к этим файлам. Хорошо, пусть "одинаковых" файлов будет не 5, а 500... ну хрен с ним 5000 (я слабо себе представляю зачем это мне?? и как я до этого докатился??). Можно очень долго заниматься оптимизацией баз данных, но сама по себе операция поиска одинакового хеша среди 200000 записей является весьма затратной процедурой: Надо поддерживать как-то доп. индекс, его пересчитывать, пересортировывать, чтобы поиск занимал тысяные доли секунды и меньше. На мой взгляд опять целесообразность таких затрат является сомнительной. Хорошо, пусть не одинаковые файлы, спустимся на уровень блоков файловой системы, из которых состоят все современные файловые системы. А как для блоков пересчитывать хеши?? Нет, сам счет все легко, считаем для 4096 байт, записываем в базу данных. А правильно ли в принципе пересчитывать блоки?? Каковая вероятность, что блоки будут одинаковые?? Ну допускаю, что у одинаковых файлов будут одинаковые блоки. А у разных?? Или почти разных?? В общем, надеюсь я Вас убедил, что не выглядит здравой идея считать хеши, лишь для того, чтобы экономить операции записи для очень-очень-очень малой части файлов из всей общей кучи файлов. |
Сообщ.
#15
,
|
|
|
Раз так, то постараюсь тоже зайти с несколько боковой стороны:
1. Смотрите, пусть люди хотят сравнить картинки. Алгоритм может быстро пробежаться по файлам, посмотреть размеры картинок и выдать "не равны", если уже размеры разные. И вот тут размеры - и есть контрольная сумма, пусть и слабенькая. 2. А если ОС ставит всякие драйверы, файлы нужные для чего-то, то ей не надо было бы вскрывать файл, запись, ещё что, она бы просто сверилась с контрольной суммой и сказала: "у вас вот это установлено, а вот этого нету". И, храня такую базу MD5/иное, можно было бы в самые неожиданные моменты всюду быстро бегать, ориентироваться, а не искать "есть ли на диске такой-то файл?". Просто с записью файла пишем его КС в общий архивчик и поиск файлов будет крайне быстрым (не по названию, конечно, но всё равно). Суть, ещё раз, в том, что мы с блоком данных (большим!) храним маленькое существенное качество, кое (в некоторые неожиданные моменты) нам резко может помочь. |