>>211517
Total Commander

robocopy под оффтопиком, rsync.

>>211519
Так ведь Total Commander перебивает даты, или как-то можно?

>>211528
Explorer с ntfs на ntfs не перебивает точно.

>>211517
При помощи UltraISO под маздаем или dd в никсах рипаешь образ харда с древней файлопомойки и прожигаешь его на новый хард.
Для рипа у тебя должно быть столько свободного места на харде твоего компа, на сколько гигабайт создан раздел/сам хард, если их более одного, а для прожига хард должен быть объём более, чем рипнутый образ.

>>211528

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

>>211528

Не знаю, откуда взялась идея «Total Commander перебивает даты». Всегда при копировании копируется и дата файла, а не то простые программы защиты от копирования были бы ещё проще (им достаточно было бы проверять дату).

>>211517
Я предлагаю Акронис

True Image или Disk Director --- выбирай сам

тест

В общем в итоге я диск с древней файловой помойкой клонировал Акронисом.
Был ещё второй с торрентами его я перенёс FreeFileSync.
Total Commander почему-то всё равно перебивает даты.

>>211615

>Акронисом

Какой конкретно утилитой? У него их много и почти все так или иначе с диском работают.

>>211618
Acronis True Image, инструмент клонирование диска.

>>211517
https://www.howtoforge.com/tutorial/linux-dd-command-clone-disk-practical-example/

По треду видно. Как всегда у сидящих на альтернативной ОС нужны костыли и велосипеды.

>>211623
Философия виндоус, если я не ошибаюсь, долгое время заключалась в том, что весь стандартный софт включая даже шел, нужно будет заменить на сторонние продукты. Впрочем, сейчас уже не то время чтобы спорить какая OS лучше. Как по мне все они превратились примерно в одинаковые горы индусского добра, подпёртые палками чтоб не развалились под собственной тяжестью.

>>211517
Из-под линукса, можно с liveCD, под рутом:
cat /dev/sda > /dev/sdb
И потом
sync
Не забудь указать правильные имена дисков и трижды перепроверь.
Потом поставь диск в систему и по вкусу расширь раздел на новом диске штатными графическими средствами ос, если новый диск больше старого.

>>211632
dd if=/dev/sda of=/dev/sdb bs=16MiB status=progress все-таки будет правильнее использовать. Либо даже ddrescue, если есть желание иметь возможность записать лог, прервать и продолжит копирование.
Оно и быстрее, и надежнее. cat по своей природе предназначен больше для обработки текстовых файлов.

Но еще стоит внимание обратить на то, что в таком случае копируется не один раздел, а весь диск и если на диске используется таблица типа GPT, то будут проблемы, если размер дисков отличается, так как у GPT есть вторая таблица в конце диска. Для GPT после копирования на больший диск нужно сделать sgdisk --move-second-header.

Ну, и конечно стоит понимать, что если в файловой системе есть свободное место, то даже для переноса всей файловой системы может быть значительно эффективнее использовать утилиты вроде ntfsclone, btrfs replace, partclone и так далее.

Воспользуюсь данным тредом в своих корыстных нуждах.
Посоветуйте хорошую программу-дефрагментатор под современные операционные системы. В том числе linux и win10-11. Умеющую в предотвращение фрагментации как реальную технологию, а не форму словоблудия и маркетинговых ход. Будет хорошо если она умеет дефрагментировать диск полностью и не затрачивать на это по нескольку суток к ряду. Так же крайне желательно не использующую при всём вышеперечисленном для перемещения файлов win-API.
А то из всего что попадалось, современные софтины только и умеют что перезаписывать диск заново. В лучшем случае сортируя при этом файлы. На этом фоне стандартные дефрагментаторы выглядят не так уж плохо.

>>214470

> умеет дефрагментировать диск полностью

Тут только загрузившись с Live CD / USB, а в противном случае не получится дефрагментировать системные некоторые файлы.

> дефрагментировать диск полностью
> и не затрачивать на это по нескольку суток к ряду

Тут от самого железа зависит — объёма харда и скорости чтения / записи.

> А то из всего что попадалось, современные софтины только и умеют что перезаписывать диск заново. В лучшем случае сортируя при этом файлы. На этом фоне стандартные дефрагментаторы выглядят не так уж плохо.

Эм… Дефрагментация же и есть просто упорядоченная перезапись файлов.

>>214470
Зачем это вообще нужно на современных дисках? Ощутимый прирост получишь только в очень специфичных случаях. Для мерзкой NTFS хватит дефрагментации MFT, для нормальных CoW - вообще не надо дергаться.

Скорее наоборот проблем огребешь с черепицей. У тебя же не дорогой серверный диск?

>>214472
Старые программы умели. Перезагружаться в windows надо было только для системного диска. Всё быстро и качественно. Теперь либо одно, либо другое. А чаще ничего из этого и дополнительные проблемы в качестве бонуса.

>Тут от самого железа зависит — объёма харда и скорости чтения / записи.

Бесспорно. Только там где одни программы справляются за часы, другие тратят дни. А третьи до полумесяца мурыжат своими глупыми алгоритмами не в силах справится.
>>214473
Особенно для SSD. И если у кого линукс с малочувствительной к фрагментации файловой системой, то наверное будут проблемы важнее фрагментации. Но если у тебя жёсткий диск с моделью использования предполагающей высокую фрагментацию, то для того же для чего и раньше. Только тогда были программы эффективно борющиеся с фрагментацией, а сегодня то что стоит по умолчанию в OS и правда не имеет смысла менять на сторонние продукты. Будет только хуже. Лучше уж тогда прикупить внешний диск и гонять файлы туда-обратно вместо дефрагментации. По скорости выйдет так же, а проблем на порядок меньше.

>>214474

> Только там где одни программы справляются за часы, другие тратят дни.

Стандартная утилита из Windows справляется с дефрагментацией диска на пол терабайта за 3–4 часа, а иногда и меньше, при совершении этого процесса раз в два месяца.

> Лучше уж тогда прикупить внешний диск и гонять файлы туда-обратно вместо дефрагментации
> а проблем на порядок меньше

Внешние жёсткие диски обычно сильно греются при длительной работе.

>>214475
И как это противоречит?

>сегодня то что стоит по умолчанию в OS и правда не имеет смысла менять на сторонние продукты

Правда не потому что они такие хорошие, а из-за качества альтернатив.

>>214476

> Правда не потому что они такие хорошие, а из-за качества альтернатив.

Always has been. В сторонних дефрагментаторах никогда не было смысла, ибо стандартного dfr.exe вполне достаточно для своих задач, если рассматривать Windows, конечно.

>>214477
Для предотвращения критического уровня фрагментации,как и сейчас. Никогда не забуду как был вынужден по 10 раз на дню запускать эту прогу. Иначе к концу суток компьютер входил в хронический свап, из которого уже не выходил. Сравнивать этот обрезанный под самый корень зародыш Diskeeper с полноценными поздними версиями или хотя бы Speed Disk (который не использовал ущербные по своей природе дефрагментационные win-API) мог только тот, кто никогда не сравнивал.

>>214479
Ох не думал я что ещё доживу до обсуждения дефрагментаторов и того, нужны ли программы, не использующие defragAPI (или как оно там зовётся). Я думал, это всё закончилось со временами WinXP.

>>214480
Закончится оно только с тотальным переходом на накопители со свободным доступом к произвольным ячейкам памяти. Например SSD. Или изобретением стабильных файловых систем не подверженных фрагментации. Скорее первое.
По большому счёту проблема никуда не исчезала с начала времён, просто для повседневного использования всегда хватало стандартного дефрагментатора. А кому не хватало - те были извращенцами. Богатые извращенцы могли себе позволить решить данную проблему даже не афишируя её наличие.

>>214481

> Или изобретением стабильных файловых систем не подверженных фрагментации.

Достаточно вылезти из windows-мирка - и все становится радужно. Почти.

>>214482
Тогда бы не пришлось искать дефрагментаторы на линукс.

>Почти.

Вот из-за этого "почти" многие и не торопятся. Радужно всё только в разделе "преимущества". Для кого-то такой выбор в силу обстоятельств оправдан, для кого-то нет.

>>214481

> Закончится оно только с тотальным переходом на накопители со свободным доступом к произвольным ячейкам памяти. Например SSD. Или изобретением стабильных файловых систем не подверженных фрагментации. Скорее первое.

SMR-механика тоже не слишком позитивно относится к дефрагментации, CMR уже исчез в 2.5" формфакторе, а дефрагментация многотерабайтной файлопомойки выглядит довольно сомнительным занятием. Дефрагментация морально устарела как явление 5 лет назад.

>>214511
Она изначально была свистелкой для бедный. Любой кто мог себе позволить дополнительные носители ею не пользовался от слова совсем. Нет, у них тоже своего рода программы для предотвращения и ликвидации фрагментации, только работают они иначе. Однако это не означает что дефрагментация и дефрагментаторы не нужны. Не нужно только то что есть на выбор. А другого не завезли.

А можно поподробнее где можно почитать про автодефрагментацию SMR и их преждевременный выход из строя от сторонней дефрагментации? А то то что удалось нагуглить было либо вольными рассуждениями на тему теоретических познаний, либо частным опытом эксплуатации конкретных неудачных моделей конкретного производителя. Проще говоря причинно-следственная связь там не доказывалась. Насколько мне известно, на данный момент имеются различные механизмы компенсации главного недостатка SMR, от особенностей реализации которых и возникают разнообразные побочные эффекты. Речь, надо полагать, идёт о тех которые можно условно объединить под терминами "буфер", "HD-trim" и "перезапись блоками". И насколько мне известно, они не могут влиять на структуру данных, а их влияние на физическое расположение минимально и зачастую временно. Хотя опять же, различия в реализациях не позволяет строго этого утверждать. Поэтому хотелось бы конкретной проверенной информации.

>>214516
Про специальную "автодефрагментацию" SMR слышу в первый раз. Скорее всего ты смешал в кучу собственно дефрагментацию и процесс записи на SMR - когда диск для дозаписи данных читает целый большой блок, а потом заново его пишет в новое место. Что процесс дефрагментации определенно напоминает.

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

Господа, простите великодушно мне резкое заявление. Однако, SMR — рак.

>>214520
Вот и я немного удивлён. Не понимаю как "дефрагментация" блоков (лент) способствует дефрагментации их содержимого. Поэтому и прошу уточнить. Выше утверждалось что якобы современные диски не чувствительны к фрагментации по этой причине. Сам я подобного не утверждал.
Речь шла предположительно о реализации, при которой модифицированный блок (лента) временно перезаписывается в соседнюю пустую ячейку (ленту), старая не меняясь помечается для внутренней логики как содержащая одни нули (пустая), а позднее всё возвращается на место. Некоторые называют это разными словами содержащими слово "дефрагментация" (автодефрагментация, внутренняя дефрагментация, логическая дефрагментация, SMR-дефрагментация, HD-trim, итд). Так же существует миф, что данные в буфере (иногда уточняется, что в силу естественных причин) дефрагментируются, прежде чем быть записанными на SMR-область. Думаю стоит отдельно уточнить, что в ряде случаев пресловутый буфер всего лишь CMR-зазоры между лентами.

>>214521
Само по себе уплотнение не является злом. Даже с учётом теоретического сокращения времени хранения хранения информации на полке в шкафу. И даже ряд вызванных им на сегодняшний день проблем можно считать за компромисс и сырость технологии. Плохо то что такие диски при явном существенном отличии внутренней логики пытаются маскироваться под обыкновенные. Что не даёт стороннему софту, включая файловые системы и OS, вести себя с ними подобающим образом. Это примерно как если бы магнитные ленты маскировались под SSD.
С другой стороны, разработчики совершенно справедливо исходили из постулата "всё сейчас кодится через известное место, а нам лучше знать как лучше оптимизировать наше железо" и почти всегда в этом правы.

>>214523
Ровно в такой формулировке - не утверждалось. Утверждалось, что сама проблема фрагментации сейчас не так актуальна, как лет 20 назад. Диски стали достаточно быстрыми и умными, файловые системы не отстают (горячий привет NTFS, хе-хе).

К тому же, место HDD в задачах, включающих в себя много случайного чтения-записи, заняли SSD. В линейном же режиме выигрыш от дефрага всегда был небольшим.
Дефрагментировать десятки часов многотеррабайтную помойку ради выигрыша в пару MBPS удовольствие сомнительное.

>при которой модифицированный блок (лента)

окончательно

>перезаписывается в соседнюю пустую ячейку (ленту), старая не меняясь помечается для внутренней логики как содержащая одни нули (пустая), а позднее

на нее записывается новый блок данных. Именно так SMR и работает.

Склонен считать, что эти "некоторые" натянули сову на глобус.

>данные в буфере (иногда уточняется, что в силу естественных причин) дефрагментируются

Данные в буфере не обрабатываются, иначе это не буфер.

>>214526
Если бы оно так и работало, то спустя некоторое время все бы диски начинали виснуть на элементарных файловых операциях как сагейт. Однако у других производителей хватило ума не создавать ещё один источник безграничной фрагментации физического расположения данных на поверхности. Да, реальное расположение данных отличается от виртуальной картины тома которую диск отдаёт наружу, однако в свободное время блоки возвращаются на место. Эту процедуру несведующие и путают с автоматической дефрагментацией данных.

>Дефрагментировать десятки часов многотеррабайтную помойку ради выигрыша в пару MBPS удовольствие сомнительное.

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

>Данные в буфере не обрабатываются, иначе это не буфер.

Ну вот они не понимают, что там уже не правила файловой системы действуют, а контроллер диска работает с разметкой как с RAW-датой. Думают файлы последовательно считываются как при переносе с диска на диск.

>Диски стали достаточно быстрыми

В основном за счёт техпроцесса. Раньше вся пластина целиком была 1мб, а сейчас он считывается за миллисекунды пролетания головки. Если измерять скорость чтения и записи диска целиком, не слишком то и пошустрели.

>файловые системы не отстают

Ой, давай не будем. Ты правда хочешь раскрыть тему того что у каждой из них под капотом? За счёт чего обходят старичков и какие хронические болезни сами имеют? Гордится поросшей плесенью NTFS можно только как недоразграбленым наследием CCСР, но и унижать её не стоит. Унижай микрософт. Если возьмётся тырить ребрендить другую FS сделает с ней тоже самое.

А что произойдет, если у SMR-диска, натужно в "свободное" время разгребающего записанное (ведь ОС уже полагает, что операция записи полностью завершилась), внезапно пропадёт питание?

>>214532
Data loss с неплохой вероятностью.

И это источник отдельной боли ниже спины.

>>214537
Не будет никакой потери данных.

Контроллер SMR диска по умолчанию пишет в быстрый не-SMR буфер размером несколько десятков гигабайт. Когда место в буфере кончается, контроллер вынужден начинать писать непосредственно в SMR. Это в целом тоже не проблема, пока есть полностью свободные зоны. А когда свободные зоны с кэшем кончаются и диску надо переписывать уже имеющиеся данные, начинается веселье вида последовательной записи со скоростью в 1-2МБ/с. По крайней мере, так себя ведут сигейты.

>>214540
У сигейтов ужасная проблема с физической фрагментацией, которая не лечится даже форматированием. Реальное местоположение лент всё больше отличается от виртуальной картины тома и в определённый момент начинает напоминать расположение данных на SSD. И они никак не борются с этим, в отличии от конкурентов. Во всяком случае до недавнего времени так было.

Тут недавно произошла приинтереснейшая ситуация. Потребовалось временно скопировать на SSD довольно крупный файл (примерно 60% от свободного места). Соответствующий объём был откушан почти моментально, после чего процесс завис где-то на 30% на скорости 7мб\с, постепенно продолжая откушивать дальше, пока не скушал всё. Вот теперь сижу, думаю что это было. Раньше ничего подобного не было. Правда и файлы такого объёма на SSD не помещались. Логично было бы провести проверку с искусственно созданными файлами разного размера и пройтись по логам, но очевидно что проще начать философствовать на ычане.

>>214540
Нет, будет. При перемещении данных из кеша на постоянное место хранения при условии закончившегося кеша и записи на дальние области пластин. Запаса питания на дозапись и парковку может не хватить, поскольку число элементарных операций значительно больше, чем в CMR.

>>214546

>При перемещении данных из кеша на постоянное место хранения

Невозможно переместить данные из кэша. Можно их прочитать в буферную память, прочитать туда же содержимое зоны SMR куда они должны быть записаны, произвести перезапись зоны теми данными что лежат в буфере, обновить таблицу местоположения блоков, и только после этого можно будет перезаписать данные в кэше чем-нибудь другим.

>>214540>>214546
Мне кажется, тут многое зависит от реализации конкретного производителя. Никто не мешает использовать одну из устоявшихся схем перемещения через копирование, когда последней операцией снимается метка с записанного блока данных и помечается как пустой старый. Что впрочем не означает, что не будет выбран самый простой или самый быстрый способ.

>>214543
Причина, внезапно, оказалась в крайне сильной фрагментации SSD. Причём виндовый дефрагментатор, перезагрузка и trim не помогли. Только сторонний дефрагментатор, который пол часа лопатил SSD. После чего объём отображаемого свободного места разительно увеличился, а проблема с пропаданием оного вникуда при записи файлов сверхбольшого объёма более не повторялась.