LINUX.ORG.RU
Форум — Desktop  

[***] Мифы о ext3/ext4 [***]


0

1

Люблю, когда все linux fanboys с пеной у рта доказывают, что фрагментации у ext3/ext4/any_other_linux_fs нет или она минимальна.

Реальный пример (e2fsck -n): 

     484 inodes used (0.00%)
     621 non-contiguous inodes (128.3%)
         # of inodes with ind/dind/tind blocks: 621/99/1
  669631 blocks used (1.70%)
       0 bad blocks
       4 large files

    7232 regular files
     210 directories
       0 character device files
       0 block device files
       2 fifos
       0 links
       3 symbolic links (3 fast symbolic links)
       7 sockets
--------
    7458 files
Memory used: 269k/0k (33k/237k), time: 126.24/ 4.46/ 3.08

Т.о. фрагментация больше ... 100%.

Raw read/write на партицию - > 100MB/sec.

Скорость чтения некоторых файлов с этой партиции ... ~200KB/sec.

Заранее предвещая крики о том, что у меня заполнение FS в районе 100% - нет, это близко не так.

/dev/md3             148G   20G  121G  14% /mnt/array3

Теперь не говорите мне, что Linux'y не нужен дефрагментатор.

★★★★★
← Удалились файлы с системы (Debian)
Альтернативы kdirstat? →
  1 2 3 →
Ответ на: комментарий от KRoN73

Сейчас нам опять расскажут лекцию про волшебство виски^W этой ФС, которая сама в онлайне борется с фрагментацией :)

Ага, особено если посмотреть на это Фрагментация ext3: маленькое исследование

В это сообщении обратите внимание на время затраченное на создание файлов в 3-х разных случаях и все станет ясно:

100 файлов по 100М каждый

  1. записывает N файлов по M килобайт в указанное место обычным способом «открыли - записали М килобайт - закрыли» --- 4 минуты
  2. записывает N файлов по M килобайт способом «открыли файл 1, записали 1Кб, закрыли файл 1, открыли файл 2...»  — 36 минут
  3. записывает N файлов по M килобайт способом «открыли N файлов, записали 1Кбв в файл 1, 1Кб в файл 2...» — 14 минут
sdio ★★★★★
()
Ответ на: комментарий от sdio

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

sdio ★★★★★
()
Ответ на: комментарий от KRoN73

> Solaris Express Community Edition пойдёт? :)
вполне. то же только в профиль.

val-amart ★★★★★
()
Ответ на: комментарий от annoynimous

>Серверы почему-то никто не дефрагментирует

На серверах обычно памяти дохера (которая юзается как дисковый кэш в ляликсах), и очень много процессов, и диски знают что такое NCQ, и контроллер не очень УГ.

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

Вот. А NTFS имеет совсем более фундаментально иные проблемы, попробуйте например зайти по сетке на расшаренную директорию в ней, где тысяч 20 файлов нежатых WAV. (даже с отрубленным atime). Уж0с. А так ниче фс, местами, могло быть сильно хуже.

anonizmus ★
()
Ответ на: комментарий от iZEN

>У ZFS очень большой кэш в оперативной памяти (сейчас у меня занято 40% RAM из 6ГБ

Сейчас по приколу посмотрел на сервере. Под кеш занято 6,3Гбайт из 8Гбайт :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

Кстати, после перехода на ext4 фрагментация, кажется, стала меньше. Точно я не сравнивал, но... После долгого использования, единственный раздел моего рабочего компа фрагметирован менее чем на 1 процент (вчера делал fsck).

Deleted
()
Ответ на: комментарий от sdio

>В это сообщении обратите внимание на время затраченное на создание файлов в 3-х разных случаях и все станет ясно:

Что именно станет ясно?

>100 файлов по 100М каждый

> 1. записывает N файлов по M килобайт в указанное место обычным способом "открыли - записали М килобайт - закрыли" --- 4 минуты > 2. записывает N файлов по M килобайт способом "открыли файл 1, записали 1Кб, закрыли файл 1, открыли файл 2..." -- 36 минут > 3. записывает N файлов по M килобайт способом "открыли N файлов, записали 1Кбв в файл 1, 1Кб в файл 2..." -- 14 минут

Что о втором и в третьем случаях приходится обрабатывать много больше системных вызовов? Или что?

anonymous
()
Ответ на: комментарий от Deleted

>После долгого использования, единственный раздел моего рабочего компа фрагметирован менее чем на 1 процент (вчера делал fsck).

Так ext4 по стопам UFS2 пошла. Только нету Soft Updates, а остальные оптимизации — "as is".

iZEN ★★★★★
()
Ответ на: комментарий от anonymous

Что о втором и в третьем случаях приходится обрабатывать много больше системных вызовов? Или что?

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

>> Что о втором и в третьем случаях приходится обрабатывать много больше системных вызовов? Или что?

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

Где там затраты у xfs затраты на создание файлов? Вы уверены, что эти затраты имеют отношение к фрагментации, а не к чему-нибудь еще?

anonymous
()
Ответ на: комментарий от sdio

Вот смотрите (количество файлов уменьшил до 10, так как это UBS диск, и долго ждать неохота; плюс в выводе dtrace удалены системные вызовы с количеством вызовов меньше 10):

bash-3.2$ uname -a
SunOS solaris-devx 5.11 snv_111b i86pc i386 i86pc
bash-3.2$ zfs create aux/dumb
bash-3.2$ zfs create aux/dumb2
bash-3.2$ zfs create aux/dumbf
bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -s 102400 -n 10 /aux/dumb"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes

dtrace: pid 20518 has exited

...
  fcntl                                                            12
  ioctl                                                            32
  read                                                             33
  close                                                            36
  stat64                                                           40
  open64                                                           48
  fstat64                                                         107
  brk                                                             225
  llseek                                                          586
  write                                                          8001

real          27.27
user           1.83
sys            1.37

bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -2 -s 102400 -n 10 /aux/dumb2"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes
dtrace: pid 20525 has exited

...
  fcntl                                                            12
  ioctl                                                            31
  read                                                             33
  close                                                            36
  stat64                                                           40
  open64                                                           48
  fstat64                                                         106
  brk                                                             241
  llseek                                                          586
  write                                                          8000

real          36.11
user           0.46
sys            0.17

bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -f -s 102400 -n 10 /aux/dumbf"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes

dtrace: pid 20529 has exited

...
  read                                                             33
  stat64                                                           40
  brk                                                             223
  write                                                       1024001
  fcntl                                                       1024002
  ioctl                                                       1024022
  close                                                       1024026
  open64                                                      1024038
  llseek                                                      1024576
  fstat64                                                     4096067

real        1:26.88
user           0.47
sys            0.21

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumb | cat > /dev/null

real          30.31
user           0.08
sys            1.09

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumb2 | cat > /dev/null

real          31.09
user           0.07
sys            1.20

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumbf | cat > /dev/null

real          31.22
user           0.08
sys            1.61

bash-3.2$

Есть вопросы? Комментарии нужны?

anonymous
()
Ответ на: комментарий от anonymous

кол-во сисколов на любой ФС, будет таким же, т.к. это зависит от способа записи, а не от типа ФС. Но зфс просел в 9 раз (у тебя в 3 раза, только потому что 1Гб (100Мб х 10) влез в файловый кеш.

Кстати, у тебя в показаниях timex время sys не соответствует кол-ву сисколов, так что веры этому тесту мало.

xfs так не проседал. я проведу тест повторно: 

$ time ./code8361.pl -n 100 -s 102400 /mnt/fs-test/test/
100.0 % 

real    4m0.167s
user    1m1.720s
sys     0m23.013s

$ time ./code8361.pl -f -n 100 -s 102400 /mnt/fs-test/test/
100.0 % 

real    16m23.389s
user    1m45.839s
sys     1m9.000s

Разница в 4 раза, а не в 9 как на v890 с 4-я дисками в zpool'e подкл. к двум контролерам.

sdio ★★★★★
()
Ответ на: комментарий от sdio

> кол-во сисколов на любой ФС, будет таким же, т.к. это зависит от способа записи, а не от типа ФС.

"Иногда лучше молчать, чем говорить" (с).

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

Что мы наблюдаем в данном случае:

Первые 2 примера - 10 файлов, 102400 однокилобайтных операций записи в файл, и всего около 9000 сисколлов, то примерно 900 сисколлов на файл.

Третий пример - те же 10 файлов, те же 102400 одокилобайтных операций записи, но уже более 10 миллионов сисколлов, то есть 1 миллион сисколлов на файл. На три порядка больше.

Не правда ли, есть разница?

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

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

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

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

> Но зфс просел в 9 раз (у тебя в 3 раза, только потому что 1Гб (100Мб х 10) влез в файловый кеш.

Насчет кто тут просел и во сколько раз - см. выше. Я бы еще понял, если бы вы приводили результаты линукса, измеренные на той же железке, на которой измеряли ZFS...

Мне просто неохота было ждать результатов, которые все равно нельзя использовать для сравнения. И я об этом честно написал. Да и задача была другая - прдемонстрировать, почему эти результаты не есть то, что вы думаете. Могу повторить для 100 файлов, если будет время. Что только, если у меня вдруг 16 ГБ памяти окажется? :-) Отмечу, что во время предыдущих измерений было всего 4ГБ.

Вопросы по скорости чтения есть? Или тоже будете утверждать, что время одинаковое, потому что все в кэше лежало?

> Кстати, у тебя в показаниях timex время sys не соответствует кол-ву сисколов, так что веры этому тесту мало.

Голову иногда полезно включать. Дело в том, что timex в данном случае был нужен в качестве секундомера, чтобы не писать что-то вроде "работал 37 минут". Так что смотреть нужно только на время real, поскольку sys и user отражают время работы непосредственно команды dtrace - скомпилировать скрипт, загрузить его в ядро, запустить процесс, уйти спать, по завершении работы процесса проснуться, получить результаты из ядра, напечатать, закончить работу. А совсем не то, что вы подумали.

Вместо этого лучше б статистику по сисколлам для линукс+XFS привели, тут же писал кто-то, что systemtap допилили до состояния, что им стало можно пользоваться.

Или мне тоже за вас это сделать?

ЗЫ. Интересно, no-dashi с такого же плана программкой носится и эффекты тотального поражения от фрагментации сферического коня в безвоздушном пространстве демонстрирует?

anonymous
()
Ответ на: комментарий от sdio

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

anonymous
()
Ответ на: комментарий от sdio

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

О каких провальных затратах речь? О тех, которые в XFS? Ведь по вашим результатам на выполнение вашего скрипта с -f на XFS времени потребовалось в 4 раза больше, чем на выполнение оного же без -f, а на ZFS - только в 3 :-)

anonymous
()
Ответ на: комментарий от anonymous

«Иногда лучше молчать, чем говорить» (с).

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

Ололо (С)

Речь не об абсолютных величинах, а о порядке этих величин.

sdio ★★★★★
()
Ответ на: комментарий от anonymous

XFS времени потребовалось в 4 раза больше, чем на выполнение оного же без -f, а на ZFS - только в 3 :-)

Вот об этих: 

Разница в 4 раза, а не в 9 как на v890 с 4-я дисками в zpool'e подкл. к двум контролерам.

sdio ★★★★★
()
Ответ на: комментарий от anonymous

Вместо этого лучше б статистику по сисколлам для линукс+XFS привели

Или мне тоже за вас это сделать?

Сделай, хотя, очевидно, результат будет схожим.

sdio ★★★★★
()
Ответ на: комментарий от anonymous

Могу повторить для 100 файлов, если будет время. Что только, если у меня вдруг 16 ГБ памяти окажется? :-) Отмечу, что во время предыдущих измерений было всего 4ГБ.

Ага, на том v890 было 16Гб памяти, против 2Гб на линуксе.

sdio ★★★★★
()
Ответ на: комментарий от anonymous

Вопросы по скорости чтения есть? Или тоже будете утверждать, что время одинаковое, потому что все в кэше лежало?

Нет, по чтению, нет, но меня все еще интересует цена этой оптимизации при записи.

sdio ★★★★★
()

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

Ждём-с дефрагментатора ...

anonymous
()
Ответ на: комментарий от sdio

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

Ололо (С)

Чего-нибудь умнее сказать не пробовали? Я тут парюсь, объясняю вам в чем недостатки вашего же «теста» (ну да, немножко резковато, но по-другому может и не дойти), а в ответ какая-то херня и одна строчка? Потрудились бы подумать, прежде чем хвататься за клавиатуру.

Считаете что это не так? Аргументируйте!

Речь не об абсолютных величинах, а о порядке этих величин.

Сударь ни черта не понял? Три порядка это не разница? Сисколл эта такая операция, которая не несет с собой никаких накладных расходов?

Разница в 4 раза, а не в 9 как на v890 с 4-я дисками в zpool'e подкл. к двум контролерам.

Результаты c XFS были получены на той же железке? Нет. Повторите на той же железке, тогда можно будет о чем-то говорить.

Ага, на том v890 было 16Гб памяти, против 2Гб на линуксе.

Тут важно не это, а то, что за CPU был в коробке с вашим линуксом. Озвучьте?

Вот, кстати, результаты для 100 файлов:

bash-3.2$ pfexec zfs create aux/dumb
bash-3.2$ pfexec zfs create aux/dumb2
bash-3.2$ pfexec zfs create aux/dumbf
bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -s 102400 -n 100 /aux/dumb"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes

dtrace: pid 20985 has exited

...
  write                                                         80001

real        7:13.10
user           0.51
sys            0.23

bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -2 -s 102400 -n 100 /aux/dumb2"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes
dtrace: pid 20992 has exited

...
  write                                                         80000

real        6:55.16
user           0.51
sys            0.24

bash-3.2$ timex pfexec dtrace -s /usr/demo/dtrace/syscall.d -c "perl /tmp/dumb.pl -f -s 102400 -n 100 /aux/dumbf"
dtrace: script '/usr/demo/dtrace/syscall.d' matched 236 probes

dtrace: pid 21001 has exited

...
  write                                                      10240001
  fcntl                                                      10240002
  ioctl                                                      10240022
  close                                                      10240026
  open64                                                     10240038
  llseek                                                     10240486
  fstat64                                                    40960067

real       14:18.37

Что мы видим? Время с -f всего в два раза больше времени без -f. А что с чтением?

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumb | cat > /dev/null

real        5:03.25
user           0.69
sys           11.32

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumb2 | cat > /dev/null

real        6:18.38
user           0.67
sys           12.22

bash-3.2$ pfexec zpool export aux; pfexec zpool import aux
bash-3.2$ timex tar cf - /aux/dumbf | cat > /dev/null

real        6:49.78
user           0.59
sys           10.79

Чудес не бывает, чтение результатов работы скрипта с -f заняло на 35% больше времени чем без -f. Специально сходил посмотрел ваши результаты для XFS - 4 минуты 34 секунды против 3 минут 2 секунд, то есть на 50% больше.

Есть вопросы? Нужны еще комментарии?

anonymous
()
Ответ на: комментарий от anonymous

Три порядка это не разница? Сисколл эта такая операция, которая не несет с собой никаких накладных расходов?

Головой можно не только есть, ага: Ты утверждал что кол-во сисколов зависит от платформы и ее реализации. Я же сказал что от ФС и платформы порядок величины кол-ва сисколов не зависит, а зависит от способа записи, т.к. везде делается open, seek, write, fflush, close, ... Надо объяснить подробнее или сам подумаешь?

Ты же уже второй или третий раз рассказываешь о разнице в кол-ве сисколов между вариантами теста с -f и без. Неужели тебя окружают только такие идиоты как я? Корона не давит?

работы скрипта с -f заняло на 35% больше времени чем без -f.

Да мало ли какой там у тебя zpool. Если там raid-0, то фрагментация вообще может не влиять: пока с одного читаем, другой seek по диску делает. Ты же сам знаешь, что железо у нас разное. Надо ли объяснять некорректность такого сравнения?

sdio ★★★★★
()
Ответ на: комментарий от anonymous

Тут важно не это, а то, что за CPU был в коробке с вашим линуксом. Озвучьте?

Линукс:

  1. RAM=2G,
  2. 1 scsi disk
  3. CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

Solaris:

  1. RAM=16G,
  2. 4 scsi disks in zpool (raid-10), 2 scsi контроллера
  3. 4 CPU UltraSparc-IV 1350Mhz
sdio ★★★★★
()
Ответ на: комментарий от sdio

>> Три порядка это не разница? Сисколл эта такая операция, которая не несет с собой никаких накладных расходов?

>Головой можно не только есть, ага: Ты утверждал что кол-во сисколов зависит от платформы и ее реализации. Я же сказал что от ФС и платформы порядок величины кол-ва сисколов не зависит, а зависит от способа записи, т.к. везде делается open, seek, write, fflush, close, ... Надо объяснить подробнее или сам подумаешь?

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

Оно более-менее не зависит в примере с -f (хотя хер его знает, че там в линуксе напотимизировали). В дефолтном случае и с -2 оно как раз таки зависит, от того, как стандартная библиотека буферизует ввод-вывод, размера этого буфера, его фиксированности или нет и хер знает чего еще. Или вы 8000 на сто поделить не можете и увидеть, что восемьюстами операциями записи по 1 килобайту стомегабайтный файл никак не сгенерировать? Попробуйте в голову не только есть.

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

> Ты же уже второй или третий раз рассказываешь о разнице в кол-ве сисколов между вариантами теста с -f и без. Неужели тебя окружают только такие идиоты как я? Корона не давит?

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

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

>>работы скрипта с -f заняло на 35% больше времени чем без -f.

> Да мало ли какой там у тебя zpool. Если там raid-0, то фрагментация вообще может не влиять: пока с одного читаем, другой seek по диску делает. Ты же сам знаешь, что железо у нас разное.

Сударь, не вы ли несколько постов назад ткнули в то, что речь идет не об абсолютных величинах, а об их порядке, то есть величинах относительных? А счас начались попытки отъехать: "мало ли какой там у тебя zpool"... Себя то обманывать зачем? Железо у нас точно разное, к бабке не ходи. Пул у меня самый обычный - половина 500 ГБ 2.5" SATA диска 5400RPM, подключенного через USB:

[code] bash-3.2$ zpool status -v aux pool: aux state: ONLINE status: The pool is formatted using an older on-disk format. scrub: none requested config:

NAME STATE READ WRITE CKSUM aux ONLINE 0 0 0 c2t0d0p1 ONLINE 0 0 0

errors: No known data errors bash-3.2$ zpool list aux NAME SIZE USED AVAIL CAP HEALTH ALTROOT aux 232G 112G 120G 48% ONLINE - bash-3.2$ [/code]

Куда уж ему до вашего SCSI, небось еще и 10kRPM а то и все 15...

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

> Надо ли объяснять некорректность такого сравнения?

Давайте, объясните. Вдруг я и правда тут один идиот такой и нихера не понимаю.

Некорректность сравнения может быть только в одном случае - если на линуксе количество операций, доходящих в итоге до файловой системы, существенно отличается от того, что происходит в Solaris'е. Вы этого до сих пор не смогли ни подтвердить, ни опровергнуть. Давайте, дерзайте!

anonymous
()
Ответ на: комментарий от anonymous

Тьфу блин, опять формат не выбрал. Сорри.

bash-3.2$ zpool status -v aux
  pool: aux
 state: ONLINE
status: The pool is formatted using an older on-disk format.
 scrub: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	aux         ONLINE       0     0     0
	  c2t0d0p1  ONLINE       0     0     0

errors: No known data errors
bash-3.2$ zpool list aux
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
aux    232G   112G   120G    48%  ONLINE  -
bash-3.2$
anonymous
()
Ответ на: комментарий от anonymous

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

Некорректность сравнения может быть только в одном случае - если на линуксе количество операций, доходящих в итоге до файловой системы, существенно отличается от того, что происходит в Solaris'е.

Сначала ответь на простой вопрос.

Если я сделаю в Солярисе 

dd if=file1 of=file2 bs=1024

т.е. буду писать файл «file2» по 1 Кбайту . сколько сисколов write будет вызвано при размере файла «file1» 1Мб? Неужели меньше 1024? Нет? Как же так? Ведь у тебя оптимизация в стандартной библиотеке

sdio ★★★★★
()
Ответ на: комментарий от sdio

> Сначала ответь на простой вопрос.

Да, недостатки воспитания в детстве невозможно исправить в большом возрасте. Ну да ладно.

>Если я сделаю в Солярисе

>dd if=file1 of=file2 bs=1024

>т.е. буду писать файл "file2" по 1 Кбайту . сколько сисколов write будет вызвано при размере файла "file1" 1Мб? Неужели меньше 1024? Нет? Как же так? Ведь у тебя оптимизация в стандартной библиотеке

Сударь, вы не путаете часом функции стандартной библиотеки с системными вызовами?

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/dd/dd.c#1739

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/t...

Еще вопросы есть? И давайте вы уже ответите хоть на один вопрос, заданный вам, а? Если не можете, то так и скажите. И это не можете?

Вы пионер красноглазый чтоли?

anonymous
()
Ответ на: комментарий от maxcom

на постгресс думаю фрагментация будет негативно влиять

PgSQL вроде умел работать на разделе без ФС

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

>XFS фрагментируется очень сильно

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

у меня не тесты, у меня реальная машина 300 ГБ (SAS 15k, RAID 0+1, HP SmartArray), на которой хранятся индексы. При перелопачивании индексов там такие жуткие вещи :)

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

>у меня не тесты, у меня реальная машина 300 ГБ

Опять же, смотри выше мои df -T по использованию XFS. У меня тоже реальная машина, где под XFS несколько раз по 300Гб и уже не первый год :)

>При перелопачивании индексов там такие жуткие вещи

Что за такие страшные индексы? И что такое "перелопачивание"?? XFS хорошо себя ведёт на толстых файлах и на чтении мелочёвки. Ты, часом, не молотком шурупы забиваешь?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Опять же, смотри выше мои df -T по использованию XFS. У меня тоже реальная машина, где под XFS несколько раз по 300Гб и уже не первый год :)

Что за такие страшные индексы? И что такое «перелопачивание»?? XFS хорошо себя ведёт на толстых файлах и на чтении мелочёвки. Ты, часом, не молотком шурупы забиваешь?

У тебя, у тебя. У тебя я видел только синтетические тесты коня в вакууме. Перелопачивание: чтение -> обработка -> запись. На один и тот же раздел, на одном и том же рейде. Объем данных колеблется от нескольких сот килобайт(почасовая статистика) и до десятков гигабайт(общая статистика) и бывают uninterruptible sleep'ы. Сервер, контроллеры и диски менялись, проблемы не в них, дефрагментация штатными средствами помогает.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

>У тебя я видел только синтетические тесты коня в вакууме

Понятно. Читать не умеем даже не только тему в целом, но и тебе написанные сообщения. После этого не удивит ничего, даже фрагментация на какой-нибудь RT-11.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Понятно. Читать не умеем даже не только тему в целом, но и тебе написанные сообщения. После этого не удивит ничего, даже фрагментация на какой-нибудь RT-11.

Ну уж извините, мне не нужны какие-то странные ОС(ФС?). Мы питаемся тем, что нам послал RHEL и Solaris.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

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

KRoN73 ★★★★★
()

Зачотный вброс. Читаю почти внимательно.

FiXer ★★☆☆☆
()
Ответ на: комментарий от xpahos

Глядишь, если дело хорошо пойдет, то линуксоиды тоэе скоро смогут питаться тем, что послал Solaris.

Вон, индусы какие-то занялись делом, портируют ZFS в линукс:

http://kqinfotech.wordpress.com/

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

anonymous
()
Ответ на: комментарий от anonymous

Глядишь, если дело хорошо пойдет, то линуксоиды тоэе скоро смогут питаться тем, что послал Solaris.

не там кормишься.

xpahos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 →
← Удалились файлы с системы (Debian)
Desktop
Альтернативы kdirstat? →