Небольшой размер файла один из достоинств: Ваш браузер не поддерживается

Ответы на тест 3 по Информатике 7 класс (Босова Л.Л. учебник)

Ответы на тест 3 по Информатике 7 класс

Ответы на тест 3 по Информатике 7 класс — это пособие для родителей для проверки правильности ответов обучающихся детей (ГДЗ) на «Тестовые вопросы для самоконтроля», указанные в учебнике Информатики. Как утверждают авторы учебника (Л.Л.Босова, А.Ю.Босова) в конце каждой главы приведены тестовые задания, которые помогут оценить, хорошо ли учащиеся освоили теоретический материал и могут ли они применять свои знания для решения возникающих проблем.

Ответы на вопросы помогут родителям оперативно проверить выполнение указанных заданий.

1. К устройствам ввода графической информации относится:

а) принтер
б) монитор
в) мышь
г) видеокарта

ПРАВИЛЬНЫЙ ОТВЕТ: в) мышь

2. К устройствам вывода графической информации относится:

а) сканер
б) монитор
в) джойстик
г) графический редактор

ПРАВИЛЬНЫЙ ОТВЕТ: б) монитор

3. Наименьшим элементом изображения на графическом экране является:

а) курсор
б) символ
в) пиксель
г) линия

ПРАВИЛЬНЫЙ ОТВЕТ: в) пиксель

4. Пространственное разрешение монитора определяется как:

а) количество строк на экране
б) количество пикселей в строке
в) размер видеопамяти
г) произведение количества строк изображения на количество точек в строке

ПРАВИЛЬНЫЙ ОТВЕТ: г) произведение количества строк изображения на количество точек в строке

5. Цвет пикселя на экране монитора формируется из следующих базовых цветов:

а) красного, синего, зелёного
б) красного, жёлтого, синего
в) жёлтого, голубого, пурпурного
г) красного, оранжевого, жёлтого, зелёного, голубого, синего, фиолетового

ПРАВИЛЬНЫЙ ОТВЕТ: а) красного, синего, зелёного

6. Глубина цвета — это количество:

а) цветов в палитре
б) битов, которые используются для кодирования цвета одного пикселя
в) базовых цветов
г) пикселей изображения

ПРАВИЛЬНЫЙ ОТВЕТ: б) битов, которые используются для кодирования цвета одного пикселя

7. Видеопамять предназначена для:

а) хранения информации о цвете каждого пикселя экрана монитора
б) хранения информации о количестве пикселей на экране монитора
в) постоянного хранения графической информации
г) вывода графической информации на экран монитора

ПРАВИЛЬНЫЙ ОТВЕТ: а) хранения информации о цвете каждого пикселя экрана монитора

8. Графическим объектом не является:

а) рисунок
б) текст письма
в) схема
г) чертёж

ПРАВИЛЬНЫЙ ОТВЕТ: б) текст письма

9. Графический редактор — это:

а) устройство для создания и редактирования рисунков
б) программа для создания и редактирования текстовых изображений
в) устройство для печати рисунков на бумаге
г) программа для создания и редактирования рисунков

ПРАВИЛЬНЫЙ ОТВЕТ: г) программа для создания и редактирования рисунков

10. Достоинство растрового изображения:

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

ПРАВИЛЬНЫЙ ОТВЕТ: в) точность цветопередачи

11. Векторные изображения строятся из:

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

ПРАВИЛЬНЫЙ ОТВЕТ: б) графических примитивов

12. Растровым графическим редактором НЕ является:

а) Gimp
б) Paint
в) Adobe Photoshop
г) CorelDraw

ПРАВИЛЬНЫЙ ОТВЕТ: г) CorelDraw

13. Несжатое растровое изображение размером 64 х 512 пикселей занимает 32 Кб памяти. Каково максимально возможное число цветов в палитре изображения?

а) 8
б) 16
в) 24
г) 256

ПРАВИЛЬНЫЙ ОТВЕТ: г) 256

14. Некое растровое изображение было сохранено в файле p1.bmp как 24-разрядный рисунок. Во сколько раз будет меньше информационный объём файла p2.bmp, если в нём это же изображение сохранить как 16-цветный рисунок?

а) 1,5
б) 6
в) 8
г) размер файла не изменится

ПРАВИЛЬНЫЙ ОТВЕТ: б) 6

15. Сканируется цветное изображение размером 25 х 30 см. Разрешающая способность сканера 300 х 300 dpi, глубина цвета — 3 байта. Какой информационный объём будет иметь полученный графический файл?

а) примерно 30 Мб
б) примерно 30 Кб
в) около 200 Мб
г) примерно 10 Мб

ПРАВИЛЬНЫЙ ОТВЕТ: а) примерно 30 Мб

16. Рассчитайте объём видеопамяти, необходимой для хранения графического изображения, занимающего весь экран монитора с разрешением 1280 х 1024 и палитрой из 65 536 цветов.

а) 2560 битов
б) 2,5 Кб
в) 2,5 Мб
г) 256 Мб

ПРАВИЛЬНЫЙ ОТВЕТ: в) 2,5 Мб

Вы смотрели «Ответы на тест 3 по Информатике 7 класс (Л.Л. Босова, Ответы на вопросы)»

Перейти на страницу «Ответы на тест 4 по Информатике 7 класс (Л.Л. Босова, Ответы на вопросы)»

Размер файла — штука вовсе не однозначная. Давайте посмотрим, как он может меняться… / Программы, ПО, сайты / iXBT Live

Прежде всего скажем, что речь здесь пойдет о файловых системах FAT и NTFS, как наиболее распространенных, и ничего не будет сказано о файловых системах, используемых в не-Windows системах, поскольку такие системы лежат вне сферы интересов автора. А теперь – к делу.

Казалось бы, какая неоднозначность может быть, если говорить о размере файла. Сколько в него данных записали, такой и размер (или длина). Сколько в нем есть байтов от начала до конца (и это число записано в файловой системе в качестве размера файла), такой и размер, не так ли? Как говорил Шельменко-денщик, так то оно так, да только трошечки не так.

Проведите эксперимент. Возьмите любой исполняемый файл  и выполните его копирование командой
copy что-то.exe что-то-другое.exe
 Если вы раньше с этим сталкивались, то уже знаете, что результирующий файл получится намного короче исходного и не будет копией. Причина простая: программа copy, запущенная без параметра  /b,  копирует файл до тех пор, пока не встретит байт с кодом 27h, этот символ называется «конец файла».

Итак, у нас уже есть два разных признака конца файла – по числу, записанному в файловой системе, и по специальному байту в теле файла. Правда, стоит отметить, что второй признак остался с тех времен, когда файлы были преимущественно текстовыми и сейчас практически не применяется.

В файловых системах, использующих кластеры, а FAT и NTFS относятся именно к таким ФС, есть еще третий размер – размер файла на диске, то есть суммарный размер кластеров, отведенных этому файлу. В файловых системах FAT этот размер больше размера собственно файла или равен ему. Разница между размерами, если она есть, – так называемый хвост файла – это напрасно пропадающее место на диске, плата за размещение файлов по кластерам, а не встык друг за другом, хотя файловые системы с таким размещением файлов тоже существуют.

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

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

Максимальный размер такого файла зависит от размера записи и составляет примерно 600 байтов для записи мелкого размера (1 Кб) и 3600 – для записи крупного размера (4 Кб). Следует, впрочем, отметить, что до недавнего времени Windows показывала размер такого файла на диске равным одному кластеру, хотя фактически ни одного кластера файлу не выделено.

Если файл сжат, то его размер на диске может быть заметно меньше собственно длины файла (количества данных в нем).

Дополнительно усложняют картину так называемые разреженные файлы. В них полезные данные содержаться только в определенных участках файла, а остальная часть файла не используется вовсе. Возьмем в качестве примера файл журнала изменений \$Extend\$UsnJrnl, имеющийся почти на каждом компьютере (не пытайтесь увидеть его в проводнике или других диспетчерах файлов, не получится).

Он может иметь длину несколько гигабайт, но значимых данных содержит при этом обычно только 32 мегабайта в самом конце. А остальная часть вообще никаких данных не содержит, места на диске не занимает, и при попытке прочитать данные из этой части система выдаст набор нулей, даже не обращаясь к диску.
Если у читателя возникнет желание поэкспериментировать с разреженными файлами, такой файл можно создать с помощью команды fsutil sparse. А на досуге можно обдумать, какова же настоящая длина файла, если система записала в соответствующую графу число 4 Гб, а реальных данных в файле только 32 Мб и на диске он занимает тоже 32 Мб.

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

В файловых системах FAT такого понятия не существует, и функции, которые используют эту величину, записывают в тело файла на соответствующих местах нули. В NTFS эта длина является характеристикой файла.

Попробуем пояснить, о чем идет речь, на примере. Возьмите флешку (флешка используется для наглядности, поскольку она медленнее жесткого диска работает с большими объемами данных) размером от гигабайта, отформатированную в FAT32, и создайте на ней большой файл командой
fsutil file createnew k:\пробный.txt 900000000

Если буква, присвоенная флешке, отличается от К, то исправьте команду соответствующим образом.
Вы увидите, что процедура создания файла окажется довольно продолжительной, полминуты или даже больше (хотя сообщение «файл создан» появится сразу же, появления приглашения командной строки придется подождать). Это совсем не удивительно, ведь в описании команды (https://technet.microsoft.com/en-us/library/cc788058.aspx) сказано, что создаваемый файл состоит из нулей. А файл у нас получился 858 мегабайт, так что его запись и должна занять не такое уж малое время.

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

Рассмотрим это на примере. Создайте новый файл на одном из рабочих дисков, отформатированном в NTFS. Сотни мегабайт совершенно не обязательны, десятка-другого килобайт будет вполне достаточно:
fsutil file createnew C:\пробный.txt 10000

Теперь откройте его с помощью любого просмотрщика файлов, например FAR.

Как видим, в файле действительно нули. Но если посмотреть на этот файл с помощью какого-либо редактора дисков, обращающегося к секторам напрямую, например dmde, то картина будет другая.

Если мы откроем том С как логическое устройство и посмотрим на содержимое файла, то увидим те же самые нули.

Но если открыть диск как физическое устройство, то в том же самом секторе (обратите внимание на номера LBA – разница в 63 возникла из-за того, что начало раздела сдвинуто относительно начала диска) увидим данные, которые ранее были записаны в какой-то позже удаленный файл.

И если мы увеличим длину действительных данных, то увидим эти данные в файле. Установим эту длину равной 300 байт:

fsutil file setvaliddata C:\пробный.txt 300

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

Теперь снова посмотри на содержимое файла. Заметьте, что никаких данных мы в него не записывали!

Чисто случайно получилось, что в этом файле довольно много осмысленного текста, что делает картину более наглядной. 300 десятичных байтов – это 12c шестнадцатиричных, и как раз на этом байте обрывается текст и начинаются нули. Если сдвинуть границу действительных данных еще дальше, то «проявятся» и следующие строки.

Подведем итоги

Имеется две физических длины файла – это размер файла, записанный в файловой системе и место, занимаемое на диске. Также имеется две логических длины файла – это признак конца файла (байт EOF – 27h) и длина действительных данных. Как составную часть логической длины можно рассматривать и пустые области в разреженных файлах – вспомните \$Extend\$UsnJrnl, где большой массив отсутствующих данных завершается тридцатью двумя мегабайтами действительных.

Итак, обычно, когда говорят о длине файла, имеют в виду число, хранящееся в файловой системе. Но, как видите, возможны варианты!

Вы можете выразить свою благодарность автору и стимулировать его на дальнейшее творчество, переведя небольшую сумму  с помощью пейпала http://paypal.me/Leyko, переводом на карту сбербанка 6390 0238 9021 6390 91 или через яндекс-деньги. 

Современные файловые системы:что выбрать для внешнего накопителя и почему

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

Ситуация улучшилась лишь тогда, когда стало ясно, что линейка IBM PC (прародительница практически всех выживших на сегодняшний день архитектур ПЭВМ) постепенно становится стандартом де-факто в отрасли (и не только). Ну а когда на рынке появляется доминирующая архитектура, все остальные вынуждены это учитывать — из соображений выживания. Основным сменным носителем данных тогда являлись гибкие диски, так что достаточно быстро средством обеспечения совместимости оказались те их форматы, которые использовала компания IBM. Далеко не лучшие, надо заметить. Причем не только по аппаратуре, хотя и это тоже — несмотря на то что первые дисководы на 3,5″ появились в том же году, что и первые РС, и многие производители начали их использовать еще в первой половине 80-х годов, сама IBM перешла на этот конструктив лишь в 1987 году, а до того момента цеплялась за пятидюймовые дисководы, представленные на рынке еще в 1976 году. Однако и с точки зрения форматирования «оригинальные» разработки IBM уступали даже многим клонам ее компьютеров — в частности, компания на двухсторонних дискетах двойной плотности хранила лишь 360 Кбайт информации, в то время как конкуренты из них же без особых ухищрений выжимали и 600—720 Кбайт. Ну а уж о примитивности файловой системы FAT не рассуждал только ленивый. Хотя, вполне возможно, именно примитивность и стала второй причиной превращения «писюковых дискет» в стандарт — его было очень уж легко поддерживать. Пусть хотя бы только для чтения и в дополнение к собственному «продвинутому» варианту.

Впрочем, с точки зрения сегодняшнего дня все это имеет лишь историческую ценность. Дискеты давно уже перестали использоваться в качестве основного средства переноса информации, да и альтернативных линейке «х86-based» компьютеров на большинстве сегментов рынка не осталось. Однако нельзя сказать, что это полностью решило все проблемы. Дело в том, что на этой са́мой единственной стандартной платформе работает чуть ли не больше операционных систем, чем их было во времена, когда «расцветали все цветы». Даже если взять самое распространенное на рынке семейство, а именно Windows, то оно, строго говоря, неоднородно. Бо́льшая часть инсталляций приходится до сих пор на Windows XP — родом из начала века, но занимающую чуть ли не 2/3 рынка. Где-то четверть последнего приходится на современные версии Windows, а все оставшееся — на сборную солянку из сохранившихся компьютеров с системами, появившимися до Windows XP (их сейчас осталось мало, но все еще встречаются), различные версии MacOS и цельный букет UNIX-систем. Но даже если вам повезло никогда не сталкиваться в практической жизни ни с чем, кроме Windows XP, полностью это проблему не решает — некогда «компьютерные» технологии давно уже вышли за пределы этого рынка, активно вторгаясь в сферу бытовой электроники. Например, большинство сегодняшних видеоплееров умеет работать с USB-накопителями, а в фотоаппаратах или мобильных телефонах повсеместно применяются разнообразные карты памяти. И тут все оказывается просто только в том случае, если, например, карта используется исключительно в «своем» фотоаппарате — форматируем ее средствами камеры и навсегда забываем об этом вопросе 🙂 Однако если нам надо хотя бы обмениваться данными с компьютером, тут уже все не так очевидно…

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

FAT — старая, ограниченная, но вездесущая

Начнем мы со старейшей файловой системы, появившейся еще во времена MS DOS, но, тем не менее, до сих пор иногда встречающейся. К положительным особенностям системы относятся простота, компактность служебных областей и большой срок присутствия на рынке. В общем-то, первые два достоинства непосредственно вытекают из третьего — в 1980 году, когда система и появилась, компьютеры были столь «мощными», а носители информации столь «емкими», что ничего сложного использовать было просто нельзя. Впрочем, оригинальный вариант, а именно FAT12, уже давно вышел из широкого пользования вследствие того, что размер диска с этой системой не может превышать 32 МиБ. Хотя, конечно, к некоторым фотоаппаратам и даже видеокамерам до сих пор умудряются прилагать флэш-карту такого или даже меньшего размера, но полноценно использовать их в подобной комплектации все равно не выйдет.

А вот FAT16, появившаяся 23 года назад, уже интереснее, благо размер как файла, так и раздела доведен уже до 2 ГиБ (для тех, кто еще не успел привыкнуть к двоичным приставкам — это чуть больше двух гигабайт). Теоретически, емкость раздела может достигать и 4 ГиБ при использовании кластеров по 64 Кбайт, однако этот вариант не является стандартным, так что поддерживается далеко не везде. На компьютерах с таким разделом умеют работать системы начиная с Windows NT4 и более новыми этой линейки, но вот ни бытовая техника, ни большинство «альтернативных» систем с ними не совместимо. Таким образом, этот вариант можно считать полностью пригодным лишь для накопителей невысокой емкости. Последних у пользователей на руках достаточно много до сих пор, но «бал правят» не они. А вот во времена флэшек размером до гигабайта была FAT16 весьма актуальной ввиду, как раз, небольших потребностей в объеме для своих нужд. Так, например, на отформатированной под FAT16 флэшке на 128 МБ пользователю остаются доступными 128 621 744 байт, а если использовать FAT32 — 127 921 152 байт. С одной стороны, пустячок, а с другой — лет пять назад «лишние» 700 КБ на дороге не валялись. Недаром Microsoft не рекомендует использовать FAT32 на разделах менее 512 МБ, так что отформатировать их во что-то отличное от FAT16 можно только сторонними средствами.

Последняя все еще актуальная сфера применения этой системы — телефоны, плееры, фотоаппараты и прочая «бытовуха», рассчитанная на поддержку карт SD или microSD, но не поддерживающая SDHC (сейчас такое уже не выпускается, но еще используется). Стандартной файловой системой для этих карт является как раз FAT16, поэтому большинство таких устройств никаких других и не поддерживают. В данном случае крайне желательно форматировать карту исключительно в устройстве, но не делать этого на компьютере. Причина в том, что Windows XP (по крайней мере, про нее это известно точно) иногда умудряется при явном указании ФС отформатировать карту под FAT32, после чего тот же фотоаппарат может ее не увидеть и даже не предложить возможности переформатировать. Решать проблему приходится какой-нибудь альтернативной программой форматирования — снова на компьютере.

FAT32 — разумный компромисс между совместимостью и прочими характеристиками

В отличие от предшественницы, FAT32 сейчас является наиболее массовой системой для внешних накопителей. 90% флэшек и более половины ВЖД поступают с заводов отформатированными именно под нее. Причина? По совместимости она лишь немногим хуже FAT16 — «за кадром остаются» только слишком уж древние операционные системы. Изначально поддержка FAT32 появилась в августе 1996 года вместе с Windows 95 OSR2 — если кто-то ныне и использует более старую ОС на своем компьютере, то вряд ли он будет подключать к нему современный внешний накопитель 🙂 Причем в большинстве случаев — и не сможет.

Однако иногда использование FAT32 уже неудобно, из-за чего приходится использовать другие системы. Основным и самым существенным недостатком является то, что файлы не могут иметь размер более 4 ГиБ. Соответственно, хранить на накопителе образы DVD-дисков, очень большие архивы или некоторые фильмы — не выходит. Вернее, это можно сделать, но их приходится разбивать на части, а потом перед использованием «склеивать», что очень неудобно. Либо такое разбиение нужно предусмотреть заранее, что иногда делается, но далеко не всегда. Именно эта причина и вызывает необходимость использования других файловых систем — пусть имеющих меньшую поддержку со стороны оборудования, зато свободных от ограничения на размер файла. Судя по нашей конференции, кстати, эта проблема в последнее время стои́т достаточно остро — многие пользователи, купив внешний жесткий диск или флэшдрайв, буквально в первые же дни пытаются записать туда очень большой файл и… очень удивляются реакции системы, которая сообщает о недостатке места на носителе. А удивляться есть чему: по-хорошему, создатели ОС могли бы обрабатывать данную ситуацию более корректным образом — сообщая пользователю, что используемая файловая система непригодна для записи данного файла; а иначе все очень странно выглядит: свободного места десяток или даже сотня (а то и несколько сотен) гигабайт, а рапортуют о его нехватке при попытке записи файла размером всего 5-6 гигабайт. Мы, конечно, не думаем, что после публикации данной статьи соответствующие сообщения в форуме исчезнут, однако надеемся, что их, хотя бы, станет немного меньше 🙂

А вот размер тома, отформатированного под FAT32, теоретически может составлять до 8 ТиБ, что даже на сегодня очень много (не говоря уже о времени, когда система создавалась). Впрочем, не все так просто — компания Microsoft, скажем, считает, что тома более 32 ГиБ делать нежелательно. И не просто считает, а ввела соответствующие ограничения во встроенные программы форматирования Windows XP и более новых версий своей системы. Особенно печальный результат получается при попытке отформатировать, например, флэшку на 64 ГБ штатными средствами: для FAT32 (по мнению Microsoft) она слишком велика, а NTFS на сменных носителях (опять же — по мнению Microsoft) использовать не положено. Обе проблемы с легкостью решаются при помощи использования сторонних утилит форматирования. Так, например, простенькая консольная программа fat32format спокойно работает с томами до 2 ТБ (максимум для нединамических разделов Windows XP).

Не все гладко, кстати, и с Windows 98 или ME, несмотря на то что для них использование FAT32 безальтернативно. Дело в том, что некоторые встроенные в эти системы утилиты так и остались 16-разрядными. Ну а поскольку для таких программ максимальный размер адресуемого блока памяти равен примерно 16 МБ, то разделы, на которых таблица FAT имеет больший размер, им недоступны. В переводе на простой язык это означает невозможность полноценно использовать разделы больше ≈127,5 ГиБ (около 133 ГБ). Точнее, попробовать-то можно, но осторожно — не пытаясь «натравить» на такой раздел разнообразные дисковые утилиты: в лучшем случае (штатные средства) они просто не будут работать, а в худшем — могут и данные испортить. Либо, для страховки, можно просто разбивать накопители, которые планируется использовать и с Windows 9x, на разделы по сотне гигабайт. Заметим, что к внешним дискам эти ОС все равно более лояльны, чем к внутренним: получить под их управлением доступ к внутреннему винчестеру более чем на 137 ГБ — задача не совсем тривиальная, а вот для USB-накопителя бо́льшие объемы допустимы без особых проблем, за исключением неработоспособности дисковых утилит.

У других ОС таких проблем нет, да и описанные, в принципе, решаемы. Это и позволяет считать данную файловую систему оптимальной для тех случаев, когда требуется обеспечить максимальную совместимость внешнего накопителя со всем спектром компьютерной и бытовой техники. Особенно в тех случаях, когда хранение файлов размером более 4 ГБ не предполагается — тогда и заметных на практике недостатков не будет.

NTFS — быстрая, мощная, но избыточная

До последнего времени данная файловая система являлась единственным надежно работающим средством обойти «проблему больших файлов» на компьютерах под управлением Windows. Разумеется, не всякой версии Windows — линейка 9х в принципе не поддерживает NTFS, однако совместимость с этими системами важна уже, мягко говоря, не всем. Хуже то, что в бытовой технике поддержка NTFS встречается достаточно редко. Но в последнее время встречается. Кроме того, такие разделы поддерживают и компьютеры, работающие под управлением MacOS или Linux — как минимум, они умеют читать данные с таких разделов, а при установке специальных драйверов нередко начинает работать и функция записи. При помощи дополнительных драйверов, кстати, поддержку NTFS можно «прикрутить» и к Windows 98 или даже DOS.

Чем эта система хороша? Во-первых, ограничения как на размер тома, так и на размер файлов можно считать отсутствующими: и то, и другое может составлять до 16 экзабайт (для улучшения восприятия сообщим, что в одном экзабайте примерно миллион терабайт). Во-вторых, можно получить и более высокую скорость работы, особенно если попадаются каталоги, содержащие очень большое количество файлов — например, когда их несколько тысяч, разница в скорости работы FAT32 и NTFS заметна невооруженным глазом. В-третьих, эта система является более отказоустойчивой, как минимум из-за журналирования. В-четвертых, она способна работать с кластерами малого размера (точнее, не только способна, но и рассчитана на это), так что потери дискового пространства при хранении маленьких файлов у NTFS заметно меньше, чем у FAT32, не говоря уже об exFAT. В-пятых, достаточно удобной возможностью является встроенная поддержка сжатия данных. Разумеется, архивирование «на лету» куда менее эффективно, чем при помощи специальных программ-архиваторов с серьезными алгоритмами, но зато и выполняется прозрачным для пользователя образом, а при хранении хорошо сжимаемых данных дает заметный эффект. В общем, нет ничего удивительного, что на внутренних жестких дисках на данный момент NTFS является доминирующей системой.

Но на внешних у нее есть и недостатки. Самым безобидным из них является невозможность на практике получить многие преимущества системы. В частности, в настоящий момент редко кто переносит несжатые файлы: даже если говорить об офисных документах, то начиная с 2007 года они уже автоматически сжимаются при сохранении, а о фотографиях или видеофайлах и говорить нечего, так что встроенная поддержка сжатия оказывается не у дел (и даже чаще мешает, чем наоборот). Да и огромные количества файлов в каталоге встречаются редко — куда более типичным является десяток очень больших файлов. (Заодно это нивелирует и пользу от небольших кластеров.) Кроме того, улучшенная за счет кэширования производительность может оказаться палкой о двух концах — отформатированные под NTFS накопители крайне нежелательно отключать от компьютера, не воспользовавшись «Безопасным извлечением» или его аналогами. Все указанные неудобства свойственны для любых внешних накопителей, но для основанных на флэш-памяти есть и дополнительные. Во-первых, журналирование в данном случае рекомендуется отключать (поскольку ресурс массовых флэшек ограничен, так что «лишние» записи файлов им ни к чему). Во-вторых, быстродействие этих накопителей существенным образом зависит от выровненности всех структур ФС и кластеров по границам блоков стирания, что актуально и для FAT, но для NTFS, с ее небольшим размером кластера (а также любовью многих программ, в том числе и штатной утилиты форматирования Windows XP, смещать начало раздела на 63 сектора), может оказаться весьма критично. Да и вообще — как показывает опыт многих пользователей, наилучших скоростных результатов проще всего добиться, используя размер кластера в 32 Кбайт, т. е. не меньший, чем для FAT32.

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

exFAT — будущее флэш-накопителей и не только

В ситуации, когда FAT32 уже недостаточно, а NTFS — неоптимальна, неудивительно, что компания Microsoft в очередной раз (спустя 10 лет после появления FAT32) доработала FAT. Новая версия, получившая название exFAT, дебютировала в Windows CE 6, поскольку была наиболее актуальна для встроенных систем и бытовой техники, но позднее ее поддержка появилась и в настольных компьютерах. Чем новинка отличается от предыдущей версии?

Во-первых, снято ограничение на размер файла — подобно варианту «взрослых» систем, он может достигать 16 экзабайт. Во-вторых, увеличен размер кластера: если для предыдущих систем его приходилось удерживать в рамках 32 Кбайт (иногда применяя не всеми поддерживаемый вариант на 64 Кбайт), то в exFAT максимальный размер кластера составляет 32 МиБ, т. е. увеличился в 1024 раза. Разумеется, это крайне неудобно в случае файлов небольшого размера, однако они сейчас не слишком-то актуальны в качестве объекта транспортировки, зато размер таблицы размещения файлов удалось сократить соответствующим образом, а следовательно, снизились и требования к объему оперативной памяти для работы с томами большого размера. Естественно, для exFAT было отменено и волюнтаристское ограничение в 32 ГиБ для размера тома — не нужно оно более 🙂 Первыми, кто этим воспользовался, кстати, оказались производители SD-карт памяти, достаточно жестко завязывающиеся в стандартах именно на FAT. Для спецификаций версий SD 1.х стандартной была FAT16 (что и определяло максимальную емкость карты в 2 ГБ), версия 2.0 ориентируется на FAT32 (карты SDHC до 32 ГБ), а в новой версии 3.0 для карт большого объема стандартом является именно exFAT (соответственно, карты SDXC заметных с точки зрения практического использования ограничений по емкости не имеют).

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

В общем, системка получилась на диво хороша — есть все нужное и нет ничего ненужного. Почему же до сих пор приходится мучиться с выбором, а не перейти на exFAT повсеместно? А потому, что для внешнего накопителя, как уже не раз было сказано, совместимость является той еще «священной коровой» — что толку в характеристиках используемой вами на флэшке файловой системы, если вы этой флэшкой сможете воспользоваться лишь на каждом десятом компьютере? exFAT до сих пор находится как раз в подобном положении. Гарантированно ее использовать можно только на компьютерах, работающих под управлением Windows Vista с SP1, Windows Server 2008 и Windows Seven. Вроде бы поддержка есть и в MacOS X 10.6, но тут, вероятно, потребуется апдейт системы — кстати, очень может быть, что Apple бы и не стала поддерживать новую разработку Microsoft, однако в последнюю линейку компьютеров компания решила встроить картоводы с поддержкой карт SDXC, а это в обязательном порядке потребовало и совместимости с exFAT. Для Linux придется самостоятельно интегрировать драйвер (причем их два: нормальный поддерживает только чтение, а запись — лишь использующий FUSE). Пользователям Windows XP повезло чуть больше — еще в начале 2009 года на Windows Update появилось официальное обновление KB955704, добавляющее к системам с SP2 и SP3 поддержку exFAT, однако оно не относится к обязательным, так что найдется далеко не на всех компьютерах. С бытовой техникой все столь же грустно, как с предыдущими версиями Windows — счастливым исключением являются немногие современные устройства с поддержкой SDXC (им деваться некуда), однако в остальных до сих пор проще встретить поддержку NTFS, нежели exFAT.

Прочая экзотика, иногда полезная

Нравится это кому или нет, но на данный момент времени большинство персональных компьютеров (порядка 95%) работает под управлением одной из систем семейства Windows, причем в основном эта доля распределена между Windows XP, Vista и Seven. Соответственно, наиболее актуальным является выбор между перечисленными файловыми системами, ведь только они без особых ухищрений поддерживаются этой тройкой. Задумываться о чем-либо ином есть смысл только в том случае, когда совместимость с Windows вас в принципе не волнует: несмотря на то что для поддержки большинства «родных» для прочих ОС файловых систем есть и драйверы для Windows, на каждый компьютер их ставить — дело неблагодарное. Поэтому вне зависимости от достоинств и недостатков какой-нибудь ext3 использовать ее можно разве что в том случае, когда внешний накопитель эксплуатируется в качестве стационарного или близком к тому виде.

Единственное частичное исключение из правил — файловая система HFS+, традиционная для MacOS X. И дело даже не в каких-то ее особых качествах, а в том, что эта операционка имеет пусть и небольшую, но монолитную долю рынка (чего не скажешь о разных иногда несовместимых друг с другом «линуксах»). Кроме того, несмотря на малую распространенность в мировом масштабе, есть страны, где ниша MacOS вполне ощутима. Это и ставит HFS+ в привилегированное положение. Вплоть до того, что некоторые производители продают специальные версии внешних винчестеров «for Mac», отформатированных под HFS+ (а не FAT32 или NTFS, которые встречаются чаще) прямо на заводе. Из этого не следует ни непригодность для Mac прочих винчестеров, ни невозможность использовать «маковские» на других компьютерах. Более того — для обмена данными между Маком и прочими системами вообще удобнее применять FAT32, гарантированно работающую в большинстве случаев. В чем плюс именно HFS+? В том, что встроенная система резервного копирования и восстановления информации Time Machine совместима только с дисками с этой файловой системой. Таким образом, если вы используете накопитель для резервирования данных на Маке, выбора не остается. Ну а если иногда возникает и необходимость подключения этого внешнего устройства к другим компьютерам, вполне логичным действием будет установка на них специальных драйверов с поддержкой HFS+. Впрочем, не самым худшим вариантом окажется и разбиение диска на пару разделов — небольшой с FAT32 позволит обмениваться данными различным системам, а раздел HFS+ даст возможность ни в чем себе не отказывать при работе под MacOS X.

Иногда покупка специальной версии внешнего винчестера «для Маков» может быть оправдана и для пользователя Windows — как правило, все эти модели снабжены интерфейсом FireWire (иногда и FireWire-800) в дополнение к USB 2.0, что может оказаться полезным. C файловой системой проблем не будет — с точки зрения Windows, отформатированные под HFS+ винчестеры никакой структуры данных не содержат, так что просто создаем раздел (или разделы) и форматируем нужным нам образом.

FAQ вместо заключения

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

Хаки при работе с большим числом мелких файлов / Блог компании SRG / Хабр

Идея статьи родилась спонтанно из дискуссии в комментариях к статье «Кое-что об inode».

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

Поэтому делюсь нашим опытом, может кому и пригодится.

Проблема первая: «No space left on device»

Как упоминалось в вышеупомянутой статье, проблема в том, что свободные блоки на файловой системе есть, а вот inode закончились.

Проверить число использованных и свободных inodes можно командой df -ih:

Не буду пересказывать статью, если кратко, то на диске есть как блоки непосредственно для данных, так и блоки для мета-информации, они же inodes (index node). Их количество задается при инициализации файловой системы (речь идет об ext2 и ее наследниках) и далее не меняется. Баланс блоков данных и inodes вычисляется из среднестатистических данных, в нашем же случае, когда много мелких файлов, баланс должен сдвигаться в сторону числа inodes — их должно быть больше.

В Linux уже предусмотрели варианты с разным балансом, и все эти предрасчитанные конфигурации находятся в файле /etc/mke2fs.conf.

Поэтому при первичной инициализации файловой системы через mke2fs можно указать нужный профиль.

Вот несколько примеров из файла:

    small = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 4096
    }

    big = {
        inode_ratio = 32768
    }

    largefile = {
        inode_ratio = 1048576
        blocksize = -1
    }

Выбрать нужный вариант использования можно опцией «-T» при вызове mke2fs. Также можно вручную задать нужные параметры, если нет готового решения.

Больше подробностей описано в мануалах для mke2fs.conf и mke2fs.

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

Однако стоит учитывать такую интересную особенность, как архитектура процессора.

Я как-то в свое время задумался, что мне для больших файлов фоток нужен размер блока побольше. Дело было в домашних условиях, на домашней файлсторадже имени WD на архитектуре ARM. Я, не долго думая, задал размер блока то ли 8к, то ли 16к вместо стандартного 4к, предварительно измерив экономию. И все было замечательно ровно до того момента, как сам сторадж не вышел из строя, при этом диск был жив. Поставив диск в обычный комп с обычным интеловским процессором, получил сюрприз: неподдерживаемый размер блока. Приплыли. Данные есть, все хорошо, но прочитать невозможно. Процессоры i386 и подобные не умеют работать размерами блока, не соответствующими размеру страницы памяти, а она ровно 4к. В общем, дело закончилось использованием утилит из user space, все было медленно и печально, но данные спасли. Кому интересно — гуглите по названию утилиты fuseext2. Мораль: или продумывать все кейсы наперед, или не строить из себя супергероя и пользоваться стандартными настройками для домохозяек.

UPD. По замечанию пользователя berez уточняю, что для i386 размер блока не должен превышать 4к, но не обязательно должен быть ровно 4к, т.е. допустимы 1к и 2к.

Итак, как решали проблемы мы.

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

Во-вторых, решение нужно было срочное.

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

Чтобы уменьшить число файлов, было решено складывать файлы в один общий архив. Учитывая нашу специфику, мы складывали в один архив все файлы за некоторый промежуток времени, и проводили архивацию cron-таской ежедневно по ночам.

Выбрали zip-архив. В комментариях к предыдущей статье предлагался tar, но с ним есть одна сложность: он не имеет оглавления, и файлы в нем лежат поточно (не просто так «tar» — это сокращение от «Tape Archive», наследие ленточных накопителей), т.е. если нужно почитать файл в конце архива — нужно прочитать весь архив, поскольку в нем нет смещений для каждого файла относительно начала архива. А поэтому это долгая операция. В zip все намного лучше: он имеет то самое оглавление и смещения файлов внутри архива, и время доступа к каждому файлу не зависит от его расположения. Ну и в нашем случае можно было задать опцию сжатия «0», ибо все файлы уже заранее были пожаты в gzip.

Клиенты забирают файлы через nginx, и согласно старому API, указывается просто имя файла, например так:

http://www.server.com/hydra/20170416/0453/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5

Чтобы на лету распаковывать файлы, нашли и подключили модуль nginx-unzip-module (https://github.com/youzee/nginx-unzip-module) и настроили два апстрима.

В результате получилась такая конфигурация:

Два хоста в настройках выглядели так:

server {
  listen *:8081;

  location / {
    root      /home/filestorage;
  }
}

server {
  listen *:8082;

  location ~ ^/hydra/(\d+)/(\d+)/(.*)$ {
    root      /home/filestorage;
    file_in_unzip_archivefile "/home/filestorage/hydra/$1/$2.zip";
    file_in_unzip_extract "$2/$3";
    file_in_unzip;
  }
}

И конфигурация апстримов на вышестоящем nginx:

upstream storage {
  server server.com:8081;
  server server.com:8082;
}

Как работает:

• Клиент идет на front nginx
• Front nginx пытается отдать файл с первого апстрима, т.е. напрямую с файловой системы
• Если файла нет — пытается отдать со второго апстрима, который пытается найти файл внутри архива

Проблема вторая: опять «No space left on device»

Это вторая проблема, с которой мы столкнулись, когда в каталоге много файлов.
Мы пытаемся создать файл, система ругается, что места нет. Изменяем имя файла и снова пытаемся его создать.

Получается.

Выглядит примерно так:

Проверка inodes ничего не дала — их много свободных.

Проверка места — то же самое.

Подумали, что может слишком много файлов в каталоге, а на это есть ограничение, но опять нет: Maximum number of files per directory: ~1.3 × 10^20

Да и файл-то создать можно, если поменять имя.

Вывод — проблема в имени файла.

Дальнейшие поиски показали, что проблема в алгоритме хеширования при построении индекса каталога, при большом числе файлов наблюдаются коллизии со всеми вытекающими последствиями. Более подробно можно почитать тут: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories

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

 tune2fs -O "^dir_index" /dev/sdb3

В общем, как временное решение может сработать.

Мораль: много файлов в каталоге — это обычно плохо. Так делать не надо.

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

Но общее число маленьких файлов — это все равно плохо, даже если их разбить по каталогам — тогда см. первую проблему.

Проблема третья: как посмотреть список файлов, если их много

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

Стандартное решение — команда ls.

Ок, посмотрим, что получается на 4772098 файлах:

$ time ls /home/app/express.repository/offercache/ >/dev/null

real	0m30.203s
user	0m28.327s
sys	0m1.876s

30 секунд… многовато будет. Причем основное время уходит на обработку файлов в user space, а вовсе не на работу ядра.

Но решение есть:

$ time find /home/app/express.repository/offercache/ >/dev/null

real	0m3.714s
user	0m1.998s
sys	0m1.717s

3 секунды. В 10 раз быстрее.
Ура!

UPD.

Еще более быстрое решение от пользователя berez — отключение сортировки у ls

time ls -U /home/app/express.repository/offercache/ >/dev/null
real	0m2.985s
user	0m1.377s
sys	0m1.608s

Проблема четвертая: большой LA при работе с файлами

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

Самое разумное, что хочется — использовать SSD. Реально круто. Вопрос только в стоимости многотерабайтных SSD.

Но если диски обычные, копировать файлы надо, а это ко всему еще и продакшн-система, где перегрузка ведет к недовольным возгласам клиентов? Есть как минимум два полезных инструмента: nice и ionice.

nice — уменьшает приоритет процесса, соответственно шедулер раздает больше квантов времени другим, более приоритетным процессам.

В нашей практике помогало выставлять nice максимальным (19 — это минимальный приоритет, -20 (минус 20) — максимальный).

ionice — соответственно корректирует приоритет ввода/вывода (I/O scheduling)

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

echo 1000 > /proc/sys/dev/raid/speed_limit_max

Проблема пятая: Как синхронизировать файлы в real-time

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

Стандартное решение: Rsync over SSH.

Это хороший вариант, если только не нужно это делать раз в несколько секунд. А файлов много. Даже если их не копировать — то надо как-то все равно понимать, что изменилось, а сравнить несколько миллионов файлов — это время и нагрузка на диски.

Т.е. нам надо сразу знать, что надо копировать, без запуска сравнения каждый раз.

Спасение — lsyncd. Lsyncd — Live Syncing (Mirror) Daemon. Он тоже работает через rsync, но дополнительно мониторит файловую систему на предмет изменений с использованием inotify и fsevents и запускает копирование только для тех файлов, которые появились или изменились.

Проблема шестая: как понять, кто грузит диски

Это наверное знают все, но тем не менее для полноты картины: для мониторинга дисковой подсистемы есть команда iotop — наподобие top, но показывает процессы, наиболее активно использующие диски.

Кстати, старый добрый top тоже позволяет понять, что проблемв с дисками или нет. Для этого есть два наиболее подходящих параметра: Load Average и IOwait.

Первый показывает, сколько процессов стоят в очереди на обслуживание, обычно больше 2х — уже что-то идет не так. При активном копировании на бэкап-сервера мы допускаем до 6-8, после этого ситуация считается нештатной.

Второй — насколько процессор занят дисковыми операциями. IOwait >10% — причина для беспокойства, хотя у нас на серверах со специфическим профилем нагрузки бывает стабильно 40-50%, и это реально норма.

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

Каковы преимущества и недостатки использования сжатия файлов? | Small Business

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

Место для хранения на компьютере

Со временем файлов становится не только больше, но и их размер. Например, если в какой-то момент отправка 30 страниц текста за несколько минут могла быть невероятной технологией, современный пользователь компьютеров ожидает HD-видео и звука по запросу.Большинство компьютеров имеют достаточно места для хранения, поэтому хранение больших файлов не представляет большой проблемы, а создание дополнительного хранилища с помощью внешнего жесткого диска или USB-накопителя — это просто и недорого. Тем не менее, при работе с файлами большого размера экономия места на диске — разумная практика. Не говоря уже о том, что многие распространенные программы по-разному ограничивают размер данных.

Лимиты данных Gmail

Как многие из вас знают, Gmail не позволяет отправлять вложения электронной почты, размер которых превышает 25 МБ. Кроме того, Google позволяет пользователям отправлять файлы через Интернет, используя популярный облачный сервис Google Drive. Отсутствие сжатия файлов делает процесс отправки массовой информации более трудоемким. Отсутствие сжатия файлов может вызвать проблемы у получателей при отправке данных в Интернете или по сети.

Преимущества и недостатки сжатия

Помня об этом, рассмотрим некоторые преимущества и недостатки сжатия и обсудим некоторые распространенные типы сжатия, такие как zip-файлы и сжатие без потерь.Таким образом, вы можете не тратить время на загрузку и передачу огромных файлов и правильно работать с программами, которым требуется много места.

Что такое сжатие данных?

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

Сжатие данных vs.Сжатие файлов?

Сравнивая сжатие данных и сжатие файлов, вы должны понимать, что это не всегда синонимы. Часто сжатие файлов можно рассматривать как разделение сжатия данных, в то время как сжатие данных относится к уменьшению размера любого объекта данных — будь то кластер ячеек или отдельные биты данных. Сжатие файлов — это метод сжатия данных, который уменьшает размер файла для повышения эффективности использования дискового пространства. Кроме того, сжатие файлов уменьшает размеры файлов при резервном копировании соответствующей информации и обеспечивает более быструю передачу в Интернете или по сети.

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

Как работает сжатие данных?

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

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

Чем отличается сжатие файлов от сжатия?

Если говорить об этом, архивирование — это форма сжатия файлов. В частности, zip-файлы, хотя .zip или. zipx, часто содержат несколько сжатых файлов, известных как «архивы». Zip-файлы — это самый известный формат сжатия среди пользователей Windows.Поэтому неудивительно, что WinZip — наиболее широко используемая программа сжатия для пользователей ПК.

Примечание : К сожалению, в macOS нет встроенной служебной программы архивирования, предназначенной для работы с zip-файлами. Таким образом, сторонники Apple должны полагаться на сторонние приложения для обработки сжатых данных такого типа.

Общие сведения о Zip-файлах

Как бы то ни было, подумайте о том, как папки работают в Windows. Вы можете сгруппировать несколько файлов в папке и перемещать папку.Между тем файлы остаются вместе в исходном порядке. Zip-файлы работают аналогичным образом, но содержимое папки уменьшается для повышения производительности хранилища. ZIP-файлы не только упрощают организацию связанных файлов, но также значительно упрощают управление передачей, загрузкой, отправкой по электронной почте и хранением данных.

Это определение zip-файла устраивает большинство людей. Но знаете ли вы, что у zip-файлов есть много других функций, кроме простого сжатия файлов и создания сжатых архивов? К тому же WinZip — не единственная программа для управления сжатыми файлами, но и не самая продвинутая.

Стороннее программное обеспечение

Бесплатное программное обеспечение для Windows под названием 7-Zip — это программа, которая может делать гораздо больше, чем собственный архиватор операционной системы, то есть WinZip. Ниже приведены некоторые преимущества использования стороннего программного обеспечения для сжатия:

Шифрование Zip-файлов — бесценный ресурс, если вы хотите сжимать файлы, защищая их от посторонних глаз. Только не забудьте использовать надежный пароль, чтобы словарные атаки и грубая сила не помешали вашим усилиям по шифрованию.

Самораспаковывающийся архив — это обычный zip-файл со встроенным исполняемым файлом (.exe) с расширением . Выполнение архива позволит начать процесс извлечения самостоятельно. Для открытия архива не обязательно использовать какие-либо специализированные программы.

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

Наконец, встроенная утилита 7-Zip для измерения степени сжатия позволяет более компактно сжимать файлы. Хотя это преимущество не является существенным, при определенных обстоятельствах может возникнуть проблема с выделением места для нескольких дополнительных MB.

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

Преимущества сжатия файлов

Как вы уже видели, использование сжатия файлов дает множество преимуществ.Подведем итоги:

Повышенная эффективность вычислений

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

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

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

Электронная почта / доступность веб-страницы

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

Недостатки сжатия данных

Хотя это обсуждение в основном было сосредоточено на преимуществах сжатия файлов , было бы упущением не упомянуть некоторые недостатки, обычно связанные со сжатием. Вот некоторые недостатки при сжатии данных:

Сжатые файлы должны быть несжатыми

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

Исполняемые файлы имеют плохую репутацию

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

Если вы поместите зашифрованные файлы в уже отформатированную zip-папку, есть большая вероятность, что они станут незашифрованными при распаковке.Этот недостаток кодирования может привести к непреднамеренному раскрытию личной информации и конфиденциальных данных.

Преимущества и недостатки сжатия

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

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

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

.

Как работает сжатие файлов | HowStuffWorks

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

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

Объявление

Если программа сжатия просканирует фразу Кеннеди, первая повторяемость, с которой она столкнется, будет состоять всего из пары букв. В словах «не спрашивайте, что у вас» есть повторяющийся узор из буквы «т», за которой следует пробел — в «не» и «что». Если программа сжатия записала это в словарь, она могла бы записывать «1» каждый раз, когда за буквой «t» следовало пробел. Но в этой короткой фразе этого шаблона недостаточно для того, чтобы его можно было использовать, поэтому программа в конечном итоге его перезапишет.

Следующее, что программа может заметить, — это «ou», которое встречается как в «your», так и в «country». Если бы это был более длинный документ, запись этого шаблона в словарь могла бы сэкономить много места — «ou» — довольно распространенная комбинация в английском языке. Но по мере того, как программа сжатия прорабатывала это предложение, она быстро нашла лучший выбор для словарной статьи: не только повторяется «ou», но и повторяются целые слова «your» и «country», и они фактически повторяются. вместе, как словосочетание «ваша страна.«В этом случае программа перезапишет словарную статью для« ou »записью« ваша страна ».

Фраза «может сделать для» также повторяется, один раз за ней следует «ваш» и один раз за ней следует «вы», что дает нам повторяющийся образец «могу сделать для вас». Это позволяет нам записывать 15 символов (включая пробелы) с одним числовым значением, в то время как «ваша страна» позволяет нам записывать только 13 символов (с пробелами) с одним числовым значением, поэтому программа перезаписывает запись «ваша страна» как просто «r страна, а затем напишите отдельную запись для «может сделать для вас.«Программа действует таким образом, собирая все повторяющиеся биты информации и затем вычисляя, какие шаблоны следует записать в словарь. Эта способность переписывать словарь является« адаптивной »частью алгоритма LZ на основе адаптивного словаря . способ, которым программа на самом деле это делает, довольно сложен, как вы можете видеть из обсуждений на Data-Compression.com.

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

1. спросите__
2. what__
3. you
4. r__country
5. __can__do__for__you

И это меньшее предложение: «1not__2345 __ — __ 12354»

Предложение теперь занимает 18 единиц памяти, а наш словарь занимает 41 единицу.Таким образом, мы уменьшили общий размер файла с 79 до 59 единиц! Это всего лишь один способ сжатия фразы, и не обязательно самый эффективный. (Посмотрим, сможете ли вы найти лучший способ!)

Так насколько хороша эта система? Коэффициент уменьшения файла зависит от ряда факторов, включая тип файла, размер файла и схему сжатия.

В большинстве языков мира определенные буквы и слова часто встречаются вместе в одном шаблоне.Из-за такой высокой степени избыточности текстовые файлы , очень хорошо сжимаются. Уменьшение на 50 процентов и более типично для текстового файла хорошего размера. Большинство языков программирования также очень избыточны, потому что они используют относительно небольшой набор команд, которые часто идут вместе в заданном шаблоне. Файлы, содержащие много уникальной информации, например графику или файлы MP3, не могут быть сильно сжаты с помощью этой системы, потому что они не повторяют много шаблонов (подробнее об этом в следующем разделе).

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

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

.

6 Преимущества и недостатки анимированных GIF-изображений — ConnectUS

Можно сделать множество изображений, чтобы привлечь внимание людей. Один из них — использование анимированных гифок. Это форматы файлов, которые позволят пользователям использовать серию кадров, а затем объединять их в таком порядке, который в конечном итоге формирует некую анимацию. Однако, несмотря на преимущества использования этой опции, следует учитывать и соответствующие недостатки. Чтобы определить, действительно ли это ваш идеальный формат файла изображения, вы можете проверить некоторые плюсы и минусы анимированных гифок, представленных здесь.

Список преимуществ анимированных GIF-файлов

1. Маленький размер файла
Одним из основных преимуществ использования анимированных GIF-файлов является размер, который может быть относительно меньше по сравнению с другими форматами файлов. Более того, это может быть полезно при загрузке изображений в Интернете, поскольку они могут загружаться быстрее без потери качества.

2. Профессионально выглядящие изображения
Помимо файлов небольшого размера при использовании анимированных gif, эти типы также могут поддерживать прозрачный фон.Это также поможет придать более профессиональный вид конкретному веб-сайту с анимацией на разном фоне.

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

Список недостатков анимированных файлов GIF

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

2. Редактирование невозможно
Еще один недостаток использования анимированных GIF-файлов заключается в том, что их нельзя редактировать, если анимация уже закодирована в настоящий GIF-файл.Поэтому вам нужно убедиться, что у вас есть окончательное изображение, прежде чем сразу приступить к работе. Если вы этого не сделаете, вам, возможно, придется сделать то же самое с самого начала, чтобы внести незначительные изменения в существующий файл gif.

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

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

Автор Биография
Натали Реголи — дитя Божье, преданная жена и мать двух мальчиков.Она имеет степень магистра права Техасского университета. Натали публиковалась в нескольких национальных журналах и занимается юридической практикой в ​​течение 18 лет. Если вы хотите связаться с Натали, перейдите сюда, чтобы отправить ей сообщение. .

Преимущества и недостатки электронных таблиц | Малый бизнес

Элизабет Наттер Обновлено 25 января 2019 г.

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

Преимущество: систематизация данных

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

Недостаток: предвзятость пользователя

Однако обратная сторона заключается в том, что в эти презентации включается только информация, которую пользователь выбирает для анализа, и, следовательно, другая уместная информация, которая может повлиять на принятие решения, может быть непреднамеренно исключена. Чтобы сделать отчетность по данным более удобной и всеобъемлющей, компании предпочитают использовать инструменты отчетности, такие как Tableau и Qlik, вместо того, чтобы полагаться только на электронную таблицу.

Преимущество: упрощение вычислений

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

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

Недостаток: изучение синтаксиса требует навыков

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

Преимущество: доступ нескольких пользователей

В современной совместной рабочей среде нескольким пользователям в офисе часто требуется доступ к одним и тем же документам. При использовании Microsoft Excel можно предоставить общий доступ к таблицам, но только один пользователь может изменять данные одновременно. Если создаются и обновляются локальные копии, другие пользователи не будут иметь доступа к новым данным.Google Sheets предлагает решение для обмена файлами и позволяет нескольким пользователям получать доступ и обновлять одну форму.

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

Недостаток: отсутствие безопасности

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

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

.