Создание раздела диска размером более 2 Тб в Линуксе

> а потом fsck-ть ее неделю будешь

LVM спасет отца русской демократии.

> Ты будешь делать то, что делал товарищь в посте.

Аж ни разу.

# pvcreate /dev/sdX
# vgextend my_data /dev/sdX

Чего только народ не делает чтобы не использовать "правильные" fs ;)

> А раздел-то дальше 2 тб не увеличивается, dos partition table, знаете ли!

И что только люди не придумают, лишь бы целиком /dev/*da или LVM2 не использовать...

> лучше б кто перевел пару статей как создать раздел больше 8ТБ.

Да точно так же.

> mkfs.ext3 такие разделы делать отказывается.

1. mkfs не делает разделов. mkfs делает файловую систему.
2. Пользуйте _файловую систему_, а не ext3.

> Только зачем для этого таблица разделов?

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

> производительность по nfs, в итоге добился своего: 120 мегабайт/с
> чтение, 95 мегабайт/с запись
Ааааа....поделись опытом! (я абсолютно серьезно)..
Я от nfs в боевых условиях (перманентное чтение/запись) больше полтинника
никак не выжимал...:((
Сейчас вот смотрю в сторону gfs, но до дела пока не дошло...

> Теперь нужно написать статью для чего нужен раздел диска размером более 2 Тб

У меня на домашней машине > 2Tб. И это уже мало. Образ одного Blu Ray до 50Гб однако.

> Кроме того, ленточки еще руками ставить надо в стример :)

Чего? О_О

Дядя, ты автоподачу не осилил и ленточные библиотеки видимо тоже? Признавайся, небось и под "стримером" имеешь в виду "виндавс бакап унд ресторе"? =)

> Вот такие дешевые железки бывают. http://www.promise.ru/production/sata_raid_subsystems/vtrak-mclass-p/

Вот ты и обгадился, сынок. У нас ведь просто: "Promise" поминать ну никак нельзя при серьёзных дядях. Помянул - всё, готовься на вынос.

> Пожалуйста, поделитесь опытом.

man mount / nfs / async,rsize,wsize, брутфорс и немного времени.

Promise и сервер вещи несовместимые,пора бы уже такие вещи знать.Иначе для таких "умножадных" нужно ещё и вазелин покупать.

>Вот ты и обгадился, сынок. У нас ведь просто: "Promise" поминать ну никак нельзя при серьёзных дядях. Помянул - всё, готовься на вынос.

А Fastor можно или тоже на вынос ?

http://www.etegro.com/rus/items/35/2.html вроде как весьма гламурно выглядит, ну правда я вот облизываюсь на девайс попроще (ибо первый нам пока не нужен) http://www.etegro.com/rus/items/61.html

> А Fastor можно или тоже на вынос ?

Это с каких это пор железо предоставляющее в числе прочего "ADS (Active Directory Service), PDC (Primary Domain Controller)" перестало быть оффтопиком на форуме честных линуксоидов? о_О

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

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

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

> http://www.etegro.com/rus/items/35/2.html вроде как весьма гламурно выглядит, ну правда я вот облизываюсь на девайс попроще (ибо первый нам пока не нужен) http://www.etegro.com/rus/items/61.html

А теперь признавайся, зачем это ты положил сервак компании "этегро"? ;)

я смотрю лор эффект их сайт уже уронил :)))

Даже в системе загруженой на 100% (кроме dd  еще около 40 задач читают и пишут, временами интенсивно)

ss@node-1:/mnt/pvfs2/BackUp/> dd if=/dev/zero of=test bs=100M count=80
80+0 записей считано
80+0 записей написано
 скопировано 8388608000 байт (8,4 GB), 88,0796 секунд, 95,2 MB/s

niemand@gloom:~$ dd if=/dev/zero of=test bs=100M count=80 80+0 records in 80+0 records out 8388608000 bytes (8,4 GB) copied, 89,7947 seconds, 93,4 MB/s

простой массив из двух винтов хитачи по 160гб (сата). Домашний.

или ты про nfs

Только у меня оно через один гигабитный шланг ;) Это сетевая fs.

Как нибудь могу показать как оно будет писать через IB только нужно будет задачки тормознуть и fs перемонтировать

и еще, почему это пара сетевух в bond собранных не удвоят пропускную способность ? Я тестировал - вроде нормально, почти в два раза, правда по 100мегабит, ибо в свиче к которому подключен сервак который под рукой только два гигабитных и нормально не потестить, а еще кроме скорости мы получим резервирование нахаляву - если одна сетевуха сдохнет - все будет работать

Коротко и по делу!
Спасибо автору! ;)

>Создание раздела диска размером более 2 Тб в Линуксе

...дык на OpenNet.ru таких советов несчесть:

http://www.opennet.ru/openforum/vsluhforumID1/75685.html

sS, ну расскажи уже как сделал-то ?

Это не nfs это pvfs2

Оно вам надо ? ;)

Надо. А то NFS достал уже.

Из 10 дисков, пролежавших на полочке 3+ лет, в среднем 2,5 диска не заведутся. С лентой таких проблем нет.

> У меня на домашней машине > 2Tб. И это уже мало. Образ одного Blu Ray до 50Гб однако.

Не проболвали меньше тырить? :)

>Из 10 дисков, пролежавших на полочке 3+ лет, в среднем 2,5 диска не заведутся. С лентой таких проблем нет.

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

да, разумеется на это все забивали, просто там то аналог был (в то время еще) а не цифра. Ну попортится децл, ну и хер с ним.

>Надо. А то NFS достал уже.

http://www.pvfs.org

У вас есть N компутеров чтобы её поднять ?

Она вообще говоря не для хранилища (хотя размер и может быть очень большим) а для хранения больших кусков временных данных и интенсивного параллельного I/O в кластерах с MPI.

http://www.linux.org.ru/gallery/2053822.png

>Она вообще говоря не для хранилища (хотя размер и может быть очень большим) а для хранения больших кусков временных данных и интенсивного параллельного I/O в кластерах с MPI.

Я так понял по скрину физически файлы на одном серваке находятся, или все же на нескольких? И как оно себе ведет если есть интенсивное I/O, write больше чем read раза в 3-4, но куски данных небольшие?

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

Есть такая фигня. При долгом хранении соседние слои плёнки могут "перемагничивать" друг друга.

> Не проболвали меньше тырить? :)

Не пробовал. Диски уже давно складывать некуда. Даже в пакетиках.

> Не пробовал. Диски уже давно складывать некуда. Даже в пакетиках.

Вот так ты и пришёл в spindle-pack'ам, дружок. А пакетики по назначению используй, чай не в Занзибаре обитаешь.

Кстати, теперь я знаю, почему у меня установщик Debian так глюкал. То вообще разделов не видит, то видит, но не все. Проблема 2Тб однако.

> и еще, почему это пара сетевух в bond собранных не удвоят пропускную способность ?

Способность-то удвоят, да вот nfs от этого в два раза не ускорится. Начнем с того, что там уже загрузка проца при чтении на полной скорости около 50%. Это 2ghz A64 в 64-х битном режиме и сеть с jumbo frame'ами (без них скорость чуть ниже, а загрузка растет вплоть до 75%). На запись там вообще отдельная история.

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

Во-первых, нужно узнать, на что способна сеть. Включить jumbo frames, если возможно (ifconfig eth0 mtu 9000). iperf'ом проверить максимально выжимаемую скорость в каждую сторону по отдельности и в обе одновременно. Если получается порядка 1000 mbit/s (обычно чуть больше) в каждую сторону и 500-700 mbit/s в одновременном двунаправленном тесте, все отлично. Это сложная часть; мне пришлось перепробовать 3 гигабитных свитча и в итоге отказаться от всех! Теперь даже не знаю, куда их девать. Первый я купил в полной уверенности, что jumbo frames гигабитные свитчи держат; до этого был опыт только с серверными 3com и cisco. Как оказалось, обычные быдлосвитчи его не держат. Свитч на полочку. Поискав по сайтам производителей, нашел такой, который jumbo frames держит. Купил. Оп-па! Не работает. Оказалась, мне досталась старая ревизия, которая их не держала. Которая уже давно должна была быть снята с производства, но в России ее все еще сбывали. А жаль - свитч очень красивый, для дома самое то (от netgear). Ладно, нашел свитч еще одного производителя, узнал, с какой ревизии поддерживает jumbo frame'ы. Нашел эту ревизию. Купил, действительно держит 9k фреймы. Но.. радости с этого никакой. Потому что наблюдается позитивный эффект при увеличении mtu до ~2200, а дальше все как бы работает, но измеряемая iperf'ом скорость начинает падать. И равномерно так падает при увеличении кадров, к 9000 достигая примерно 700 mbit/s. Вот вам и гигабитный свитч с поддержкой jumbo frame'ов.

А они нужны. Во-первых, капельку выше чисто пропускная способность; во-вторых, нагрузка на проц и сервера, и клиента при пропускании того же гигабита с jumbo frames ниже процентов на 30% (что важно, гигабитная сеть при пропускании через нее трафика ест _много_ cpu, даже на C2D 3Ghz системе это до 10% - это на нормальной сетевухе, с аппаратным вычислением контрольных сумм, а на более медленных машинах весьма ощутимо). В-третьих, как показыет iperf, без них может наблюдаться резкое падение скорости в двунаправленном тесте. У меня, к примеру, оно падает до 200 mbit/s в одну из сторон, при 500-700 в другую - а увеличение размера фреймов позволяет довести скорость в оба направления до 500-700.

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

Простите, а LVM2 на таких объемах уже не модно использовать?

> Это сложная часть; мне пришлось перепробовать 3 гигабитных свитча и в итоге отказаться от всех!

А можно имена железок в студию? :)

>Я так понял по скрину физически файлы на одном серваке находятся, или все же на нескольких?

На 10 данные и на 10 метаданные.

В данной конфигурации сервера данных и сервера метаданных одни и те же.

Можно их разнести в любой пропорции.

> И как оно себе ведет если есть интенсивное I/O, write больше чем read раза в 3-4, но куски данных небольшие?

Не слишком хорошо. Она любит большие куски данных и доступ к ним через ROMIO/MPI-IO.

Когда появляется гарантия, что сеть не является узким местом (гигабит в обе стороны, не меньше 500 мегабит в каждую из сторон в двунаправленной передаче и крайне желательно jumbo frame'ы), можно выжимать все из nfs'а. Впрочем, нельзя еще забывать про диски: понятно, что выше реальной скорости чтения/записи диска тут не прыгнешь, даже ее не факт, что достигнешь. У меня был рейд-массив, три сотни мегабайт в секунду обеспечивали достаточный запас, поэтому тут не было узкого места. А еще хорошо на nfs-сервер воткнуть побольше памяти, под кэш.

Во-первых, дистрибутив. Не спрашивайте, какая разница, но в изначальных экспериментах с Ubuntu server скорость получалась очень печальная - пара десятков мегабайт, и никакие твики не помогали. А когда я взял RHEL 5.1 (beta), сразу сходу получилось 100 мегабайт на чтение. В чем там разница, точно не знаю, у меня не было времени и желания выяснять, какие секретные настройки используют редхатовцы.

Теперь о финальных настройках (к ним я шел довольно долго - уж очень они ненатуральные, и nfs совершенно мистически себя ведет при изменении). Я экспериментировал с nfs3 udp, nfs3 tcp и nfs4 tcp. Что примерно должно было получиться, я знал: http://nfsv4.bullopensource.org/tools/tests/page5.php http://nfsv4.bullopensource.org/tools/tests/read_udpv3_nfsv4_tcpv3_samba3_asy... http://nfsv4.bullopensource.org/tools/tests/write_udpv3_nfsv4_tcpv3_samba3_as... примерно соответствовали наблюдаемой картине: udp легче заставить работать и чистая пропускная способность больше, но когда ситуация становится более интересной, tcp побеждает. Надо сказать, это трудный выбор, т.е. на udp действительно проще получить высокую производительность на сырое чтение в один поток - но нужно все-таки было стремиться к tcp.

А собственно секрета два: жесткое урезание количества потоков nfsd на сервере и опция sync при монтировании на клиенте. Без первого у меня не получалось прыгнуть выше определенной скорости записи. Видимо, при нескольких потоках nfsd он пишет в параллель, даже если всего один клиент записывает один поток - и тут теряется скорость. Все вокруг рекомендуют _увеличивать_ число потоков nfsd от дефолтных 8 до 16 или даже 32 - но у меня наблюдалась плохая производительность при числе потоков больше 4, а оптимум при 1 или 2. Оставил 1 - вроде негативных эффектов не наблюдаю. Это не ограничивает число одновременно выполняющихся операций, но ограничивает максимальное число клиентов - до 4, думаю, или где-то так. С парой клиентов проблем нет. Скорость чтения незначительно (несколько мегабайт) упала от такого уменьшения, но это не критично, потому что скорость записи без этого не могла достичь сотни мегабайт.

Что же до опции sync, то с async (у _клиента_!) наблюдается очень странная ситуация: писать начинает он очень быстро, а потом задыхается и скорость падает до очень маленькой (5-10 мегабит). Как оказалось, в nfs есть встроенная защита от избыточного потока при асинхронной записи, и она тут активируется. Пишут, что до ее введения было еще хуже, nfs-сервер блокировал все остальные операции чтения/записи в этот момент - а теперь пытается ограничить поток, который способен его заблокировать. Тоже нетривиальное решение, когда включаешь всюду async и пытаешься выжать производительность, а на самом деле нужен был sync.

С этими опциями различное поведение nfs3/4 udp/tcp сходится примерно к одной скорости - udp в простых операциях чуть быстрее, но tcp почти не отстает, ну а раз так, можно выбрать nfsv4 tcp и наслаждаться всеми его фичам. Никаких муторных .nfsКУЧАМУСОРА у nfs4 больше не наблюдается, блокировки там новые, много высокоуровневых операций и куча других плюсов. Различные аномалии в скорости при разных размерах буфера тоже уходят, становится очевидным, что буферы 32k или чуть больше оптимальны.

Все остальное, в общем-то, по умолчанию: nas:/ /mnt/media nfs4 rw,sync,hard,intr,noatime,rsize=131072,wsize=131072 0 0 на клиенте и /mnt/media 192.168.2.0/24(rw,async,fsid=0,all_squash,no_subtree_check,no_acl,anonuid=501,a nongid=501) на сервере.

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

Хехе! Я знаю этот фетиш. Покажи чудиле слово Promise и он начинает копытом стукать. Действует как тряпка на быка. Эффект 100%.

> А можно имена железок в студию? :)

Можно, конечно. Linksys SD2005 - первая (вообще не держит), NetGear GS605EE - вторая (часть ревизий не держит) и D-Link DGS-1008D (третьей или четвертой ревизии - в общем той, которая уже держит jumbo frames согласно информации от dlink) - с сюрпризом в виде падения пропускной способности при их использовании.

Я так и не понял, можно ли за небольшие деньги купить хороший свитч, который это все умеет. Посматриваю на TRENDnet. 3com жаба душит покупать, хотя я уже столько на эти свитчи потратил, что может лучше бы сразу купил свитч за $200 ;)

> жесткое урезание количества потоков nfsd на сервере и опция sync при монтировании на клиенте

+1, но "async" на клиенте.

> Хехе! Я знаю этот фетиш. Покажи чудиле слово Promise и он начинает копытом стукать. Действует как тряпка на быка. Эффект 100%.

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

>3com жаба душит покупать, хотя я уже столько на эти свитчи потратил, что может лучше бы сразу купил свитч за $200 ;)

Знаешь, еще в гигабитных недорогих свичах 3com какие то проблемы с термодатчиком (видимо таки с ним, хз, я не электротехник и с паяльником лезть не хочу) бывает, там кулер не всегда включается... и он перегревается и виснет, суко, это правда на обычных 12портовых я такое замечал, может брак просто попался, хз, так что если они так себя будут вести - туда кулер надо нормальный и что бы постоянно молотил.

а цпу да, жрет жестко :-((

> надеюсь, что это теперь сэкономит кому-нибудь время ;)

NFS дистрибутивный RHEL'овский (т.е. без возни с патчами и т.п.)?