Материнки надо брать не из нижнего сегмента, тогда там будет штук 8-10 портов на самой матери и еще внешних для esata.

Там в лучше случае будет 6 нормальных портов, а остальные - днище jmicron/marwell. Тем более, по цене эти нормальные материнки - не для нищебродов, проще на ибее взять интерпрайз прошлых дней.

днище jmicron/marwell

В каком смысле «днище»? В софтом рейде всё упирается в диски/шину, CPU, но никак не в контроллер, имхо (если дрова есть нормальные).

Потом, если речь идёт о домашнем применении, то, даже если всё упрётся в контроллер, производительности за глаза.

Даже по самому быстрому интернету 4к фильм ты будешь выкачивать от 2-ух часов.

И что? Скачал, посмотрел, удалил.

В каком смысле «днище»?

Во всех. Они режут скорость и i/o. Хотя marvel умеет какой-никакой аппаратный рейд, он такой плохой, что никуда не годен.

В софтом рейде всё упирается в диски/шину,

Софтовый рейд вообще пионэркая забава. Его обсуждать-то серьёзно не интресно. В голову создателя он упирается.

Потом, если речь идёт о домашнем применении,

Домашнее применение - одно из самых непростых. Торрент+плеер+какое-нить копирование грузит массив получше многих корпоративных серверов. Или у вас там «выключи торрент, мне поиграть надо ?» считается нормой ?

это дома то запасной 24-портовый? спасибо, поржал. за эти деньги можно второй массив собрать для бекапа и еще на падших женщин останется

это дома то запасной 24-портовый?

Ну, да. Их относительно не дорого на ибее продают.

спасибо, поржал. за эти деньги можно второй массив собрать для бекапа и еще на падших женщин останется

Да уж ладно. Вот прям сейчас. http://www.ebay.com/itm/ARECA-ARC1280ML-CONTROLLER-CARD-512MB-MEMORY-/3818290... Я брал дешевле в 2.5 раза.

Софтовый рейд вообще пионэркая забава

Ооо, Димон, это про тебя: https://www.youtube.com/watch?v=6O9diQ8SjNs

Ладна, по ценам был не прав. Однако хардовые рейды все равно сливают по всем параметрам кроме скорости (которая дома имхо не нужна), а работает ли данный в HBA я хз.

Софтовый рейд вообще пионэркая забава

Вот теперь точно поржал

Торрент+плеер+какое-нить копирование грузит массив получше многих корпоративных серверов

Ну вот у меня софт отдает до 5 гбит/с, одновременный запуск всего вышеперечисленного ничего страшного не делает, все работает плавно и красиво. Вывод - ты врешь. Впрочем, как всегда.

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

Хз насчёт скорости и юзабельности, но оно у меня как / уже давненько на Fedora. И как-то похер, проблем не испытываю.

P.S. *Комментарий уровня домохозяйки*.

Как может сливать спец. железка с xor процессором

За такой ответ меня жутко пропесочили как-то на собеседовании, я потом покурил мануалы. Современный процессор НАМНОГО быстрее твоего дохлого встроенного процессора. А уж по IOPS'ам твоя железка давно позади планеты всей.

Сколько пытался юзать софт рейд, всегда плакал от скорости.

Так может ты того, дурачок действительно, и не дожидался первоначального ребилда рейда? :))

Там в лучше случае будет 6 нормальных портов, а остальные - днище jmicron/marwell.

Этого «днища» более чем хватает для хранения данных и раздач их в локалку и на торренты. Иные NAS еще и похуже будут. Или ты SSD собрался втыкать для объема?

ext3

И час ждать, пока полтора терабайта прочекаются, ага...

Да кому нужен твой 2016

Если совсем скоро наступит Год Линукса на дескстопе!

Даже Backblaze Marvell'ы ставят и не жужжат, надо им Димку захантить, он им поставит контроллеры 10-тилетней давности :)

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

Скорость чтения и записи у всех ФС похожи, а при желании можно накрутить опциями

А вот со стабильностью у btrfs вопрос, раньше она не раз у меня падала на ровном месте

С другой стороны прошло много лет, наверняка до оптимума допилили

Иные NAS еще и похуже будут

«Иные NAS» - это не ориентир.

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

А меня на собеседовании как-то пропесочили за то, что я не знаю, что такое «недокументированные возможности Windows NT». До сих пор не знаю, что это. 15 лет прошло. Догадываюсь только, ЛОЛ.

Современный процессор НАМНОГО быстрее твоего дохлого встроенного процессора.

Это надо показать цифрами.

А уж по IOPS'ам твоя железка давно позади планеты всей.

niet.

А как там со стабильностью на самом деле? Пойдёт для обыкновенного офисного файл-сервера с <50 одновременных пользователей? Можно ограничиться снапшотами и не делать бекапы на отдельный хард (при условии надёжного железа)?

Это надо показать цифрами.

Самостоятельная работа. Hint: под линуксом при загрузке модуля raid456 показываются кое-какие циферки в dmesg.

niet.

Сливает, по-полной.

Да ты прям мажор с блюреями.

Ставлю ОС на отдельную флешку с btrfs с субволюмами и сквозной компрессией.
Ну а данные на отдельный диск, сейчас тоже в btrfs,
но если тебе нужна скорость, то вроде xfs называют?
Но на ней легко потерят данные, хотя вроде там сейчас что-то делают.

Что такое «толстый zraid»?

Как минимум хотя-бы с десяток SAS HDD (и еще несколько запасных) Или 2-3 SSD хороших по 1Тb, скажем (хотя с SSD скорость вообще непредсказуемая наверное будет). Но надо что-то возможно и более серьезное, чтобы скорость с ZOL была приличной и не сильно хуже той же raw xfs, или чтобы разница уже была очень несущественным фактором, на фоне фишек ZFS.
На плохом железе из одного диска/SSD ZOL медленней в 3-5 раз чем xfs/ext4/btrfs у меня (что на запись, что на чтение), и это крайне печально. Отключение prefetch дает максимум лишних 5-10MБ/c и иногда лишних 20MБ/C. Так, что это не просто сказки, zfs (zol, в данном случае) реально очень тормозит. Еще есть такие странности, что кусок zfs на xfs на том же HDD выделенный через truncate в конце диска одинакового размера с разделом zfs вначале подключенный к пулу скорость выдавал даже большую. Но мне все равно zol очень нравится, вот только в некоторых местах из-за этого пришлось от него избавляться в сторону brtfs. И BTRFS которую многие ругали и я сам избегал, очень приятно удивила, особенно на SSD и после balance, графики io очень красивые получаются (в хорошем смысле, более ровные). А вот с тестами не все ясно, особенно, на чтение/запись через тот же fio. Возможно для фс с cow свои тонкости есть, потому-что BTRFS подозрительно хорошие результаты показывает, я больше верю графикам с мониторинга, чем синтетике в данном случае. Да с ZFS (zol, в данном случае) я еще заметил, что когда копируешь сначала скорость очень медленная, потом более нормальная или почти приличная, а концу копирования скорость опять падает. Для себя сделал пока вывод, что ZFS это суровый энтерпрайз, и без raidz и вложения существенных для меня денег не очень интересно. Даже ZFS пул нужно обдумывать изначально, нельзя так просто все подряд туда подключать, как-бы это удобно не было, и того не хотелось, хотя когда нет места и не на такое пойдешь.

Ну я снапшоты всей фс не делаю, у меня только снапшоты контейнеров. И в данном случае у меня BTRFS как lxd backend. C BRTFS наверно проблемы со стабильностью только если у тебя дистрибутив какой-то очень старый или наоборот роллинг релиз какой-нибудь. Например в trusty btrfs считается experimental, и даже когда ты форматируешь через mkfs оно без «skinny-metadata», а вот если ты обновился до xenial например, то тебе надо «skinny-metadata» включить через brtfstune (причем только на отмонтированной фс), а потом сделать rebalance. «no-holes» я не включал, но не думаю, что это сразу все испортит. Там в wiki у них написано, с чем нужно быть осторожней. Бэкапы нужны по любому, какая фс бы у тебя не была, но конечно смотри по уровню ответственности, если все потерять это окей, то тогда да, бэкапы не нужны.

в wiki у них написано, с чем нужно быть осторожней

А можно конкретнее или ссылку?

«Иные NAS» - это не ориентир.

Еще как ориентир. Из плюсов NAS для дома, по сравнению с системником, я пока вижу только меньшие габариты и большую тишину, впрочем системник тихим тоже сделать можно.

Плюсы системника: больший объем, гибче в конфигурировании и дешевле.

https://btrfs.wiki.kernel.org/index.php/Mount_options
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfstune
https://btrfs.wiki.kernel.org/index.php/SysadminGuide
http://logan.tw/posts/2015/05/17/grub-install-and-btrfs-root-file-system/
https://unix.stackexchange.com/questions/tagged/btrfs
Да в моем случае понабилось еще квоты включить.
Много разных ссылок даю, потому-что для меня самого BTRFS достаточно свежее «открытие», поэтому кое-что осталось в закладках.

На плохом железе из одного диска/SSD ZOL медленней в 3-5 раз чем xfs/ext4/btrfs у меня (что на запись, что на чтение), и это крайне печально.

«Обычные SATA-диски» это достаточно плохое железо? У меня с ним тоже всё ок. Корефану на хецнерском днищевом железе настроил ZoL под довольно нагруженный проект на 4 SATA-диска, он ссыт кипятком от него.

Стабильность - превосходно, несколько отключений электричества во время компиляции пакетов - жив и здравствую (чем не мог похвастаться с ext4). Нет необходимости в fsck, таковы уж особенности btrfs - превеликий CoW. С опцией compress=lzo работает намного быстрее, чем ext4: скорость записи гигабайта нулей в файл - 780Мб/с, скорость записи гигабайта случайных данных в файл - 100-150Мб/с. Это учитывая, что тестировалось на HDD WDC Blue, которому уже 7 лет. К сравнению, ext4/ntfs и прочие на этом HDD больше 90Мб/с никогда не давали ни в одном из тестов. А на SSD, судя по бенчмаркам, btrfs работает ещё более эффективно. Не терпится уже скорее поменять ноутбук на тот, в котором будет SSD. Снэпшоты - чудная вещь, если любишь эксперементы без переустановки ОС. Дефрагментация - работает быстро и хорошо, ни одной ошибки за ~70 раз. Есть только один минус - grub2 не умеет записывать ENV параметр на btrfs (ай ай ай), так что SAVE_DEFAULT=true работать не будет. Во всём остальном - замечательная ФС.

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

Copy on Write - CoW - Копирование при Записи. Это киллер-фича btrfs. Если ты копируешь файл и при этом не изменяешь его, то 2 копии занимают место как один файл. Но если начинаешь редактировать одну из копий- дозаписываются только изменённые куски. Чем-то напоминает zsync в интернете, только в мире ФС. Это я так, очень образно описал, но суть та же. Снэпшот - снимок, почти тоже самое, только немного по другому. Допустим, ты собрался обновляться - разумнее сделать снэпшот и обновиться, а если что-то пойдёт не так - просто загружаешься в стабильный снимок и продолжаешь свою работу. Это уже чем-то напоминает «Точки восстановления» в Windows, только во много раз эффективнее и в бесконечное число раз быстрее (в прямом смысле).

Фильмы хранить.

А зачем их хранить? Они на рутрекере хранятся.

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

Copy on Write - CoW - Копирование при Записи. Это киллер-фича btrfs. Если ты копируешь файл и при этом не изменяешь его, то 2 копии занимают место как один файл. Но если начинаешь редактировать одну из копий- дозаписываются только изменённые куски.

Нет, это так не работает. Подучи матчасть и не распространяй 4.2.

Кстати, собственно вот страничка, со статусом стабильности btrfs. Как видим - для десктопа и большинства серверных конфигураций она полностью готова.

Толсто.

Defrag mostly OK

Compression mostly OK

Device replace mostly OK

Quotas, qgroups mostly OK

Для сервера это непригодно.

Итак...

Копирование при записи (CoW)

Главная идея copy-on-write — при копировании областей данных, создавать реальную копию только тогда, когда в одну из копий производится операция записи.

А теперь исправь меня. В упор не вижу, где я не прав))

Ты не прав в том, что применяешь общее определение к частному случаю.

Когда говорят «copy-on-write» применительно к файловым системам, имеют в виду прежде всего механизм обеспечения целостности, противопоставляемый журналированию и впервые применённый в файловой системе WAFL. Снимки файловой системы (snapshots), безусловно, работают как обобщение идеи copy-on-write, но ей не являются. Копирование также можно реализовать как обобщение снимков, но интерфейс системных вызовов Linux (не имеющий отдельного системного вызова для копирования файлов, по крайней мере стандартного) этого сделать не позволяет.

Уточнение: системный вызов copy_file_range(2), появившийся в Linux 4.5, допускает реализацию на основе идей copy-on-write (и, скорее всего, в btrfs так и реализован), но он является нестандартным (не входит в POSIX) и очень новым, поэтому могу предположить, что в реальном мире его используют в ~0 случаев.

Btrfs можно будет считать готовой для сервера, когда она станет дефолтом в CentOS/Debian, для десктопа — в Fedora/Ubuntu.
И то я бы подождал год-два, как минимум, пока любители экстрима отловят фейлы.

http://www.vpnbook.com/webproxy

Согласен, товарищ анонимус, ты ответил довольно толсто и поверхностно.

Разложу по полочкам:

Defrag mostly OK

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

Compression mostly OK

Говорит о том, что не всё, что было запланировано, на данный момент реализовано. Конкретнее - сейчас на стадии реализации поддержка нового эффективного метода сжатия lz4 (lz4hc). В это же время lzo и zlib превосходно выполняют свои функции и полностью стабильны. Также написано, что авто-восстановление при использовании сжатия может не произойти, но лишь при определённых условиях (которых мне так и не удалось воспроизвести, даже учитывая постоянные вырубания электричества).

Device replace mostly OK

На kernel.org написано, что может зависать на устройствах, с плохими секторами (вспоминаю как дерьмово с плохими секторами работал ext[2-4] и громко смеюсь).

Quotas, qgroups mostly OK

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

• To get accurate information, you must issue a sync before using the qgroup show command.
• The qgroup show command is missing some information, for example you cannot see which subvolume is part of a parent qgroup.
• Creating a qgroup from an existing directory will show a 0 usage until a full filesystem quota rescan is issued.
• Using btrfs subvolume delete will break qgroup unshared space usage.
• After deleting a subvolume, you must manually delete the associated qgroup.

Что говорит о том, что работает почти стабильно, но надо быть более внимательным, думать, прежде чем делать и проверять, что же было сделано.

А вообще, все эти пункты - полагаю, «детские болезни», которые, если учесть бешеные темпы развития btrfs, успешно излечатся к выходу linux 4.9LTS в середине декабря этого года.

Примерно это же я и имел ввиду) Просто предпочитаю объяснять легко, популярно и максимально доходчиво. Насколько понимаю, в btrfs для сохранения целостности используются транзакции. Изменённые данные записываются в неиспользуемое пространство, а как только данные будут успешно записаны, эти, допустим, 2 сектора «меняются ролями»: использовавшийся - помечается как неиспользуемый, и доступный для новой записи, а второй, соответственно, наоборот. Верно?

linux 4.9LTS

4.10

Верно?

Да, верно.

Просто предпочитаю объяснять легко, популярно и максимально доходчиво.

Но из твоего объяснения складывается впечатление, что btrfs магически (без каких-либо дополнительных усилий) ускоряет операции копирования файлов, делая их почти «бесплатными». А это не так.

Нет необходимости в fsck, таковы уж особенности btrfs

Разработчики в этом не очень уверены:
https://btrfs.wiki.kernel.org/index.php/Btrfsck

А на SSD, судя по бенчмаркам, btrfs работает ещё более эффективно.

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

Не знаю, упоминали тут или нет, но в btrfs можно отформатировать весь диск

Это и с ext можно. Даже, наверное, с ext2 было можно.

Это киллер-фича btrfs. Если ты копируешь файл и при этом не
изменяешь его, то 2 копии занимают место как один файл.

Эта киллер-фича называется дедупликация. И она в онлайне пока в стадии разработки.

Конечно же не так, ловкость рук разработчиков и никакой магии. Я описывал немного другую ситуацию, которую можно воспроизвести примерно по такому сценарию:

• На btrfs разделе есть файл 4Гб размером
• Проверим занятое/свободной пространство на этом разделе
• Скопируем тот 4Гб файлик в пределах данного раздела
• Проверяем свободное место ещё раз. Видим, что его стало меньше, но уж точно не на 4Гб, а где-то в пределах нескольких Мб
• Изменим немного скопированный файл, перезапишем его крайние 512Мб
• Снова проверяем занятое пространство раздела - оно увеличилось как раз примерно на 512Мб

Скопируем тот 4Гб файлик в пределах данного раздела

Чем копируем?

Не работает и работать не будет, о чём я тебе и говорю

$ cd /mnt/data

$ dd if=/dev/urandom of=test bs=1M count=1024
1024+0 записей получено
1024+0 записей отправлено
1073741824 байт (1,1 GB, 1,0 GiB) скопирован, 28,0825 s, 38,2 MB/s

$ df -BM /mnt/data                           
Файловая система Тип   1M-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/sdb         btrfs  7630917M     2552133M 4215509M           38% /mnt/data

$ cp test test2; sync

$ df -BM /mnt/data
Файловая система Тип   1M-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/sdb         btrfs  7630917M     2553161M 4214485M           38% /mnt/data