Sd card testing linux

Как я могу проверить полную емкость SD-карты в Linux?

Я купил карту SD на 64 ГБ у eBay. Он отлично работает, когда я записываю образ Arch Linux ARM и использую его для загрузки моего Raspberry Pi.

Однако, когда я пытаюсь создать на нем один раздел ext4 для использования всей емкости карты, возникают ошибки. mkfs.ext4 всегда заканчивается счастливо; однако, раздел не может быть mount отредактирован, всегда выдает ошибку и dmesg показывает сообщения ядра Cannot find journal . Это подтвердилось как минимум на двух платформах: Arch Linux ARM и Ubuntu 13.04.

С другой стороны, я могу создать и смонтировать раздел FAT32 без ошибок (проверка полной емкости не была выполнена).

Я слышал, что некоторые плохие парни могут изменить интерфейс SD-карты, чтобы сообщить о неправильной емкости ОС (т. Е. Карта действительно всего 2 ГБ, но сообщает о себе как 64 ГБ), чтобы продать карту по более выгодной цене.

Я знаю, что подобные инструменты badblocks существуют для меня, чтобы проверить SD-карту на предмет плохих блоков. Может ли badblocks обнаружить такие проблемы? Если нет, то какие еще существуют решения для тестирования карты?

В идеале я хотел бы знать, был ли я обманут или нет; если результат показывает, что я только что получил плохой товар, я могу только вернуться к продавцу, а сообщить в eBay, что кто-то пытался меня обмануть.

ОБНОВИТЬ

операции и сообщения:

ОБНОВИТЬ

Я бежал, badblocks /dev/sde но он не сообщает об ошибке. Это означает, что оставшиеся причины:

SD автомобиль хорош , но по какой — то причине mke2fs или mount или ядра есть ошибка , которая вызывает проблему.

Я был обманут таким образом, badblocks что это не может обнаружить поражение. Это правдоподобно, потому что я думаю, что badblocks просто делает некоторый тест записи-чтения на месте. Однако мошенник может связать доступ к исходящим областям с каким-либо входящим блоком. В этом случае проверка на запись-чтение на месте не может обнаружить проблему.

Если нет приложения, способного выполнить надлежащий тест, я думаю, что я могу попытаться написать простую C-программу для его тестирования.

Источник

Thread: how to test SD read/write speed

Thread Tools

Display

[SOLVED] how to test SD read/write speed

Just got a brand new SD card off ebay, but bought it from a seller in Hong-Kong and when I got it, it wasn’t the same brand as advertised. in fact, it didn’t have any brand at all..

It has a sticker in it saying it is a class 6 device.

How can I test its read/write speed?
Looked all over and found nothing for Linux.

Last edited by macakinho; May 10th, 2009 at 11:36 PM . Reason: [SOLVED]

Re: how to test SD read/write speed

Find out which device it mounts as and run hdparm -t. For instance, if I plug a USB pendrive in it mounts as /dev/sdb:

Re: how to test SD read/write speed

Find out which device it mounts as and run hdparm -t. For instance, if I plug a USB pendrive in it mounts as /dev/sdb:

Thank you!
This only gave me the write speed though. Read the ma hdparm and didn’t find any option to test the write or erase speed.
Any help here?

Re: how to test SD read/write speed

You can use DD to test disk speed, but it can easily lead to damaged data (partitions) if used incorrectly but is probably the most direct way of testing.

So for example my second internal disk is mount /media/HD2 so running this gives me the write speed:

that command writes 1GB to the disk, this large number is because the filesystem on the device will speed up the transfer by caching the data if a small transfer is carried out.

—edit—
This is a VERY dangerous command if you miss-type the output file so obviously take care using it and be sure to type correctly!

Re: how to test SD read/write speed

Thanks! That did it!

I’m really disappointed now.
sticker on SD card: «Class 6»
terminal: «1073741824 bytes (1.1 GB) copied, 212.248 s, 5.1 MB/s»
wikipedia : «Class 4»

Re: how to test SD read/write speed

It could be your card reader/writer that is slower as opposed to the card?

Re: how to test SD read/write speed

humm.. how can I know that?
Will try a different SD card. One I know it’s not class 6 and post tthe results here.

Re: how to test SD read/write speed

On a SD card I though would be way slower:

«1073741824 bytes (1.1 GB) copied, 117.218 s, 9.2 MB/s»

damn it, those cheecky ebayers.

Re: how to test SD read/write speed

If you use that command multiple times, is it normal for the speed to be lower on subsequent runs? The first time I ran it, creating a new file, test.img, I got 110MB/sec,* then each time after I run it, I get just under 50MB/sec. I changed to a different output file name, and the same thing happens, faster the first time at 114MB/s, then slower.

*the 110MB/sec is actually faster than what I get from the hdparm -t command: 90MB/s.

Re: how to test SD read/write speed

You can use DD to test disk speed, but it can easily lead to damaged data (partitions) if used incorrectly but is probably the most direct way of testing.

So for example my second internal disk is mount /media/HD2 so running this gives me the write speed:

that command writes 1GB to the disk, this large number is because the filesystem on the device will speed up the transfer by caching the data if a small transfer is carried out.

—edit—
This is a VERY dangerous command if you miss-type the output file so obviously take care using it and be sure to type correctly!

Thanks for this info, works like a charm,

I played around with the 1k(1000 times) and 1M (1 Mb file) to test my 16 GB SD card.
Keep in mind FAT32 formated card only support single files (thats why the second one gave me a file too large.

Источник

Стресс-тестирование SD-карт с использованием linux

Сегодня я немного рассердился в отношении логики и / или правдивости моего ответа здесь , относительно того, что регистрация и поддержка метаданных fs на достойной (GB +) SD-карте не может быть достаточно значительным, чтобы носить карту в разумные сроки (годы и годы). Суть контр-аргумента, казалось, заключалась в том, что я должен ошибаться, поскольку в Интернете так много историй о том, что люди носили карты SD.

Поскольку у меня есть устройства с SD-картами в них, содержащими корневые файловые системы rw, которые оставлены на 24/7, я раньше проверял помещение до своего собственного удовлетворения. Я немного изменил этот тест, повторил его (используя ту же карточку) и представляю его здесь. У меня два основных вопроса:

1. Является ли метод, который я использовал, чтобы попытаться разрушить карту, жизнеспособную, имея в виду, что она предназначена для воспроизведения эффектов непрерывного переписывания небольших объемов данных?
2. Является ли метод, который я использовал для проверки карты, все еще в порядке?

Я ставил вопрос здесь, а не SO или SuperUser, потому что возражение против первой части, вероятно, должно было бы утверждать, что мой тест на самом деле не писал на карточку, как я уверен, что это так, и утверждая, что это потребует некоторых специальное знание linux.

[Также может быть, что на SD-картах используется некоторая интеллектуальная буферизация или кеш, так что повторная запись в одно и то же место будет буферизоваться / кэшироваться где-то менее подверженной износу. Я не нашел никаких указаний на это, но я прошу об этом на SU]

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

Для очистки оборудования я полагался на вызов библиотеки POSIX fdatasync() :

Я запускал это в течение

8 часов, пока не набрал 2 миллиона + записи в начало раздела /dev/sdb1 . 1 Я мог бы просто легко использовать /dev/sdb (необработанное устройство, а не раздел), но я не вижу, какая разница.

Затем я проверил карту, пытаясь создать и смонтировать файловую систему на /dev/sdb1 . Это сработало, указывая, что конкретный блок, который я писал всю ночь, был осуществим. Однако это не означает, что некоторые регионы карты не были изношены и смещены с помощью выравнивания износа, но остались доступными.

Чтобы проверить это, я использовал badblocks -v -w в разделе. Это деструктивный тест чтения-записи, но уровень износа или нет, это должно быть убедительным доказательством возможности карты, так как оно должно обеспечивать пространство для каждой прокатки. Другими словами, это буквальный эквивалент заполнения карты полностью, а затем проверка того, что все это в порядке. Несколько раз, поскольку я позволяю badblocks работать через несколько шаблонов.

[Комментарий Контра Джейсона С ниже, нет ничего неправильного или ложного об использовании badblocks таким образом. Хотя это было бы не полезно для фактического выявления плохих блоков из-за характера карт SD, это нормально для проведения деструктивных тестов чтения-записи произвольного размера с использованием переключателей -b и -c , в которых пересмотренный тест прошел ( см. мой собственный ответ). Никакое количество магии или кеширование контроллером карты не может привести к ошибке, так как несколько мегабайт данных могут быть записаны на аппаратное обеспечение и правильно вернутся назад. Другие комментарии Джейсона, похоже, основаны на неправильном понимании – ИМО преднамеренным , поэтому я не стал спорить. С этой головой я оставляю это читателю, чтобы решить, что имеет смысл, а что нет .]

1 Карта была старой карточкой Sandisk 4 ГБ (на ней нет номера класса), которую я едва использовал. Еще раз, имейте в виду, что это не 2 миллиона, пишет буквально одно и то же физическое место; из-за выравнивания износа «первый блок» будет постоянно перемещаться контроллером во время испытания, так как термин «состояние» выравнивает износ.

Я думаю, что стресс-тестирование SD-карты в целом проблематично, учитывая 2 вещи:

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

разные технологии (MLC против SLC). Другая проблема, которую я вижу в этом, – это различие в технологиях. SLC типов SSD я ожидал бы гораздо более продолжительный срок жизни по сравнению с разновидностью MLC. Кроме того, на MLC существуют гораздо более жесткие допуски, на которые вам просто не приходится иметь дело с SLC, или, по крайней мере, они более терпимы к неудаче таким образом.

• MLC – многоуровневая ячейка
• SLC – одноуровневая ячейка

Проблема с MLC заключается в том, что данная ячейка может хранить несколько значений, биты, по существу, сложены с использованием напряжения, а не просто являются физическими + 5 В или 0 В, поэтому это может привести к значительному увеличению скорости отказа, чем их SLC эквивалент.

Ожидаемая продолжительность жизни

Я нашел эту ссылку, которая немного рассказывает о том, как долго аппаратное обеспечение может продолжаться. Он называется: Знай свои SSD – SLC и MLC .

SLC ssds можно рассчитывать, по большей части, для того, чтобы жить где-то между 49 и 149 годами, в среднем, по наилучшим оценкам. Тестирование Memoright может подтвердить SSD 128 ГБ, имеющую продолжительность выдержки на запись, превышающую 200 лет, при средней записи 100 Гбит в день.

Именно здесь дизайн mlc падает. Пока еще не выпущено ни одного. Никто действительно не изучил, какая продолжительность жизни гарантирована с помощью mlc, за исключением того, что это будет значительно ниже. Я получил несколько разных убеждений, которые в среднем составляют от 10 до 1 жизни в пользу дизайна slc. Консервативная догадка заключается в том, что большинство оценок продолжительности жизни будет составлять от 7 до 10 лет, в зависимости от продвижения «уровней выравнивания износа» в контроллерах каждого производителя.

Сравнения

Чтобы провести сравнение посредством циклов записи, slc будет иметь срок службы 100 000 полных циклов записи по сравнению с mlc, который имеет продолжительность жизни 10000 циклов записи. Это может значительно увеличиться в зависимости от используемой конструкции «выравнивания износа».

Просто добавив несколько моментов к ответу slm – обратите внимание, что они больше подходят для SSD, чем для «немых» SD-карт, поскольку SSD-файлы играют с вами более грязные трюки (например, дедупликация):

вы пишете 64 КБ в начале устройства – у этого есть две проблемы:

флеш-камеры обычно имеют блоки стирания размером от 16 КБ (более вероятно, в диапазоне 128-512 КБ). Это означает, что ему нужен кеш, по крайней мере, такого размера. Поэтому писать 64 КБ, похоже, недостаточно для меня.

для недорогих (считающихся «не предпринимателями») решений (и я ожидал бы этого еще больше для карт SD / CF, чем для твердотельных накопителей), производители могут выбрать, чтобы начало устройства было более эластичным для ношения, чем остальное, поскольку важные структуры – таблица разделов и FAT на одном разделе на устройстве (большинство карт памяти используют эту настройку) – расположены там. Таким образом, тестирование начала карты может быть предвзятым.

fdatasync() самом деле не гарантирует, что данные будут записаны на физический носитель (хотя, вероятно, он делает все возможное, что находится под контролем ОС) – см. справочную страницу:

Вызов блокируется до тех пор, пока устройство не сообщит, что передача завершена

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

В любом случае, в предположении, что кэш присутствует на карте (см. Мой ответ на ваш вопрос о SU ), запись 64KB и синхронизация (с fdatasync() ), по-видимому, для этой цели не являются достаточно убедительными. Даже без какого-либо «резервного питания» прошивка может по-прежнему играть в нее небезопасно и держать данные неписаными немного дольше, чем можно было бы ожидать (поскольку в типичных случаях использования это не должно создавать никаких проблем).

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

Есть ряд проблем с вашим тестом, некоторые нечеткие, некоторые нет. Это также зависит от вашей цели. Две тонкие, нечеткие проблемы:

• Вы не читаете из той же области, о которой вы пишете, ваш тестовый тест эффективно, затем ничего не делает (если только контроллер не прочитал коррекцию нарушения, и в этом случае он может иногда перемещать страницу, читаемую в другое место, но это все еще делает не влияет на ваш тест).
• Вы предполагаете (и, скорее всего, но не гарантировано), что чтение / запись в плохой блок обнаруживается и сообщается контроллером – вы хотели бы записать данные, прочитать их и сравнить для гарантированной проверки.

Тем не менее, они, возможно, педантичны. Более серьезным является:

• Вы не можете использовать badblocks чтобы показать неудавшиеся страницы во флэш-памяти; все обнаружения сбоев и последующие отображения страниц выполняются контроллером и прозрачны для ОС. Вы можете получить информацию от SMART, если диск поддерживает ее (я не знаю никаких SD-карт, которые ее поддерживают, возможно, есть более дорогие флеш-накопители).
• Уровни износа, осложненные вашим тестом, не принимая во внимание предыдущие команды TRIM, свободное / используемое состояние диска во время теста и зарезервированное пространство.

Уровни износа: основная проблема заключается в том, что выравнивание износа является основной переменной в вашем тесте. Это происходит на контроллере (обычно), и в любом случае его прозрачное даже прямое устройство ищет + чтение / запись. В вашем примере вы фактически не знаете состояние выравнивания износа (в частности, недавно были выпущены команды TRIM для бесплатных блоков?) …

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

Для статического износа (которые, как правило, имеют твердотельные накопители, карты SD, как правило, не имеют, и флэш-накопители меняются): вокруг него практически нет способа, кроме повторного ввода на каждую страницу устройства.

… Другими словами, есть детали для выравнивания износа, которые вы не можете знать и, конечно, не можете контролировать – особенно, используется ли динамическое выравнивание износа, независимо от того, используется ли статическое выравнивание износа или нет. количество свободного места на устройстве для выравнивания износа (которое не видно через контроллер [или драйвер в некоторых случаях, например, M-Systems old DiskOnChip]).

SLC / MLC: что касается SLC и MLC, это имеет очень непосредственное влияние на пределы, которые вы ожидаете увидеть, но общая процедура выравнивания износа и процедура тестирования одинаковы для обоих. Многие поставщики не публикуют, являются ли их устройства SLC или MLC для их более дешевых потребительских продуктов, хотя любой флеш-накопитель, который утверждает, что ограничение скорости 100k + на странице, вероятно, является SLC (упрощенный компромисс – SLC = выносливость, MLC = плотность).

Кэширование. Что касается кэширования, это немного некорректно. На уровне ОС, в общем случае, конечно, fsync / fdatasync не гарантирует, что данные фактически записаны. Тем не менее, я думаю, что можно с уверенностью предположить, что это (или, по крайней мере, контроллер сделал это, т.е. запись не будет проглочена в кеше) в этом случае, поскольку съемные диски, как правило, предназначены для общей схемы использования «Извлечь» (размонтировать> синхронизацию), затем удалить (выключение питания). Хотя мы не знаем наверняка, образованное предположение говорит, что можно с уверенностью предположить, что синхронизация гарантирует, что запись будет абсолютно иметь место, особенно при записи -> sync -> read back (если бы это было не так, то диски были бы ненадежными после извлечения). Нет другой команды, кроме «sync», которая может быть выпущена при извлечении.

На контроллере все возможно, но предположение выше также включает в себя предположение, что контроллер по крайней мере не делает ничего «сложного», чтобы риск потери данных после синхронизации. Можно предположить, что контроллер может, скажем, буферизировать и группировать записи, или не записывать данные, если одни и те же данные переписываются (в ограниченной степени). В приведенной ниже программе мы чередуем два разных блока данных и выполняем синхронизацию перед считыванием, чтобы победить разумный механизм кэширования контроллера. Тем не менее, конечно, нет никаких гарантий и никакого способа узнать, но мы можем сделать разумные предположения, основанные на нормальном использовании этих устройств и нормальных / общих механизмах кэширования.

Тестирование:

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

Первое, что вам нужно сделать, это заполнить всю карточку данными. Это важно и является основной переменной, которая осталась в вашем первоначальном тесте. Это означает, что в качестве используемого блока используется как можно больше блоков, кроме любого зарезервированного пространства (к которому у вас нет доступа). Обратите внимание, что мы работаем со всем устройством (которое будет уничтожать все данные), поскольку работа с одним разделом влияет только на одну конкретную область на устройстве:

Если вы являетесь индикатором выполнения:

Изменить: для карт с блоками стирания 4 МБ попробуйте это для более быстрой записи:

Затем вы можете написать программу тестирования циклов следующим образом, используя O_DIRECT и O_SYNC (и, возможно, параноидальное, избыточное использование fsync() ), чтобы сократить как можно больше буферизации ОС и кэширования изображения, и, теоретически, напишите непосредственно контроллеру и дождитесь, пока сообщение о завершении операции:

Обратите внимание, что для O_DIRECT буферы должны быть соответствующим образом выровнены. Как правило, достаточно 512-байтовых границ. Вы можете скомпилировать:

При необходимости добавьте -D_POSIX_C_SOURCE=200112L .

Затем, после заполнения устройства полностью, как указано выше, просто оставьте его в течение ночи:

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

В настоящее время я тестирую на довольно избитом 4GB PNY флеш-накопителе, который я обнаружил вчера на тротуаре (похоже, это было то, что осталось от http://www3.pny.com/4GB-Micro-Sleek-Attach- -Purple-P2990C418.aspx ).

Вышеупомянутая программа по существу представляет собой ограниченную версию badblocks и вы не увидите сбоев, пока все зарезервированные пространства не будут исчерпаны. Следовательно, ожидание (с 1 страницей, написанной на итерацию), состоит в том, что вышеприведенная процедура, в среднем, должна завершиться неудачей в итерациях зарезервированных_page_count * write_cycle_limit (опять же, выравнивание износа является основной переменной). Это слишком плохие флеш-накопители, и SD-карты обычно не поддерживают SMART, который имеет возможность сообщать зарезервированный размер пространства.

Кстати, fsync vs fdatasync имеет никакого значения для записи блочного устройства, которую вы делаете, для целей этого теста. Важны ваши режимы open() .

Если вам интересно узнать технические подробности; вот все, что вы можете узнать (и многое другое) о внутренней работе SD-карт: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Edit: Bytes vs Pages: В контексте этих типов тестов важно думать о вещах с точки зрения страниц, а не байтов. Это может быть очень ошибочным, чтобы делать обратное. Например, на SDD SanDisk 8GB размер страницы в соответствии с контроллером (доступный через /sys/classes/mmc_host/mmc?/mmc. /preferred_erase_size ) является полным 4 МБ. Написав 16 МБ (выравнивается с границами 4 МБ), затем стирайте / записывайте 4 страницы. Однако, записывая четыре одиночных байта, каждый из которых смещает 4 МБ друг от друга, также стирает / записывает 4 страницы.

Это неточно, а затем сказать: «Я протестировал с записью 16 МБ», так как это то же количество износа, что и «Я тестировал 4 байта». Точнее, «я протестировал с 4 страницами».

Ответ Петерфа заставил меня рассмотреть вопрос о возможном кешировании. После копания я все равно не могу сказать наверняка, делают ли это какие-либо, некоторые или все SD-карты, но я думаю, что это возможно.

Тем не менее, я не считаю, что кэширование будет включать данные, большие, чем блок стирания. Чтобы быть действительно уверенным, я повторил тест, используя кусок размером 16 МБ вместо 64 КБ. Это 1/250-й общий объем платы 4 ГБ. Это заняло

8 часов, чтобы сделать это 10 000 раз. Если выравнивание износа делает все возможное, чтобы распределить нагрузку, это означает, что каждый физический блок использовался бы 40 раз.

Это не так много, но исходная точка теста заключалась в том, чтобы продемонстрировать эффективность выравнивания износа , показывая, что я не мог легко повредить карту, повторяя записи с небольшим количеством данных в одно и то же (видимое) место. IMO предыдущий тест на 64 Кбайт был, вероятно, реальным – но должен быть 16 МБ. Система сбросила данные на аппаратное обеспечение, и оборудование сообщило о записи без ошибок. Если это был обман, карта не была бы хороша ни для чего, и она не может кэшировать 16 МБ в любом месте, кроме первичного хранилища, и это то, что тест должен подчеркнуть.

Будем надеяться, что 10 000 записей по 16 МБ каждый достаточно, чтобы продемонстрировать, что даже на карточке с наименьшим именем (значение: 5 долларов США CDN) запуск rw-корневой файловой системы 24/7, которая ежедневно записывает скромные объемы данных , не будет носить карту в разумный период времени. 10 000 дней – 27 лет … и карта по-прежнему прекрасна …

Если бы мне платят за разработку систем, которые делали более тяжелую работу, я бы хотел сделать хотя бы несколько тестов, чтобы определить, как долго может длиться карта. Моя догадка заключается в том, что с таким, как этот, который имеет низкую скорость записи, это может занять недели, месяцы или годы непрерывной работы на максимальной скорости (факт, что нет сравнимых тестов такого рода в режиме онлайн, факт, что это будет очень продолжительное дело).

Что касается подтверждения карты, все еще в порядке, я больше не думаю, что использование badblocks в конфигурации по умолчанию является подходящим. Вместо этого я сделал это так:

Это означает, что нужно протестировать с использованием блока размером 512 кБ, повторяемого 8 раз (= 4 МБ). Так как это деструктивный тест rw, вероятно, это будет хорошо, поскольку моя домотканая относится к тому, чтобы подчеркнуть устройство, если оно используется в непрерывном цикле.

Я также создал на нем файловую систему, скопированную в файл размером 2 ГБ, diff от файла с оригиналом, а затем – поскольку файл был .iso – смонтировал его как изображение и просмотрел файловую систему внутри него.

Карта по-прежнему прекрасна. Который, вероятно, следует ожидать, в конце концов …

Источник