Копирпование директории и файлов & Дефрагментация

[algri14]

При переносе данных с одного диска на другой скопировал директорию "/mnt/audiovideo/Видео" с папками и файлами из-под Dolphin'а, за 5 лет много чего накопилось. Вопрос вот в чём, почему скопированная директория в /run/media/algri/audiovideo1/Видео1/ имеет меньший размер 183Гб, в отличии от родной 297Гб:

Spoiler

Shell

[algri@localhost ~]$ df -h /mnt/audiovideo/Видео/
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sda9 313G 297G 581M 100% /mnt/audiovideo

[algri@localhost ~]$ df -h /run/media/algri/audiovideo1/Видео1/
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sdb7 306G 183G 108G 64% /run/media/algri/audiovideo1

При этом количество файлов и папок совпадают:

Spoiler

Shell

[algri@localhost Видео]$ cd /mnt/audiovideo/AudioVideo/Видео
[algri@localhost Видео]$ ls -l | grep "^-" | wc
1147 18653 137066
[algri@localhost Видео1]$ ^C
[algri@localhost Видео1]$ cd /run/media/algri/audiovideo1/Видео1
[algri@localhost Видео1]$ ls -l | grep "^-" | wc
1147 18653 137066

Вот и гадаю - фрагментация или бед-блоки виноваты, хотя есть 2 исошника подозрительные, два раза прогнал на предмет дефрагментации e4defrag -c /dev/sda9 , на беды проверил, а результат тот же:

Spoiler

Shell

[root@localhost algri]# e4defrag -c /dev/sda9
<Fragmented files> now/best size/ext
1. /mnt/audiovideo/AudioVideo/Документы/Obrasy_iso/MagOS_Rosa/MagOS_2014.64_20171127.tar.gz
693/1 1793 KB
5. /mnt/audiovideo/AudioVideo/Документы/Obrasy_iso/EduMagic.iso
519/3 8470 KB

Да, похоже надо со старого всё скопировать и заново разметить

[Vascom]

Размер директории надо смотреть не через df, а через du!

[Hephaestus]

Вопрос вот в чём, почему скопированная директория в /run/media/algri/audiovideo1/Видео1/ имеет меньший размер 183Гб, в отличии от родной 297Гб:

Как уже сказали, Вы не те размеры сравниваете.
У Вас выводится размер всего раздела, а не только каталога с видео.

Вот, например:

Shell

df -h /tmp/video
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
tmpfs 2,0G 301M 1,8G 15% /tmp

Shell

$ df -h /tmp/audio
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
tmpfs 2,0G 301M 1,8G 15% /tmp

По этой логике получается, что каталоги video и audio имеют одинаковый размер - 301М
Хотя на самом деле 301M - это размер файлов во всем /tmp

Shell

$ du -sh /tmp
301M /tmp

А video и audio

Shell

$du -sh /tmp/video
100M /tmp/video

Shell

$du -sh /tmp/audio
200M /tmp/audio

При этом количество файлов и папок совпадают

При копировании файлов полезно ещё контрольные суммы проверять.
Особенно, имея дело с внешними носителями, вроде всяких флешек/карт памяти.

[serzh-z]

При копировании файлов полезно ещё контрольные суммы проверять.

Все чаще начинаю задумываться о битроте, при использовании ФС без контрольных сумм. Может есть какие-то удобные средства контроля/проверки большого количества файлов?

[Kido]

При копировании файлов полезно ещё контрольные суммы проверять.

Все чаще начинаю задумываться о битроте, при использовании ФС без контрольных сумм. Может есть какие-то удобные средства контроля/проверки большого количества файлов?

Если имеется ввиду проверка при копировании/перемещении, то rsycn --checksum --ignore-times подойдет.

[Hephaestus]

serzh-z
Битрот - это вот это?

Может есть какие-то удобные средства контроля/проверки большого количества файлов?

Ну, собственно, контрольные суммы и есть. А как ещё?
Чтобы убедиться в целостности файла, его нужно с чем-то сравнивать.
Если в случае текстов ещё можно что-то там проверять визуально, то в случае бинарных данных - только хеш.
Помнится, для CD были какие-то инструменты "контроля за старением носителя". С нового диска снимались какие-то показатели, сохранялись в базу, потом спустя время можно было сверить. Я сам этим ни разу не пользовался, знаю только в общих чертах - по описанию. Но там вроде бы, какие-то хеши - опять-таки.
Так что, насколько я знаю, хеш - это единственный универсальный (подходит для любых данных), экономный (хеш занимает мало места по сравнению с самим файлом) и довольно быстрый (визуальный просмотр будет значительно дольше) способ убедиться в идентичности данных. При условии, что алгоритм достаточно надежный.

[serzh-z]

Если имеется ввиду проверка при копировании/перемещении

Нет. Проверка архива. Скажем, утилита сканирует большой набор файлов и сохраняет отдельно базу хешей, а спустя год хотелось бы натравить эту утилиту на тот же набор файлов и заставить ее проверить все в соответствии с базой.

[serzh-z]

Ну, собственно, контрольные суммы и есть.

Я про готовый удобный инструмент.

[Hephaestus]

Скажем, утилита сканирует большой набор файлов и сохраняет отдельно базу хешей, а спустя год хотелось бы натравить эту утилиту на тот же набор файлов и заставить ее проверить все в соответствии с базой.

И в чем проблема?
find -type f -exec md5sum -b '{}' \; >/tmp/files.md5 посчитает хеши для файлов рекурсивно по каталогам и сохранит в файл.
В дальнейшем, md5sum -c files.md5 проверит контрольные суммы (также по всем каталогам).
Не мне Вам рассказывать, Вы это лучше меня знаете.
Если же говорить о том, насколько это быстро, то на мой взгляд - достаточно быстро (принимая во внимание объемы данных, которые проверяются). А вообще, это зависит от скорости железок.
А запихивать этот функционал в какую-то утилиту/оболочку... Можно, конечно, но зачем?
Кроме данных, файла с суммами и самой утилиты ничего не нужно. А если хранить в базе, то ещё придется беспокоиться о целостности этой базы.
По-моему, в данном случае, чем проще, тем лучше.

[algri14]

Всем спасибо народ! много поучительного узнал, особенно про:

Битрот - это вот это?

Все чаще начинаю задумываться о битроте, при использовании ФС без контрольных сумм.

А это как - использовать ФС с контрольными суммами? Использовать Btrfs или ReFS?

[Hephaestus]

Я про готовый удобный инструмент.

Ну, вот было ещё такое обсуждение:

Системы управления версиями. Например, git. У меня весь домашний каталог под его управлением находится. В итоге (в частности) всегда есть возможность вернуться (временно) к любой отмеченной ранее версии любого файла; в том числе и .bash_history. Я в ближайшее время планирую написать именно о применении СУВ «в мирных целях». Если интересует, дам в этой теме ссылку, когда будет готово.

В целом, идея мне понравилась, но уж больно расточительно в смысле дискового пространства.
Фактически каждый файл хранится дважды: на своем обычном месте и в "базе" git. Но если это не критично, то вполне можно. Особенно, если файлы со временем не меняются.
С другой стороны, git с большими файлами дружит не очень (позднее появилась какая-то модификация именно для больших файлов), а для бинарных, можно сказать, не подходит.
Но опять-таки, если говорить лишь о задаче "засечь изменения", то есть обнаружить сам факт того, что файлы изменились - git вполне сгодится. И даже, наверно, быстро будет работать.

Offtopic

Тихон давно на форуме не был. Жив ли он? Кто-нибудь знает?

[serzh-z]

Использовать Btrfs или ReFS?

Да. Или ZFS.