Форум по операционной системе GNU/Linux и свободному программному обеспечению
Текущее время: 12 ноя 2018, 21:20

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
Непрочитанное сообщениеДобавлено: 14 мар 2013, 19:54 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Вот такой вопрос: имеет ли смысл выполнение промышленных проектов под Wine?

Вопрос откуда произошёл:
- меня пригласили в девелоперскую фирму, достаточно крупную и с достаточно хорошей историей, производящей некоторые разные комплексные системы... это некоторые системы ... регистрации (на HDD) потоков принимаемых сеансов GSM мобильной связи;
- ними произведено новое оборудование, превосходящее по производительности предыдущее поколение ... раз в ~5, при этом потоки по TCP/IP (входные и внутри системы, между программными модулями) и на HDD теперь достигают критических для аппаратуры величин ... 20 Мбайт/сек. и заметно более;
- есть вариант "размасштабировать" программную систему "погоризонтали" - разнести разного уровня обрабатывающие модули (сам сервер обработчик-регистратор, его визуализатор, администрирование и управление БД и др.) по разным хостам (благо, модули сделали "по уму", взаимодействующие по TCP/IP) ...
- и для улучшения (по производительности, надёжности, конфигурируемости, прозрачности, ...) перевести самые напряжённые модули-хосты (сервер обработчик-регистратор) на Linux - естественно, всё это раньше крутилось на едином хосте Windows ...
- программно эти модули в сумме - это крупный долгосрочный проект, развивавшийся и изменявшийся лет 5 или несколько более, трудоёмккостью в несколько десятков человеко-лет, писанные (кто из модулей на чём: Visual C++, C++ Builder, прикомпоновано ExtremeDB и графика DevExpress, многопоточность с использованием библиотек Boost ... и т.д.).

И вот вопрос, совершенно не тривиальный:
- а не имеет ли смысл такой и другие такие (!) проприетарные проекты просто эксплуатировать в Linux под Wine?
- вместо того, чтобы переписывать код проекта ... "портировать" то, что не портруемо ;-)
- по крайней мере (в первую очередь) те серверные компоненты проекта, которые не имеют графического пользовательского интерфейса (GUI)...
- при том, что к сфере Wine по традиции относят запуск игрушек ... ну и ещё, так уже сложилось, 1С-Бухгалтерию...
Т.е. вместо того, чтобы переписывать крупную программную систему, просто начать её эксплуатировать "как есть", не терять на переписывание времени, а уже какую-то следующую версию начать писать исключительно под Linux, "с чистого листа", начиная с архитектурной проработки под POSIX.

При этом с Wine в Linux, предполагаю, такое исполнение может получить все основные преимущества Linux, и не притягивая за собой минусов родного исполнения в Windows:
- Linux стек TCP/IP производительнее и, главное, он прозрачный, хорошо конфигурируемый, и имеющий огромный инструментарий диагностики и контроля...
- но делается всё это конфигурирование (в смысле QoS и др.) средствами ОС, извне программы, так, что она и не заметит, что ей из-под Wine подсунули другой стек;
- обращения (по буферизации на обработке) к HDD в файловой системе NTFS (которые нужны в "рандомном" а не последовательном режиме к файлам) - крайне избыточны, но теперь можно а). использовать высокопроизводительные ФС без журналирования, ext2 ту же + б). можно перепробовать и десяток разных более подходящих файловых систем (ufs, zfs и т.д.);
- можно вообще легко использовать просто вместо файлов неразмеченные дисковые устройства: /dev/sdb, или разделы: /dev/sdb3 ... с такой же лёгкостью как и файлы.

P.S. При этом только не нужно упускать (для правильной оценки), что Wine не есть система виртуализации. Это а). механизм вызовов Win32 DLL + б). подмена системных DLL (kernel32.dll, user32.dll и мн. др.) с тем, чтобы системные вызовы Win32 API ретранслировать в системные вызовы POSIX. При этом не должно происходить существенного снижения ни производительности, ни надёжности.

Таким способом многие промышленные проекты прежних лет могут просто получить новую жизнь под Linux.

Это всё - вопрос интересный, и совсем не очевидный: что выигрывает и что проигрывает при таком решении разработчик?


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 16 мар 2013, 14:20 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 28 дек 2012, 14:05
Сообщения: 113
Откуда: Самара
Цитата:
Таким способом многие промышленные проекты прежних лет могут просто получить новую жизнь под Linux.


Эта идея используется питерской компанией Etersoft (http://etersoft.ru/products/wine/about), c 2006 года, как написано в Википедии:
Цитата:
WINE@Etersoft — программный продукт, основанный на исходном коде свободного проекта Wine, предназначенный для запуска Windows-приложений на операционных системах семейства Linux и на ОС FreeBSD. Разрабатывается петербургской компанией Etersoft. WINE@Etersoft ориентирован на работу таких популярных российских приложений для бизнеса, как 1С:Предприятие, КонсультантПлюс, Гарант, КОМПАС-3D, система сдачи отчётности в электронном виде СБиС++. В отличие от обычного Wine, в нём реализована поддержка ключей защиты и работа в многопользовательском режиме


Цитата:
что выигрывает и что проигрывает при таком решении разработчик?

Вопрос все равно остается интересным.
Мои сомнения
1) Зависимость от ошибок предыдущих разработчиков. Вообще то, это в любом проекте присутствует под любой ОС и поэтому, наверно, не является определяющим.
2) По сайту Etersoft - на некоторые программные продукты может потребоваться лицензия Microsoft. Это тоже не так существенно, решение на уровне заказчика. А может это и главное? По крайней мере, Microsoft отказалась обновлять свои продукты, если они работают в wine
3) Использование недокументированных возможностей Microsoft в windows-приложениях. Это, как мне кажется, большая бяка. Но м.б. их и нету, и паника напрасна. В конце концов все приложения офисные (графический офисный интерфейс, база данных), зачем там может понадобится использование каких-то трюков?
4) Непереносимость системных вызовов в POSIX? Это я не знаю пока... А многопоточность в boost она соответствует стандартам POSIX?

Или я неправильно поняла вопрос "что выигрывает и что проигрывает при таком решении разработчик?"


Вернуться к началу
 Профиль Отправить личное сообщение  
 
Непрочитанное сообщениеДобавлено: 17 мар 2013, 17:07 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Виктория писал(а):
Вопрос все равно остается интересным.

Разговаривая с этой командой разработчиков, я для себя так подумал (неожиданно), что для некоторых существующих Windows проектов их выполнение под Wine в Linux может оказаться лучше, чем выполнение в родной среде Windows. Лучше по производительности, по надёжности, по гибкости и возможностям конфигурирования и т.д. ... по разным показателям.

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

Ошибки самого проекта как были, так и останутся, ровно в той же степени.
Но сбоев из-за ошибок самого проектного кода в отлаженном до уровня эксплуатации коде - обычно не так много.
Серьёзные сбои при эксплуатации вылазят именно в месте выполнения системных вызовов, когда эти вызовы выполняются в какой-то необычной сложившейся обстановке (при дефиците памяти, при выгруженности страницы...). А wine как раз ретранслирует системные вызовы WIn32 в системные вызовы POSIX, через тонкий слой подмененных интерфейсных DLL (kernel.dll, user32.dll и т.п.). И вот здесь частота совпадения экстремальных условий-состояний ядра, выполняющего системные вызовы, должна быть поменьше ... думаю ;-).
На сегодня, конечно, Windows гораздо надёжнее (Windows XP, Windows 7 ... судя по внешнему наблюдению поведения), но раньше это был просто "караул" (Windows 98, Windows 2000 ... не вспоминая уж к ночи Windows 95, который просто цирк)... но из-за их пресловутой "совместимости снизу вверх" там ещё достаточно сюрпризов поджидает ;-) .

Виктория писал(а):

2) По сайту Etersoft - на некоторые программные продукты может потребоваться лицензия Microsoft. Это тоже не так существенно, решение на уровне заказчика. А может это и главное? По крайней мере, Microsoft отказалась обновлять свои продукты, если они работают в wine
3) Использование недокументированных возможностей Microsoft в windows-приложениях. Это, как мне кажется, большая бяка. Но м.б. их и нету, и паника напрасна. В конце концов все приложения офисные (графический офисный интерфейс, база данных), зачем там может понадобится использование каких-то трюков?

Меня в этом обсуждении совершенно не интересовала как-раз судьба любых продуктов от Microsoft. ;-)
Меня заинтересовал вопрос: как продлить жизнь существующим проприетарным, целевым крупным проектам, выполненным ранее под эксплуатацию в ОС Windows?

Например, FineReader :lol: ... который замечательно работает под Wine + не имеет соизмеримых (по функционалу) нативных конкурентов под Linux.

Виктория писал(а):
4) Непереносимость системных вызовов в POSIX? Это я не знаю пока...

Системные вызовы Windows (Win32 API ... но не только это + специфические механизмы, такие как OLE и др.) не переносятся никак в Linux.
Они перехватываются Wine (это небольшие затраты runtime) и ретранслируются в другие (POSIX) вызовы системы, эквивалентные ... которые и выполняют исходный вызов Win32. Ещё раз: здесь нет никакой виртуализации.

Виктория писал(а):
А многопоточность в boost она соответствует стандартам POSIX?

Многопоточность (и множество других механизмов - http://www.solarix.ru/for_developers/cp ... list.shtml , http://www.boost.org/doc/libs/) boost конечно не является совместимой с каким либо стандартом API, в том числе и POSIX.
В этом её (boost) и достоинство - boost это промежуточный слой, собственная логическая модель, которая в Windows компилируется в Win32, в UNIX компилируется в POSIX, в 3-й системе - ещё во что-то. Но за счёт этого достигается статическая (периода компиляции) независимость от системы (а Wine - это пример динамической независимости, периода выполнения).

Проект Boost не одинок в таком качестве.
Для переносимости на языке C (а не C++) есть такой Apache Portable Runtime (APR), который решает ту же задачу что и boost ... но более органичным для UNIX способом (для UNIX C более характерен, чем C++).
Были ещё какой то проект (пакет), более ранний, для C++, решающий те же задачи, что и boost, широко применявшийся... да и не один.
Как очень удачный пример того же, что и boost - это STL ... а). который начал создаваться как совершенно частный инструмент в Hewlett Packard, а потом стал чуть ли не составной частью C++, б). который тоже почти полностью реализован в заголовочной .h части, использованием шаблонов, не привлекая компилируемый код (за редкими исключениями).


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 17 мар 2013, 17:56 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 28 дек 2012, 14:05
Сообщения: 113
Откуда: Самара
Цитата:
Непереносимость системных вызовов в POSIX? Это я не знаю пока..
Я здесь имела в виду именно ретрансляцию, т.е. перехват системных вызовов Win32 и их подмену.
Это моё сомнение - умозрительное, теоретическое. Любой системный вызов Win32 можно покрыть функциями POSIX?

boost больше на слуху, чем другие перечисленные средства. Раз boost транслируется в POSIX, сомнения отпадают.

Вообще то стоит на чем-нибудь попробовать :-P . Теоретизировать неохота


Вернуться к началу
 Профиль Отправить личное сообщение  
 
Непрочитанное сообщениеДобавлено: 17 мар 2013, 18:11 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Виктория писал(а):
Цитата:
Непереносимость системных вызовов в POSIX? Это я не знаю пока..
Я здесь имела в виду именно ретрансляцию, т.е. перехват системных вызовов Win32 и их подмену.
Это моё сомнение - умозрительное, теоретическое. Любой системный вызов Win32 можно покрыть функциями POSIX?

Ну, строго говоря ... теоретически (хотя какая тут может быть теория?) ;-) - не все (а наиболее точно будет сказать так: все, но не всегда ;-) ).
Но Wine это делает с большим успехом! - уже десятки тысяч программ Windows проверены на их выполнимость под Wine (хотя и сам проект Wine движется уже лет 13 ... и только ~3 года они решились назвать версию 1.хх - а до этого все годы было 0.9х ... beta, это тоже указывает на серьёзность подходов разработчиков).

Другое дело, что Wine многие годы проверяли на совместимость, главным образом, геймеры и на игровых программах...
А я ж завёл речь об Wine с промышленными программами.

Виктория писал(а):
boost больше на слуху, чем другие перечисленные средства. Раз boost транслируется в POSIX, сомнения отпадают.

Только при компиляции в UNIX (любом).
В этом смысле, программы написанные с использованием boost, конечно, полностью совместимые для применения в UNIX-системах.

Виктория писал(а):
Вообще то стоит на чем-нибудь попробовать :-P . Теоретизировать неохота

Конечно стоит.
Некоторые успешные применения Wine просто изумляют (неожиданно для такой сложности приложений):
- запуск FineReader для распознавания сканированных текстов (это как-раз удобно и наглядно попробовать);
- запуск терминала MetaTrader для операций Forex (при той активности сетевой работы, которую он производит + там своя развитая целая система программирования: Forex, MT4, MQL4);
- выполнение MS Office тоже можно считать достижением, с тем количеством всяких "находок" от MS там ... типа OLE, VisualBasic и др. прелести (хотя кому он сейчас нужен MS Office при наличии Open/Libre Office? ;-) ).


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 18 мар 2013, 15:09 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Olej писал(а):
я для себя так подумал (неожиданно), что для некоторых существующих Windows проектов их выполнение под Wine в Linux может оказаться лучше, чем выполнение в родной среде Windows. Лучше по производительности, по надёжности, по гибкости и возможностям конфигурирования и т.д. ... по разным показателям.


За счёт чего?
За счёт того, что для выполнения всё тех же вызовов Win32 API будет использоваться более эффективный и более гибкий POSIX API. Особенно акцент на гибкости, потому, что окружение, в котором теперь будут выполняться Win32 API вызовы, будет настраиваться извне самой программы, средствами операционной системы Linux.
Это, наверное, мало понятно в таком объяснении, но вот конкретности (только некоторые) ... я отдельные такие конкретные "заменители" планирую обкатать на тестовых приложениях:

1. Создание больших (и огромных) промежуточных (и временных) файлов регистрации потоков данных. Подготовка таких буферных файлов в NTFS может занимать минуты времени, потому что там файл должен прописываться последовательно значениями, подобно тому как это делает:
Код:
bash-4.2$ time dd if=/dev/zero of=./yyy bs=10240 count=1024000
1024000+0 записей считано
1024000+0 записей написано
 скопировано 10485760000 байт (10 GB), 430,979 c, 24,3 MB/c

real    7m11.006s
user    0m0.580s
sys     0m26.294s


Но в ext* файловых системах (и др.) можно создавать файлы "с дырками", которые будут реально заполняться только при последующей записи в них данных. Пример такого приложения (создающего "дырявые" файлы) приложен. Вот пример как это происходит:
Код:
bash-4.2$ du -hs
24K     .
bash-4.2$ time ./crenul xxx1 -v -s 1G
создаётся файл xxx1 размером 1073741824 байт
real    0m0.013s
user    0m0.000s
sys     0m0.002s
bash-4.2$ time ./crenul xxx2 -v -s 1G
создаётся файл xxx2 размером 1073741824 байт
real    0m0.002s
user    0m0.001s
sys     0m0.001s
bash-4.2$ time ./crenul xxx3 -v -s 1G
создаётся файл xxx3 размером 1073741824 байт
real    0m0.002s
user    0m0.000s
sys     0m0.001s
bash-4.2$ du -hs
48K     .
bash-4.2$ ls -l
итого 44
-rwxrwxr-x 1 olej olej       6958 марта 15 11:08 crenul
-rw-r--r-- 1 olej olej       1862 марта 18 13:29 crenul.c
-rw-rw-r-- 1 olej olej       2233 марта 18 13:30 crenul.hist
-rw-r--r-- 1 olej olej         92 марта 15 09:51 Makefile
-rw-r--r-- 1 olej olej 1073741824 марта 18 13:31 xxx1
-rw-r--r-- 1 olej olej 1073741824 марта 18 13:31 xxx2
-rw-r--r-- 1 olej olej 1073741824 марта 18 13:31 xxx3

Создаются 3 файла по 1 Gb. Создание происходит за миллисекунды, а все 3 гигабайтных файла занимают на диске 48 Kb.

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

3. Использование вместо размеченных файловых систем для больших буферных пространств - сырого неразмеченного пространства диска, или раздела диска, непосредственно используя файловое имя типа /dev/sdb или /dev/sdb1. А когда этот диск что-то типа SSD, с однородным временем случайного доступа, без необходимости перемещать головки - то разница может стать весьма ощутимой.


Вложения:
crenul.tgz [4.75 КБ]
Скачиваний: 523
Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 19 мар 2013, 11:17 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Olej писал(а):
Создаются 3 файла по 1 Gb. Создание происходит за миллисекунды, а все 3 гигабайтных файла занимают на диске 48 Kb.

Как вам нравятся 3 Gb файлового пространства, занимающие на диске 24 Kb (если быть совсем точным) места? :lol:


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 19 мар 2013, 13:46 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Olej писал(а):
Но в ext* файловых системах (и др.) можно создавать файлы "с дырками", которые будут реально заполняться только при последующей записи в них данных.


Olej писал(а):
3. Использование вместо размеченных файловых систем для больших буферных пространств - сырого неразмеченного пространства диска, или раздела диска, непосредственно используя файловое имя типа /dev/sdb или /dev/sdb1. А когда этот диск что-то типа SSD, с однородным временем случайного доступа, без необходимости перемещать головки - то разница может стать весьма ощутимой.


Вот совершенно предварительная версия программы-тестера для всяких таких возможностей.
Код:
bash-4.2$ ./randwr
Запуск:  ./randwr файл [число записей] [размер блока записи[{K,M}]]

Программа записывает внутрь базового файла (но в Linux это может быть и устройство типа /dev/sdb) прямым доступом заказанное число записей (если не указано, то 100) заданного размера (если не указано, то 1M). Записываемые блоки разбрасываются (позиционируются) равномерным случайным образом на длине базового файла. И при этом фиксируются временные затраты на это дело.

Виктория писал(а):
4) Непереносимость системных вызовов в POSIX? Это я не знаю пока... А многопоточность в boost она соответствует стандартам POSIX?

Тестер написан как-раз:
- на С++, в отличие от предыдущего примера crenul.tgz - тот сделан в классическом UNIX стандартном POSIX C;
- с использованием только стандартизованных С++ типов (ofstream для работы с файлом);
- и с использованием как-раз boost (mt19937 генератор случайных значений, boost::timer::auto_cpu_timer t для хронометрирования выполнения, ...);
Код:
bash-4.2$ make
c++ -Wall -L /usr/lib -l boost_timer -l boost_system -l boost_chrono -l rt randwr.cpp -o randwr


Это всё для того, чтобы получить переносимость и иметь возможность скомпилировать это в Windows, и сравнивать результаты на одном и том же компьютере и относительно одного и того же носителя данных (пока это предварительный вариант, не исключено, что он в таком виде не захочет компилироваться в Windows ... , но доведу до ума ;-), движение в этом направлении).

P.S. Здесь на отдельных операторах можно представить как boost ретранслируется в среду POSIX API. Точно так он это делает и в Win32 API.

P.P.S. Если кто раньше меня удосужится проверить это в Windows, то напишите о своих ощущениях ;-)


Вложения:
randwr.tgz [4.62 КБ]
Скачиваний: 501
Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 19 мар 2013, 14:07 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Olej писал(а):
Olej писал(а):
Но в ext* файловых системах (и др.) можно создавать файлы "с дырками", которые будут реально заполняться только при последующей записи в них данных.

...
Программа записывает внутрь базового файла (но в Linux это может быть и устройство типа /dev/sdb) прямым доступом заказанное число записей (если не указано, то 100) заданного размера (если не указано, то 1M). Записываемые блоки разбрасываются (позиционируются) равномерным случайным образом на длине базового файла. И при этом фиксируются временные затраты на это дело.


Создаём базовые файлы, 2-мя разными способами:
Код:
bash-4.2$ time dd if=/dev/zero of=./xxx2 bs=1M count=2000
2000+0 записей считано
2000+0 записей написано
 скопировано 2097152000 байт (2,1 GB), 73,258 c, 28,6 MB/c
real    1m13.354s
user    0m0.014s
sys     0m5.293s
bash-4.2$ time ./crenul xxx0 -v -s 2000M
создаётся файл xxx0 размером 2097152000 байт
real    0m0.032s
user    0m0.000s
sys     0m0.001s

Вот они:
Код:
bash-4.2$ du -hs
2,0G    .
bash-4.2$ ls -l xxx*
-rw-r--r-- 1 olej olej 2097152000 марта 19 10:49 xxx0
-rw-rw-r-- 1 olej olej 2097152000 марта 19 10:03 xxx2

Файл xxx0 - "дырявый". ;-)

А теперь перепропишем оба блоками со случайным доступом:
Код:
bash-4.2$ ./randwr xxx2 500 1m
длина файла 2097152000, блоков в файле 2000
продолжительность выполнения случайной записи:
 17.136367s wall, 0.010000s user + 0.930000s system = 0.940000s CPU (5.5%)
в случайные позиции файла записано 500 блоков длиной 1048576 байт каждый
из 2000 блоков файла модифицировано 450 блоков
длина файла после записи: 2097152000
bash-4.2$ ./randwr xxx0 500 1m
длина файла 2097152000, блоков в файле 2000
продолжительность выполнения случайной записи:
 21.772127s wall, 0.010000s user + 0.930000s system = 0.940000s CPU (4.3%)
в случайные позиции файла записано 500 блоков длиной 1048576 байт каждый
из 2000 блоков файла модифицировано 442 блоков
длина файла после записи: 2097152000
bash-4.2$ du -hs
2,5G    .

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


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Непрочитанное сообщениеДобавлено: 19 мар 2013, 14:35 
Не в сети
Писатель
Аватара пользователя

Зарегистрирован: 24 сен 2011, 14:22
Сообщения: 11294
Откуда: Харьков
Olej писал(а):
Времена незначительно отличаются ... но это времена одного порядка.


Теперь можно это же поэкспериментировать (с разными типами файловых систем) на USB-флешке, которая имитирует SSD (с равномерным временем доступа к секторам) ... только флешка нужна какая-то старенькая, которую не жалко убить - запись то всё-таки, как ни как! ;-)

Код:
bash-4.2$ ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sda3  /dev/sdb  /dev/sdb1
bash-4.2$ sudo fdisk -l /dev/sdb

Диск /dev/sdb: 32 МБ, 32702464 байт
255 heads, 63 sectors/track, 3 cylinders, всего 63872 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7d2eef5d

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sdb1              63       48194       24066    4  FAT16 <32M

Вот, как была - с FAT16.
Код:
bash-4.2$ mount | grep /dev/sdb
/dev/sdb1 on /run/media/olej/6003-DF95 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=ascii,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2)


Только здесь всё придётся смотреть через команду sync, поскольку в дисковые кэши ОС оно то сбрасывается мгновенно ... а запись этих кэшей на медленную флешку происходит весьма долго (происходящее хорошо видно по фонарям на флешке ;-) ):
Код:
bash-4.2$ time dd if=/dev/zero of=/run/media/olej/6003-DF95/f1 bs=1M count=10
10+0 записей считано
10+0 записей написано
 скопировано 10485760 байт (10 MB), 0,213425 c, 49,1 MB/c
real    0m0.216s
user    0m0.001s
sys     0m0.072s

bash-4.2$ time sync
real    2m4.444s
user    0m0.000s
sys     0m0.009s

Прописывание 10Mb файла заняло почти 3 минуты :-(
Код:
bash-4.2$ ls -l /run/media/olej/6003-DF95
итого 10240
-rw-r--r-- 1 olej olej 10485760 марта 19 13:19 f1
bash-4.2$ df | grep /run/media/olej/6003-DF95
/dev/sdb1            23862        10240    13622           43% /run/media/olej/6003-DF95
bash-4.2$
bash-4.2$ du -hs /run/media/olej/6003-DF95
11M   /run/media/olej/6003-DF95


А теперь можно его прогонять случайной записью:
Код:
bash-4.2$ ./randwr /run/media/olej/6003-DF95/f1 10000 1k
длина файла 10485760, блоков в файле 10240
продолжительность выполнения случайной записи:
 0.110104s wall, 0.000000s user + 0.060000s system = 0.060000s CPU (54.5%)
в случайные позиции файла записано 10000 блоков длиной 1024 байт каждый
из 10240 блоков файла модифицировано 6362 блоков
длина файла после записи: 10485760

bash-4.2$ time sync
real    2m10.811s
user    0m0.001s
sys     0m0.007s

bash-4.2$ ./randwr /run/media/olej/6003-DF95/f1 100 1m
длина файла 10485760, блоков в файле 10
продолжительность выполнения случайной записи:
 0.167077s wall, 0.000000s user + 0.160000s system = 0.160000s CPU (95.8%)
в случайные позиции файла записано 100 блоков длиной 1048576 байт каждый
из 10 блоков файла модифицировано 10 блоков
длина файла после записи: 10485760

bash-4.2$ time sync
real    0m15.902s
user    0m0.000s
sys     0m0.011s


Вернуться к началу
 Профиль Отправить личное сообщение Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB
[ Time : 0.183s | 18 Queries | GZIP : On ]