Re: Нюансы взаимодействия ZFS

[Dmitry Kulagin]

Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS
pool лучше поверх LUKS, а не наоборот.
LUKS почти не вносит оверхед.
А кэширование записи диска всегда возможно включить вручную (как и
подобрать размер блока, который у ZFS, к тому же, переменный).


А после этого возникает закономерный вопрос: а зачем вам zfs?
Вы только что избавились от одного из самых больших плюсов zfs и
начали работать с device mapper, ну так продолжайте с ним работать,
lvm и вперед, зачем плодить сущности?

Re: grub не загружается с ext4

[Dmitry Kulagin]

Для загрузки с gpt диска с помощью grub-pc вам надо создать пустой 
раздел размером 1-2 МБ
тип BIOS Boot и устанавливать grub на весь диск, без этого современные 
BIOS не грузятся

с gpt диска.
Device Start    End   Sectors   Size Type
/dev/sda1   2048   4095  2048 1M BIOS boot
/dev/sda2   4096 229375    225280   110M EFI System
/dev/sda3 229376  393365503 393136128 187,5G Linux filesystem
/dev/sda4  393365504 1172123534 778758031 371,3G Linux filesystem
Такая разбивка диска позволяет грузиться и с efi и с legacy bios (в 
случае проблем).

Схема каталогов после монтирования меняться не должна, т.е.
--Создаете раздел---
update-initramfs -u -k all -t
tar -C /boot -cf /boot.tar *
mount /dev/disk/by-id/ata-Micron-partN /boot
tar -C /boot -xf /boot.tar
grub-install /dev/disk/by-id/ata-Micron
update-grub
umount /boot

19.03.2018 23:31, artiom пишет:

Поставил Stretch на шифрованный ZFS root, образующий зеркало на двух SSD.
На SSD GPT с тремя разделами типа 0x83: ext4 - /boot, luks1, luks2.
Всё более ли менее, но grub-pc не хочет грузиться с отдельного ext4
раздела ни в какую.
Делаю так:

- tar -C / -cf boot.tar
- Монтирую /dev/disk/by-id/ata-Micron-part1 в /boot
- tar -C -xf boot.tar
- update-initramfs -u -k all -t
- update-grub.
- Делаю grub-install /dev/disk/by-id/ata-Micron .
- umount /boot

Проходит, всё ok.
Перезагружаю - облом.
Чёрный экран, и мигает курсор: меню граба нет.

Вариант два:

- grub-install --boot-directory /

Вариант три:

- Монтирую /dev/disk/by-id/ata-Micron-part1 в /mnt
- mkdir /mnt/boot
- mount -bind /mnt/boot /boot
- Дальше всё тоже самое.

Не работает.

Самое смешное, что когда я ничего не монтирую, граб ругается на то, что
я хочу установить его для загрузки с шифрованного раздела и требует
установить опцию в /etc/default/grub.

После установки таковой, всё грузится, разблокируя _оба_ диска зеркала
на этапе запуска граба, запрашивая пароль, причём грузится с /boot на ZFS.
При этом, установка grub разрушает первый ext4 раздел.
Что для меня было открытием: grub может грузиться напрямую с
шифрованного раздела.

Но не работает загрузка с обычного ext4.
Что я делаю не так, по пунктам, и как это исправить?

Re: К знатокам NAS (про ZFS)

[Dmitry Kulagin]

Оптимистично.
Я уже целый день пытаюсь настроить шифрованный ZFS root.
И на Stretch, оно не очень дружит с cryptsetup (матерится на то, что
root определить не может).


Надеюсь, вы не пытаетесь установить zfs на шифрованные диски,
рекомендуется делать только обратную процедуру. Кстати, zfs, помимо
initramfstools, поддерживает и dracut, который более продвинут...

Re: научите systemd!

[Dmitry Kulagin]

А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих,
так еще и мертвое. Что вы в нем такого супер-пупер находите?
Память жрет как свинья помои? Причем память подай с ECC и вагон.
Компрессия? Восстановление данных после сбоя?
Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все 
места?

Так нет же ничего иного, если нужно больше, чем просто фс на диске: 
RAID, ssd кеш,
снапшоты, компрессия, блочные устройства с thin provisioning в общем 
пространстве
данных, дедупликация для backup; ну кроме btrfs, которая не умеет часть 
из выше перечисленного.
MDRAID и LVM в Linux не умеют Write Barriers сквозь себя пропускать от 
файловой
системы, и я замучился чинить xfs после отключений питания, а fs 
непосредственно

на диске без lvm - чинить не надо...

О systemd! Никто не знает, почему при установке пакета, который 
добавляет и запускает
новый сервис systemd, компьютер виснет наглухо с запущенными виртуалками 
kvm, если

их остановить предварительно, то все работает, и без systemd все работает?..

Re: Снова о ZFS

[Dmitry Kulagin]

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


Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента.


Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД
хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на
запись по умолчанию, в режим только кеш на чтение она может переводиться 
только

в аппаратных рейд контроллерах, потому как остальным ОС это не надо,
они пользуются командами сброса кеша в энергонезависимую память
для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD
диски для ZIL, на них этот коммит относительно долгий, а запись ZIL -
это непрерывный коммит, и кеш в такой ситуации не в состоянии
что-либо ускорить. А потери данных при перебое питания, которые
обсуждаются по ссылке будут всегда, вопрос только в том, что при 
неадекватной

поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого перебоя
питания придется делать проверку файловой системы.
И фича сброса кеш памяти она, насколько я помню, не фича пользовательского
и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2
(ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со 
времен SCSI)

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

Re: Снова о ZFS

[Dmitry Kulagin]

Вообще-то размер ZIL рекомендуют порядка нескольких ГБ, зачем там 150 ГБ 
- не очень понятно...


13.01.2018 21:56, artiom пишет:


10.01.2018 18:25, Sergey Matveev пишет:

*** artiom [2018-01-10 18:18]:

Если же установлена опция sync=disabled, произойдёт ошибка записи?

Если опция установлена, то не, ошибок не будет, но и fsync-а по факту не
будет происходить.


Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на
диске нет?
В чём тогда разница?

Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена
система (или два SSD), и на которые будет вынесен ZIL.
Хочу сделать два одинаковых GPT раздела на каждой из SSD.
На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ.
Оба раздела будут шифроваться стандартным ZFS шифрованием.
С первого раздела (миррора) должна грузиться ОС.

Эта конфигурация жизнеспособна?

Re: Снова о ZFS

[Dmitry Kulagin]

15.01.2018 00:25, artiom пишет:


Вот это наталкивает на мысли (пусть оно и для ZIL):
"After a crash, ZFS will attempt to replay the ZIL contents. SSDs
themselves have a volatile write cache, so they may lose data during a
bad shutdown. To ensure the ZFS write cache replay has all of your
inflight writes, the SSD devices used for dedicated ZIL devices should
have power protection. HGST makes a number of devices that are
specifically targeted as dedicated ZFS ZIL devices."

Отсюда:
http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-iii-pools-performance-and-cache/




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

Re: ядро и nvidia

[Dmitry Kulagin]

Вы можете просто из Jessie без бекпортов установить 340-ой драйвер, у 
меня это работало

несколько лет назад. Насчет бекпортов не знаю, не пользовался.
Если Вы просто сделаете dist-upgrade из Jessie до Stretch, то у вас 
гарантированно не заработает
сразу, потому что текущий драйвер nvidia перестал поддерживать эти 
карты, а пакеты 340-го
в Stretch были переименованы из nvidia-* в nvidia-legacy-340xx-*, 
соответственно после апгрейда
вам придется удалить текущий и поставить legacy-340. Доустанавливать 
ядро и хедеры

или нет зависит от того, установлены ли у вас сейчас пакеты:
linux-image-amd64
linux-headers-amd64
или *-686, если у вас 32-бит. Если установлены, то dist-upgrade 
доустановит новые версии из Stretch.
После апгрейда до Stretch у вас может сломаться Plasma. И вообще kde 
как-то неадекватно может
работать на пропроетарных драйверах Nvidia. У меня были разные артефакты 
изображения.

Починились переходом на MATE, на котором я пребываю до сих пор...
После апгрейда перед перезагрузкой в новую систему не забудьте добавить 
задержку в граб,
чтобы иметь возможность загрузится в режиме root (опция ядра single) или 
сразу в
командную строку (init=/bin/sh), если пойдет все плохо (переход на 
systemd все таки)...



31.10.2017 21:53, Ivan Petrov пишет:

На днях проверю еще раз.
Как лучше, установить 340 из бекпортов на jessie с новым ядром оттуда 
же, или накатить stretch с 340?
По второму варианту вопрос: надо сразу headers + dkms доустановить или 
dist-upgrade c stretch репозиторием сам догадается?

Re: ядро и nvidia

[Dmitry Kulagin]

NVIDIA Corporation GT200 [GeForce GTX 260] (rev a1)

работает на Stretch c 340-ым драйвером (как и на текущем buster).
Вы точно пробовали Stretch с 340-ым?


27.10.2017 20:45, Ivan Petrov пишет:

Я попробую.
Но на stretch они не заработали с моей карточкой.
поэтому я на jessie летом и откатился

27.10.2017 22:46, Павел Марченко пишет:
у 340-го драйвера тоже есть поддержка 200-й 
серии(http://www.nvidia.com/download/driverResults.aspx/123703/en-us)

Может стоит его попробовать?

27 октября 2017 г., 18:07 пользователь Ivan Petrov > написал:


    jessie

    Первоначальная проблема:
    ---
    обновил jessie с бекпортов до ядра 4.9.0.0 bpo3
    слетели драйвера nvidia .
    В результате сейчас на драйверах 304хх система грузит Х-ы на
    ядре 3.2.0.4.
    На 4.9. их установка + dkms + headers приводит к белому пустому
    мигающему курсору на экране вместо gdm3

    27.10.2017 15:05, Andrey Jr. Melnikov пишет:

    Ivan Petrov > wrote:

    А топ-постить - это всех пользующихся веб-интерфейсом 
заставляют?


    У меня в папке share xorg нет вообще
    есть:
    gnome-shell
    icc
    sounds


    debian какой версии?

    26.10.2017 22:04, Andrey Jr. Melnikov пишет:

    Ivan Petrov >
    wrote:


    Это в винде "не грузиться", у нас - есть логи.
    Содержимое /var/lib/gdm3/.local/share/xorg/Xorg.0.log
    показывай












--
В смысле осмысления бессмысленного смысл тоже имеет определенную 
осмысленность!!!

Re: Контроллер 12Gb/sec на десктопной плате

[Dmitry Kulagin]

Привет!

Судя по описанию на этой плате 3 слота куда можно воткнуть этот контроллер:
1 x PCIe 2.0 x16 (x4 mode, (Black)) - у этого слота максимальная 
пропускная способность
16 Гб/с, но он делит ее со всеми остальными PCIe 2.0 х1 слотами, а также 
со всеми
остальными устройствами (usb, audio, ethernet, etc) он делит DMI шину с 
пропускной
способностью 20 Гб/с. х4 режим этого слота надо включать в BIOS, х1 - по 
умолчанию.
2 x PCIe 3.0/2.0 x16 (x16 or dual x8) - в этих слотах контроллер может 
достигнуть своей
максимальной производительности около 63 Гб/с (PCIe 3.0 х8) с 
процессором intel core
3-го поколения или 32 Гб/с (PCIe 2.0 х8) с процессором 2-го поколения. 
Хватит этого или

нет зависит от количества дисков и их производительности...


10.10.2017 13:00, АвтоОлимп / Андрей Н. Прокофьев пишет:

Доброго дня.

Немного оффтоп, так как вопрос не совсем связан с тематикой рассылки.

Есть у меня рабочий ПК на плате Asus SABERTOOTH Z77 (чипсет Intel Z77).
Нужно на нем сделать производительную дисковую подсистему (требуется для
выполнения ряда задач). Для этого уже есть 12Gb/sec raid контроллер
ASR81605ZQ и соответствующие SAS диски.

Будет ли эта связка (мат. плата+контроллер) работать с пропускной
способностью 12 Gb/sec? Или же нужен PCI-E v3?

Re: NAS

[Dmitry Kulagin]

14.07.2017 10:42, Sergey Matveev пишет:

*** Andrey A Lyubimets  [2017-07-14 05:35]:

Под ZFS Вы отключаете кэш на дисках? Или это в контексте аппаратного рэйда?

Вообще конечно же отключить его не мешало бы (но мне лень :-)). Но что
будет если не отключить? Если какая-то часть данных при не запишется
внезапно, то всё-равно в них самым последним элементом идёт überblock,
создающий checkpoint. Если его не записать, то просто не будет
checkpoint-а. С точки зрения целостности системы -- абсолютно ничего
страшного. Часть ZIL-а при этом может записать, а может и нет -- просто
будет потеря данных за какое-то небольшое время (несколько секунд на
практике, по идее). Если "разсинхронизация" из-за кэша на дисках
произойдёт внутри массива, то после подключения pool всё-равно диски
будут заresilverены до того, у кого самый свежий checkpoint+ZIL успел
записаться. То бишь включённый кэш просто неприятен будет тем что данные
даже после fsync потенциально могут пропасть, но с целостностью всего
остального проблем не будет.


Информация из дискового кеша пишется на поверхность в произвольном
порядке (точнее в том, который будет быстрее с точки зрения контроллера),
поэтому последний блок может записаться раньше предыдущих.
И ни одна мне известная файловая система не переживает такую ситуацию
без fsck. Чтобы решить эту проблему, в ядре linux существует механизм
write barriers, со стороны диска поддержка появилась, кажется, в
спецификации SATA2 (в последних scsi и в sas она уже была вроде),
но поздние SATA1 диски тоже могут его поддерживать.
Заметная часть SATA2 дисков, однако, могла иметь ошибки в реализации или 
вообще
не поддерживать cache flash. В ядре есть список таких дисков. И, если вы 
видите в логе

сообщение типа: Mounting  filesystem ... barriers disabled 
- это повод задуматься о смене диска.
ZFS поддерживает данную технологию, и последнее обсуждение, которое
мне удалось найти по этой теме, относится в февралю 13-го года.
Я даже видел обсуждения, что в рейд конфигурациях zfs настолько хорошо 
оптимизирует
запросы к дискам, что производительность дискового кеша выглядит, как 
почти при

суммарном объеме кешей всех дисков.

Re: NAS

[Dmitry Kulagin]

Потому что, нет ZFS?


Потому что системы до Windows 7 включительно не поддерживали
software raid5, только серверные версии, а загрузку с програмных рейдов
не поддерживают вообще никакие Windows, то есть нужен
еще один системный диск, помимо дисков для рейда, и переустановка
системы при сбоях системного диска.

Re: zfs on linux

[Dmitry Kulagin]

Если вы создавали все фс по хелпу, то ваша проблема закономерна,
в хелпе zpool создается с опцией для файловой системы по умолчанию:
-O canmount=off, а потом zfs c canmount=noauto. Для вашего случая,
когда нужны отдельные фс на /usr и /etc, надо (да и в текущих глюках
systemd для всех) полностью формировать систему (монтировать
/var /usr /etc и т.д.) еще на этапе initrd поэтому все эти фс да и / тоже
желательно создавать с опцией canmount=on, и в /etc/default/zfs с опцией
ZFS_MOUNT='yes'. Отложить монтирование, и как в классике управлять
/home, /opt, /srv и т.п. с помощью /etc/fstab, можно указав при создании фс
опцию mountpoint=legacy.

09.07.2017 18:56, Alex Kicelew пишет:

On 07/09/17 18:52, Vasiliy P. Melnik wrote:

Про то, что отдельный /usr постепенно отламывают, даже в информации о
выпуске stretch было упомянуто:

Та при нынешних объемах дисков оно просто бессмысленно. Я вообще делаю бут,
потом все остальное нарезаю лвм-ом, в лвм-е делаю 3 партишина - root и
var_log по 20 гигов, swap на 2 гига. Если под что-то надо место - создаю с
минимальным размером, потом добавляю, если надо. Ресайз на увеличение
работает на лету, на уменьшение - проблемно.

Проблема в том, что на ноуте-то мне это не важно, но я планировал
поставить zfs и на большую машину, где небольшой рейд. Бэкапить zfs,
вроде, удобнее всего снапшотами, но снапшоты делаются на fs. Бэкапить
/etc мне нужно, а вот полный бэкап всего рута вместе с /usr -- нет.

Re: zfs on linux

[Dmitry Kulagin]

06.07.2017 16:31, Alex Kicelew пишет:

On 07/06/17 15:41, Dmitry Kulagin wrote:

zfs send|receive переносил установку  на еще 9, соответственно
процедура создания пулов, фс и установка grub прошла 10 раз
без проблем, загружался и устанавливал с флешки, на которой был

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

Может grub-pc из Stretch попробовать?..

Re: zfs on linux

[Dmitry Kulagin]

2 месяца назад устанавливал по этому хелпу Debian Stretch
(на тот момент testing) на первую машину, а потом с помощью
zfs send|receive переносил установку  на еще 9, соответственно
процедура создания пулов, фс и установка grub прошла 10 раз
без проблем, загружался и устанавливал с флешки, на которой был
установлен все тот же, текущий на тот момент, Stretch. Во время
установки столкнулся с единственной проблемой: из-за systemd
невозможно было отмонтировать новый корень, он почему-то его
не отпускал, поэтому приходилось после перезагрузки, снова
загружаться с флешки и делать:
zpool import rpool
zpool export rpool
и перегружаться снова уже в новую систему.
Кстати, примерно год назад или больше в тестинге zfs + systemd
комбинация была вообще сломана: при перезагрузки системы
zfs вообще не отмонтировали, интересно, как оно в Jessie+backports?
А Вы старый диск заного переразбивали или новый, чистый? Для старого
иногда надо перезагружаться, если его какой-нибудь udisk2 или аналог
зацепит?

06.07.2017 13:19, Alex Kicelew пишет:

Hi

А есть ли кто-нибудь, сидящий на сабже? Попробовал установить по
https://github.com/zfsonlinux/zfs/wiki/Debian-Jessie-Root-on-ZFS,
столкнулся с проблемой.

Отличия моей конфигурации от хаутушки: у меня отродясь на ноуте тестинг,
кроме того, сейчас он уже поверх stretch, а не jessy, как в хауту,
поэтому не делал никаких танцев с бубном вокруг jessie-backports, взял
zfs-dkms и zfs-initramfs из тестинга, груб оттуда же по умолчанию. Кроме
того, я не ставил систему с нуля, а полностью скопировал ее рсинком с
рабочей. Все остальное по хауту.

Проблема:

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

# grub-probe /
zfs

у меня же возвращается:

# grub-probe /
grub-probe: error: unknown filesystem.

-vvv выдает:

# grub-probe -vvv /new 2>&1 | grep -i zfs
grub-core/kern/fs.c:56: Detecting zfs...
grub-core/fs/zfs/zfs.c:1192: label ok 0
grub-core/fs/zfs/zfs.c:1007: check 2 passed
grub-core/fs/zfs/zfs.c:1018: check 3 passed
grub-core/fs/zfs/zfs.c:1025: check 4 passed
grub-core/fs/zfs/zfs.c:1035: check 6 passed
grub-core/fs/zfs/zfs.c:1043: check 7 passed
grub-core/fs/zfs/zfs.c:1054: check 8 passed
grub-core/fs/zfs/zfs.c:1064: check 9 passed
grub-core/fs/zfs/zfs.c:1086: check 11 passed
grub-core/fs/zfs/zfs.c:1112: check 10 passed
grub-core/fs/zfs/zfs.c:1128: str=com.delphix:hole_birth
grub-core/fs/zfs/zfs.c:1128: str=com.delphix:embedded_data
grub-core/fs/zfs/zfs.c:1137: check 12 passed (feature flags)
grub-core/fs/zfs/zfs.c:1878: zio_read: E 0: size 2048/2048
grub-core/fs/zfs/zfs.c:1899: endian = -1
grub-core/fs/zfs/zfs.c:595: dva=8, 1908c4f8
grub-core/fs/zfs/zfs.c:442: checksum fletcher4 verification failed
grub-core/fs/zfs/zfs.c:447: actual checksum 0082598c98ea
88a0c7f16104 005d0b808f380960 2f51aa5e372675ef
grub-core/fs/zfs/zfs.c:452: expected checksum 0004f5f43504
09254c38ba95 00087352d4a8f77f 0537bd0ed13060ad
grub-core/fs/zfs/zfs.c:1922: incorrect checksum
grub-core/kern/fs.c:78: zfs detection failed.

Гугление показало, что проблема известна с 12 года и тогда же запатчена.
А потом запатчена в 14. Но вплоть по 16 год встречаются сообщения с той
же проблемой и с вопросом: а делать-то че? Насколько я понял, проблема
может возникнуть на ровном месте при очередном апдейте, приведшем к
перегенерации загрузочной информации. scrub ее не лечит (у меня просто
не видит -- диск чистый), от типа чексумм, вроде, тоже не зависит (у
меня, правда, по умолчанию тот же флетчер4, но в нагуглившихся репортах
народ недоумевает: какой, нафиг, флетчер, если у меня везде sha-256).

Вопрос: сталкивался ли кто-нибудь с такой проблемой и известно ли, как
ее гарантированно вылечить (кроме встречающихся иногда (причем я не
понял, приведших ли к успеху) советов пересоздать пул, что в реальной
жизни не вариант)? Или же получается, что zfs на линухе пока что
нежизнеспособен?

На всякий случай:

zfs-dkms 0.6.5.9-5
grub-pc 2.02-1

Re: NAS

[Dmitry Kulagin]

24.06.2017 11:48, Sergey Matveev пишет:

*** Артём Н.  [2017-06-24 01:33]:

Xeon избыточен для NAS, мне так кажется (и это изделие позиционируется не как 
NAS, а как офисный сервер).
Для ZFS обязательна (крайне желательна) ECC память?
И нужен ли ZFS?

Лично я, поработав с ZFS уже три года, абсолютно ни с чем больше дела
иметь не хочу. И я говорю про домашние компьютеры, где 1-2 диска сейчас.
ECC -- чтобы не думалось, чтобы лучше "перебздеть". Xeon -- чтобы был ECC.
Самые младшие модели стоили довольно дёшево. Сейчас вот например на
nix.ru Xeon за 6.5 тыс.руб. вон можно купить -- я бы брал не раздумывая,
так как это плата за спокойствие (само собой с ECC памятью).


DDR4-ECC память поддерживают сейчас не только xeon, но и celeron G, 
pentium G и core-i3, но цена материнок все равно начинается от 10к 
рублей за c23x чипсет.

Re: NAS

[Dmitry Kulagin]

24.06.2017 13:02, Vasiliy P. Melnik пишет:
по текущей лицензии зфс я линуксе из коробки мы не увидим, но есть 
модули собранные.


Поддержки в установщике вроде еще нет, однако в только что вышедшем 
Debian Stretch

(в бекпортах для Jessie, тоже присутствует):
$ apt-cache show zfs-dkms
Package: zfs-dkms
Source: zfs-linux
Version: 0.6.5.9-5
Installed-Size: 7961
Maintainer: Debian ZFS on Linux maintainers 


Architecture: all
Provides: zfs-modules
Depends: dkms (>> 2.1.1.2-5), lsb-release, debconf (>= 0.5) | debconf-2.0
Pre-Depends: spl-dkms (>= 0.6.5.9)
Recommends: zfsutils-linux, zfs-zed
Description-en: OpenZFS filesystem kernel modules for Linux
 The Z file system is a pooled filesystem designed for maximum data
 integrity, supporting data snapshots, multiple copies, and data
 checksums.
 .
 This DKMS package includes the SPA, DMU, ZVOL, and ZPL components of
 OpenZFS.
Description-md5: c1e6760fc57260785aae3a4a3780013b
Homepage: http://www.zfsonlinux.org/
Section: contrib/kernel
Priority: optional
Filename: pool/contrib/z/zfs-linux/zfs-dkms_0.6.5.9-5_all.deb
Size: 1079744
MD5sum: 3d7a446b9dd3cc37ed26a2878362c5ab
SHA256: 0f947f09ed9e7c7244e1c77c46b2a182ec05796bf9b8a4d220475ba16affb554

Re: uefi + bios

[Dmitry Kulagin]

В мой вариант почти всегда работает, ваш не работает на старых
компьютерах, bios которых не знает про gpt или работает с ошибками.
http://www.rodsbooks.com/gdisk/bios.html
Флешкой с Debian я пользуюсь не так часто, но флешкой с официальным
дистрибутивом Windows 7 pro x64 модифицированным для загрузки в uefi
режиме и добавленными в инсталлятор драйверами USB 3.0, и построенной
по той же схеме, я пользуюсь на много чаще и пока не встретил
компьютер не способный загрузиться в uefi режиме для них обеих.
Для стационарных дисков вы правы, но флешка, на мой взгляд,
является исключением из этого правила.


26.05.2017 16:26, Коротаев Руслан пишет:

В сообщении от [Пт 2017-05-26 14:27 +0300]
Dmitry Kulagin <d...@ufp.appl.sci-nnov.ru> пишет:


Флешка переносной диск, как и cdrom, для них нет необходимости в gpt
разметке, достаточно создать первый mbr раздел и отформатировать его в
fat32, чтобы uefi с него загрузился.

Нет, флешка и переносной диск отличаются от cdrom. Чтобы сделать
загрузочный CD в UEFI-режиме, нужно прописать в нем загрузчик для UEFI,
например так [1].

Да, можно оставить MBR в надежде на то, что прошивка UEFI на нужном
компе поймет всё правильно (об этом всегда предупреждают [2]), но для
универсальности, лучше придерживаться правила UEFI — GPT, BIOS — MBR.

[1]: http://www.syslinux.org/wiki/index.php?title=Isohybrid
[2]: 
http://help.ubuntu.ru/wiki/руководство_по_ubuntu_desktop_14_04/особенности_установки_на_платы_с_uefi

Re: uefi + bios

[Dmitry Kulagin]

Флешка переносной диск, как и cdrom, для них нет необходимости в gpt 
разметке,

достаточно создать первый mbr раздел и отформатировать его в fat32,
чтобы uefi с него загрузился.

Сначала устанавливаете в bios режиме grub-pc в mbr, потом удяляете grub-pc
и ставите grub-efi (он ругается на недоступность efivars, что можно и нужно
игнорировать, поскольку вам не недо привязывать переносные устройства к
текущему компьютеру, и поэтому мы загрузились в режиме bios), затем 
копируете

EFI/debian/grubx64.efi в EFI/BOOT/bootx64.efi на fat32 разделе, который
проще всего монтировать как /boot. Чтобы, если хочется загрузится
с особенной системы, руками править в текстовом редакторе grub/grub.cfg.
Но это сломает обновление ядра на флешке внутри версий, вам придется
руками перед обновлением ядра удалить System.map, vmlinuz и initrd.img.

Сейчас grub всегда заменяет LABEL= и аналогочные переменные на
root=/dev/sdxx, что для переносной флешки очень неудобно, но можно
воспользоваться следующей ссылкой для устранения этой проблемы.
https://ubuntuforums.org/showthread.php?t=1530532


25.05.2017 20:43, sergio пишет:

Хочу поставить grub-pc на раздел EF02, и grub-efi на EF00.

Чтобы флешка грузилась на обоих типах машин.

Но эти пакеты друг с другом конфликтуют.

Выход только один --- всё сделать руками?

Re: software raid для бэкап-сервера?

[Dmitry Kulagin]

On Wed, Mar 23, 2016 at 05:04:58PM +0300, Dmitry Kulagin wrote:

Более 10-ти лет работаю по следующей схеме.
На каждом диске создается по 3 раздела - swap (1-4 GB), boot (500MB), sys.
Boot разделы собираются в raid1 и монтируются в /boot, первые 2 диска -
основные, остальные - spare.

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


Да




Аналогично для swap (при желании).

  Зачем своп на рейде делать? Данные там имеют ценность лишь при хибернейте,
  иначе рейд даёт лишь накладные расходы. Не лучше ли подключить несколько
  своповых разделов подряд, задав им приоритеты по вкусу?


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

Re: software raid для бэкап-сервера?

[Dmitry Kulagin]

Более 10-ти лет работаю по следующей схеме.
На каждом диске создается по 3 раздела - swap (1-4 GB), boot (500MB), sys.
Boot разделы собираются в raid1 и монтируются в /boot, первые 2 диска - 
основные, остальные - spare.

Аналогично для swap (при желании).
Sys разделы собираются в raid5, поверх создается lvm, в котором 
создаются /,/var,/home и т.д.
Проблем с загрузкой никаких, установщик как минимум 3 последних версий 
Debian позволяет создать

и загрузить такую систему.
Потеря системы за это время случилась всего один раз из-за бага в работе 
NCQ в дисках Samsung,
когда под высокой нагрузкой из рейда вылетел первый диск, а потом в 
процессе восстановления - второй.
В качестве современной альтернативы данной схемы можно предложить btrfs 
или zfs, в которых и фс,
и рейд, и lvm в одном флаконе. Последняя позволяет заметно ускорить 
работу при вынесении cache и log
на ssd диск, но сильно страдает от дефрагментации из-за COW, что, 
правда, не актуально для бэкап-

сервера. Установщик ее не поддерживает.
Jessie поддерживает btrfs, на одном разделе точно, но можно ли
выбирать рейд режимы и несколько разделов при установке мне неизвестно.

23.03.2016 13:06, Artem Chuprina пишет:

Люди местные, сами мы недобрые, поможите умным словом.

Никогда не работал раньше с софтверным рейдом. Ситуация.

Надо сделать на коленке бэкап-сервер. В смысле, чтобы стоял под столом,
его никто не трогал, а он работал. Упса, вообще говоря, нет. Ну, пока
нет, а будет ли - непонятно.

Четыре винта по 500 Gb. На самом деле 6, но рейд-контроллер давно сдох
от перегрева, и еще два воткнуть некуда. Винты вроде живы. Винты
одинаковые, т.е. в случае чего будет что воткнуть вместо сдохшего, и
даже два раза. Хочется иметь не четыре раздела с ручным
перетасовыванием, а один. Хочется некоторого запаса надежности, потому
хочется не тупо LVM, а софтверный рейд.

Грузиться буду с него же. ATA есть, но отдельного винта и даже флешки
нет.

Какой рейд лучше делать, по опыту? Пятый, который из четырех винтов по
полтерабайта сделает полтора? Какие тонкости с загрузкой?

Re: непонятка с сетью

[Dmitry Kulagin]

Не знаю, как в КУбунте собирается ядро и делается разделение на пакеты,
но в Дебиан для работы этой сетевой карты нужно установить пакет 
firmware-realtek

в jessie и новее, для более старых - firmware-linux.

15.03.2016 17:40, Andrei Lomov пишет:

Прошу помощи.
Есть роутер, к нему подключаю проводком нетбук с кубунтой 14.04, сеть
работает (dhcp).

Затем подключаю тем же проводком настольный компьютер с той же кубунтой,
сети нет, по dhcp не заводится inet addr.

Прописал IP статически, сети нет, но вроде должна быть?:

# lspci
...
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
...


# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.13
netmask 255.255.255.0
gateway 192.168.1.1



  
# ifconfig

eth0  Link encap:Ethernet  HWaddr fc:aa:14:96:a0:d2
   inet addr:192.168.1.13  Bcast:192.168.1.255  Mask:255.255.255.0
   inet6 addr: fe80::feaa:14ff:fe96:a0d2/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:3 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:47 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:555 (555.0 B)  TX bytes:0 (0.0 B)
  
loLink encap:Local Loopback

   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:65536  Metric:1
   RX packets:273 errors:0 dropped:0 overruns:0 frame:0
   TX packets:273 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:19797 (19.7 KB)  TX bytes:19797 (19.7 KB)
  



# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>From 192.168.1.13 icmp_seq=1 Destination Host Unreachable



Подскажите, пожалуйста, куда копать.
Благодарю заранее!

--
А.