т.е. если делать правильный тест на скорость копирования то только с одного жесткого на другой?
но тогда мы меряем ещё и сам жесткий, а оно нам надо?
почему? как я понял, диск-то один? скорость записи на него одна, скорость чтения из источника тоже не изменяется (источник один и тот же).
Если основное время занимает позиционирование (а это именно так видимо), то просто может у вас одна ФС лежит ближе? Вот когда вы копируете из /dev/zero, так тут источник всегда один, причём бесконечно быстрый. И файл один и большой - о чём тут ФС думать? Да ни о чём - просто тупо клади байы, и всё.
ФС решает как видно из топика коммента с рейзер.
да ничего там не видно: сжатие файлов - документированная фишка Linux'а. В EXT3/4 она включается отдельно для файлов/каталогов:
A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this
file returns uncompressed data. A write to this file compresses data before storing them on the disk.
Note: please make sure to read the bugs and limitations section at the end of this document.
<...>
BUGS AND LIMITATIONS
The `c', 's', and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented in the
current mainline Linux kernels. These attributes may be implemented in future versions of the ext2 and
ext3 filesystems.
и как видно, в МОЁМ ядре ПОКА не включена. Что там у вас - без понятия. Особенно с новой ФС, которой у меня естественно нет. Кроме того, есть ещё и т.н. разряжённые файлы, их умеет делать даже команда cp. dd конечно такого не делает, но где написано, что этим не занимается ваша FS? Если, ЕМНИП, такое NTFS уже делать могла, начиная с Windows2000. В cp довольно примитивный алгоритм, так почему-бы его не улучшить? Уже на уровне ФС, учитывая, что сейчас не 2000й год, и процессоры стали намного быстрее. Не... Сначала сделайте рандомный файл (это долго, но пойдёт любой архив со сжатием), а потом уж этот рандомный файл пишите, причём с другого диска. Или можно программку написать простенькую, чтоб генерила псевдослучайные числа, а то /dev/urandom уж больно тормозная обычно (про /dev/random вообще молчу).
]]>как же бтр мог мешать, если данные копировались с ext4 на ext4?
Опа... прошу прощения... Примерещилось, что запись с бтр на ext.
]]>почему же? потому, что прибавляется скорость чтения?
скорость позиционирования. блок головок по всему диску прыгает. читают/пишут HDD на порядок быстрее, чем головка перемещается. именно потому-то SSD и быстрее - там перемещаться просто нечему.
]]>Алгоритмы на доступ к диску
стоят по умолчанию. т.е. если никто не хочет записи на бтр, этот факт не влияет на погрешность.
если поставить DeadLine шедуллер, то вообще в момент копирование жесткий диск знать не захочет ничего про соседнюю ФС.
почему же? потому, что прибавляется скорость чтения?
Нет... фишка в другом... Алгоритмы на доступ к диску - вот важный момент. То есть не удаётся замерить, кто мусорит больше. То есть бтр мог мешать на полную программу разгонять ext4 и наоборот.
]]>в с этого-на этот-же ФИЗИЧЕСКИЙ диск копировали? тогда тесты не корректны
почему же? потому, что прибавляется скорость чтения?
Добро пожаловать в реальный мир, Нео...
говорила же мне бабушка, не бери эту таблетку.. не бери..
]]>замечу что при удалении каталога testdir ext4 выиграла с опережением на 50% (!)
я тоже заметил: всё удалил, а лампочка мигает и мигает...
правда это странный тест, мне никогда не захочется копировать такое количество файлов на одно и том же жестком диске.
в с этого-на этот-же ФИЗИЧЕСКИЙ диск копировали? тогда тесты не корректны - я просил с нормального, современного, того, который заведомо быстрее этой сороковки.
а) Ubuntu полностью переходит на этот тормоз коммунизма
б) Alve опять обманул народ, так же как с upstart
в) стоит задуматься почему интернет сообщество линукс так пропагандирует заведомую ложь о продуктах, которые должны стать килл фитчами именно Ubuntu.. какие то заказные статьи ей богу.
а как вы ещё представляете себе рекламу в мире Свободного ПО? Добро пожаловать в реальный мир, Нео...
]]>ext4 проиграл на 17.069 секунд.
так это немного для 2х минут в процентах. с достаточной для практики точностью - эквивалентно.
при копировании с btrfs на ext4 испытывал дикие тормоза, chrome грузил процессор на 99%.
это очень странно, т.к. после копирование всё вернулось в обычный режим
почему именно chrome?
это старый и известный глюк (а скорее множество глюков).
]]>Осталось посмотреть на накладные расходы и работу с большими разделами
по этому рейзер и не использую больше + проблемы при крэше ФС.. чекдиск рейзер просто форматит всё. =(
А можно ещё один тест? Запись туда и туда скажем 50 000 файлов? (например mercurial репозиторий FireFox'а подойдёт)
скопировал исходники ядра два раза, получилось 67658 файлов и каталогов.
root@asus:/mnt# ls -R testdir/ | wc -l
67658
root@asus:/mnt#
btrfs:
root@asus:~# time cp -R testdir/ testdir2/
real 2m16.319s
user 0m0.496s
sys 0m15.526s
root@asus:~#
ext4
root@asus:/mnt# time cp -R testdir/ testdir2/
real 2m33.388s
user 0m0.475s
sys 0m10.687s
ext4 проиграл на 17.069 секунд.
при копировании с btrfs на ext4 испытывал дикие тормоза, chrome грузил процессор на 99%.
это очень странно, т.к. после копирование всё вернулось в обычный режим
почему именно chrome?
root@asus:~# dd if=/dev/zero of=/dev/sda2 bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 3,04191 c, 33,7 MB/c
средняя 32.82
Reiserfs подгружалась как модуль
root@asus:/mnt# time tar xvf linux-source-2.6.32.tar.bz2
real 1m59.464s
user 0m41.989s
sys 0m7.987s
root@asus:/mnt# dd if=/dev/zero of=FILE bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 1,32455 c, 77,3 MB/c
средняя скорость за 10 проходов 75.7
]]>