Выбор ФС под много винтов

ахах http://lwn.net/Articles/476263/

Что хаха? По твоей ссылке английским по белому написано:
So how does XFS scale now? For one or two threads, XFS is still slightly slower than ext4, but it scales linearly up to eight threads, while ext4 gets worse, and btrfs gets a lot worse. The scalability constraints for XFS are now to be found in the locking in the virtual filesystem layer core, not in the filesystem-specific code at all. Directory traversal is now faster for even one thread and much faster for eight. These are, he suggested, not the kind of results that the btrfs developers are likely to show people.

Статейка старовата, сейчас всё ещё лучше.

Я бы лично на такой конфигурации сделал всё в обычной ext4, а винты поделил бы по тематике,

ну я пока так и держу всё своё добро.

сейчас всё ещё лучше

пруф или не было

да и у тс всего-то 6-ядерник. на нём она всё ещё медленнее, наверное

Идёшь вот сюда https://www.kernel.org/, внимательно изучаешь ченджлоги по XFS за последние 3 года, делаешь выводы.

угуг, причём ядра те фейковые, пайлдрайвер.

изучаешь ченджлоги

понятно, «постановка диагноза по аватарке» :3 придётся делать бенчмарки самому

придётся делать бенчмарки самому

Если не умеешь читать, то конечно всё надо делать самому.

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

ты так и не предоставил результатов бенчмарков

Ещё один анонимный дурачок?

тебя обижают? у тебя мания преследования?

4 веника - это не много. Думать не над чем. Вот 40-60 веников, тогда есть о чем поговорить.

короче, вы меня уговорили. я пощупаю glusterfs.

Это я в курсе, я про конкретную инсталляцию. Там 3T+1T<mirror>4T получается и это видимо та же система, где silent corrution наблюдается ?

Это я в курсе, я про конкретную инсталляцию. Там 3T+1T<mirror>4T

Э... Ты про мой вариант? Есть пара lv на 50..100Гб с зеркалированием. Но в целом сейчас от зеркалирования почти отказался. Предпочитаю репликацию на другие машины, в т.ч. удалённые.

та же система, где silent corrution наблюдается ?

Это про мои повреждённые файлы при массовом копировании? Да. Другие массивы меньших объёмов, данные реже копируются и там обнаружить потери сложнее.

Речек рейда потенциально может найти и исправить SDC. Рсинк тоже чексуммы фиксирует. Да, я не доверяю LVM.

Речек рейда потенциально может найти и исправить SDC

90% за то, что сбой-то не на низком уровне в дисковой подсистеме происходит, а на транспорте диск-контроллер-память-контроллер-диск. Тут RAID не поможет. Если сбой будет на диске, то итак при чтении вылетит ошибка чтения. RAID спасёт только тем, что сможет в зеркале в этом случае со второго носителя данные поднять. Так это и LVM умеет. Но в моём случае чтение проходит без ошибок. Запись — тоже без ошибок. Значит повреждаются данные пока они транспортируются от носителя к носителю через память и контроллеры. Там, где RAID не используется.

Да, я не доверяю LVM

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

Есть 6 ядерный проц и 4 винтчестера. Задумался. А может
стоит перейти на какую-нибудь кластерную многопоточную «БДФС» ?

Надо посмотреть, в первую очередь, на cat /proc/interrupts и понять, на скольки ядрах висит драйвер дискового контроллера. От этого будет зависеть, есть ли смысл от 6-и ядер для ФС.

чем от всякой линукс-экзотики, не ?

Не. Дело в том, что это NTFS - экзотика. В Linux. Эта ФС годится только для Windows.

Разумеется :)

Просто, судя по формулировке старт-поста, ТС хочет что-то новое для себя завести. А это чревато для сохранности данных.

Про нтфс я юморил.

[code] 19: 16091948 0 0 0 0 0 xen-pirq-ioapic-level ahci, ath9k
113: 0 0 0 0 0 0 xen-pirq-msi ahci
[/code]
Мм?

19: 16091948 0 0 0 0 0 xen-pirq-ioapic-level ahci, ath9k

Ну это, вообще, жопа. Вот тут ядра могут помочь тем, что ahci можно утащить на отдельное (вообще, просто сервис irqbalance запусти). Однако, данная строчка показывает, что контроллер прерываний такой, то обработчик для ahci может работать только на одном ядре. Максимум, что ты можешь, это выделить одно ядро только для него.

+1 за XFS

какой на... минимум, от 2-х дисков начинаются массивы только у raid1 и raid0

Иногда лучше молчать, чем говорить:

# mkfile -n 64m /var/tmp/r0
# mkfile -n 64m /var/tmp/r1
#
# zpool create rz raidz /var/tmp/r[01]
#
# zpool status rz
  pool: rz
 state: ONLINE
  scan: none requested
config:

        NAME             STATE     READ WRITE CKSUM
        rz               ONLINE       0     0     0
          raidz1-0       ONLINE       0     0     0
            /var/tmp/r0  ONLINE       0     0     0
            /var/tmp/r1  ONLINE       0     0     0

errors: No known data errors
#
# zpool list rz
NAME  SIZE  ALLOC  FREE  CAP  DEDUP  HEALTH  ALTROOT
rz    119M   144K  119M   0%  1.00x  ONLINE  -
#
# zfs list rz
NAME  USED  AVAIL  REFER  MOUNTPOINT
rz     72K  27.4M    31K  /rz
#

Ы?

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

Давно пофикшен же
http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_a...
https://wiki.archlinux.org/index.php/XFS#Integrity
Ну а если Вы не можете позволить себе UPS и Ваша страна не может позволить себе нормальную электросеть, то можно поставить запись на винты как можно раньше.

ух ты. ну ты смотри-ка. и 5 лет не прошло, как пофиксили!

ты не до конца понял. Открытые файлы, это не файлы, где поменяли содержимое, подобно паре новых страниц в ворде. Их просто открыли, процесс их удерживает, а при внезапной перезагрузке ФС их обнуляет. УПС тут поможет частично.

Я так пованговал, что raid-z - нечто типа raid5, а raid-z2 - нечто типа raid6? А в чём преимущества?

Да, при перезагрузке ОС или крахе драйвера ФС UPS не поможет

RAID-Z2 может пережить выход из строя двух носителей, RAID-Z1 переживёт выход из строя только одного.

Для raid5 и raid6 характерно тоже самое. Это просто маркетинговое переименование, или raidz[12] действительно чем-то лучше?

В RAID-Z1(2) решена проблема классического RAID-5(6) «Write hole»: http://www.stableit.ru/2010/08/raid-5-write-hole.html

https://blogs.oracle.com/bonwick/entry/raid_z

Понятно, спасибо.

zfs отпадает, его расширять нельзя.

ZFS-пул можно расширять, присоединяя так называемые «виртуальные устройства». Это «гирлянды» из сборок разного вида (mirror, raidz(1,2,3)), которые последовательно подсоединяются к исходному пулу, увеличивая его объём и производительность!

Так, если исходный пул был RAID-Z1 из трёх накопителей, то к нему можно подсоединить сборку RAID-Z из таких же трёх устройств, получив аналог RAID-50, где выход из строя любых двух дисков не в одном виртуальном устройстве сохраняет работоспособность пула.

Большую надёжность обеспечит, естественно, RAID-Z2. Там выход любых двух дисков (а в последовательной связке RAIDZ2+RAIDZ2 — выход из строя четырёх дисков попарно с одного и того же виртуального устройства) сохранит работоспособность пула.

В настоящее время для конфигурации RAID-Z не поддерживаются следующие операции:

Присоединение дополнительного диска к существующей конфигурации RAID-Z.

Удаление дисков из конфигурации RAID-Z.

В настоящее время RAID-Z можно расширять, увеличивая ёмкости носителей, не меняя его схемы. То есть, например, если RAID-Z состоит из трёх накопителей по 500ГБ каждый, для увеличения его ёмкости нужно последовательно заменить в нём все накопители на 1ТБ каждый, дождавшись окончания операций резильверинга после каждой замены диска и перезагрузки пула (zpool export/zpool import).

Если для ZIL используется, к примеру, SLC SSD (на 4 ГБ, к примеру), то батарейка в любом случае не нужна — SSD относится к долговременным устройствам хранения, данные на нём могут жить без подвода питания.

ясно, спасибо.

Ы?

умник мля. деградантам и рейд деградированый

+1 за ZFS

И где же он там деградированный? Или ты только вбитыми в мозг догмами мыслить в состоянии?

школоло удали из массива один девайс и удивись, деградант raidz из 2-х сущностей не имеет избыточности.

Тебя носом ткнуть или сам пойдешь проверишь?

Так и быть, ткну носом:

# mkfile -n 64m /var/tmp/r1
# mkfile -n 64m /var/tmp/r2
#
# zpool create rz raidz /var/tmp/r1 /var/tmp/r2
#
# zpool status rz
  pool: rz
 state: ONLINE
  scan: none requested
config:

        NAME             STATE     READ WRITE CKSUM
        rz               ONLINE       0     0     0
          raidz1-0       ONLINE       0     0     0
            /var/tmp/r1  ONLINE       0     0     0
            /var/tmp/r2  ONLINE       0     0     0

errors: No known data errors
#

И где ты здесь увидел DEGRADED?

Смотрим дальше:

# zfs list rz
NAME  USED  AVAIL  REFER  MOUNTPOINT
rz     72K  27.4M    31K  /rz
# cp /usr/dict/words /rz/words
#
# digest -a md5 /usr/dict/words
1e00bf6b2a28276a210465673bbae51e
#
# digest -a md5 /rz/words
1e00bf6b2a28276a210465673bbae51e
#
# zfs list rz
NAME  USED  AVAIL  REFER  MOUNTPOINT
rz    438K  27.1M   289K  /rz
#
# zpool export rz
#
# mkfile -n 64m /var/tmp/r2
#
# zpool import -d /var/tmp/r1 -d /var/tmp/r2 rz
#
# zpool status rz
  pool: rz
 state: DEGRADED
status: One or more devices are unavailable in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or 'fmadm repaired', or replace the device
        with 'zpool replace'.
        Run 'zpool status -v' to see device specific details.
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        rz                        DEGRADED     0     0     0
          raidz1-0                DEGRADED     0     0     0
            /var/tmp/r1           ONLINE       0     0     0
            12954638091440868468  UNAVAIL      0     0     0

errors: No known data errors
#
# digest -a md5 /rz/words
1e00bf6b2a28276a210465673bbae51e
#

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