date:20170624

On 2017-06-24, Sergey B Kirpichev wrote:

> ext2 не может защитить даже от порчи метаданных, не говоря уж о данных.

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

-- 
http://defun.work/

Re: Странная ошибка при конфигурировании пакета


On 24.06.2017 09:58, Vasiliy P. Melnik wrote:

|попробуйте так

apt-get download  sudo dpkg --unpack *.deb sudo rm 
/var/lib/dpkg/info/.postinst -f sudo dpkg --configure  sudo apt-get 
install -yf #To fix dependencies|


24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал:

Обновился апач.
И у меня когда-то уже была такая ошибка:
Настраивается пакет apache2 (2.4.25-3+deb9u1) …
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
ERROR: Conf apache2-doc does not exist!
dpkg: ошибка при обработке пакета apache2 (--configure):
 подпроцесс установлен сценарий post-installation возвратил код ошибки 1
При обработке следующих пакетов произошли ошибки:
 apache2
E: Sub-process /usr/bin/dpkg returned an error code (1)

При этом, apache2-doc установлен и не обновляется.
Aptitude выдаёт Internal error.
Из-за такой дурацкой ошибки я не могу работать с другими пакетами: 
удаление, обновление и установка всего остального падают на этом.
Надёжность на уровне.

Что это за фигня и почему оно вообще появляется?
И на кой делается a2enconf apache2-doc (причём, для пакета, которого может 
не быть)?



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

Смотрит он на наличие вот этой фиготы:
# dpkg -S /var/lib/apache2/deferred_actions
dpkg-query: не найден путь, подходящий под шаблон 
/var/lib/apache2/deferred_actions

# cat /var/lib/apache2/deferred_actions
apache2-doc apache2_invoke enconf apache2-doc

Откуда это? И если я его удалю, ничего не сломается?

Re: Странная ошибка при конфигурировании пакета


On 24.06.2017 09:58, Vasiliy P. Melnik wrote:

|попробуйте так

apt-get download  sudo dpkg --unpack *.deb sudo rm 
/var/lib/dpkg/info/.postinst -f sudo dpkg --configure  sudo apt-get 
install -yf #To fix dependencies|


24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал:

Обновился апач.
И у меня когда-то уже была такая ошибка:
Настраивается пакет apache2 (2.4.25-3+deb9u1) …
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
ERROR: Conf apache2-doc does not exist!
dpkg: ошибка при обработке пакета apache2 (--configure):
 подпроцесс установлен сценарий post-installation возвратил код ошибки 1
При обработке следующих пакетов произошли ошибки:
 apache2
E: Sub-process /usr/bin/dpkg returned an error code (1)

При этом, apache2-doc установлен и не обновляется.
Aptitude выдаёт Internal error.
Из-за такой дурацкой ошибки я не могу работать с другими пакетами: 
удаление, обновление и установка всего остального падают на этом.
Надёжность на уровне.

Что это за фигня и почему оно вообще появляется?
И на кой делается a2enconf apache2-doc (причём, для пакета, которого может 
не быть)?




И дальше:
июн 24 11:28:01 dana htcacheclean[27764]: htcacheclean error: Could not set 
filepath to '/var/cache/apache2/mod_disk_cache': No such file or directory
июн 24 11:28:01 dana htcacheclean[27764]: htcacheclean -- program for cleaning 
the disk cache.

Почему [оно у меня не работает из коробки]?

Re: Странная ошибка при конфигурировании пакета


On 24.06.2017 09:58, Vasiliy P. Melnik wrote:

|попробуйте так

apt-get download  sudo dpkg --unpack *.deb sudo rm 
/var/lib/dpkg/info/.postinst -f sudo dpkg --configure  sudo apt-get 
install -yf #To fix dependencies|


24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал:

Обновился апач.
И у меня когда-то уже была такая ошибка:
Настраивается пакет apache2 (2.4.25-3+deb9u1) …
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
ERROR: Conf apache2-doc does not exist!
dpkg: ошибка при обработке пакета apache2 (--configure):
 подпроцесс установлен сценарий post-installation возвратил код ошибки 1
При обработке следующих пакетов произошли ошибки:
 apache2
E: Sub-process /usr/bin/dpkg returned an error code (1)

При этом, apache2-doc установлен и не обновляется.
Aptitude выдаёт Internal error.
Из-за такой дурацкой ошибки я не могу работать с другими пакетами: 
удаление, обновление и установка всего остального падают на этом.
Надёжность на уровне.

Что это за фигня и почему оно вообще появляется?
И на кой делается a2enconf apache2-doc (причём, для пакета, которого может 
не быть)?



При этом:
# ll /var/cache/apache2/
итого 4,0K
drwxr-xr-x 2 www-data www-data 4,0K июл 23  2014 mod_cache_disk
-rw-r--r-- 1 root root0 июл 26  2014 reload

Re: Странная ошибка при конфигурировании пакета


On 24.06.2017 09:58, Vasiliy P. Melnik wrote:

|попробуйте так

apt-get download  sudo dpkg --unpack *.deb sudo rm 
/var/lib/dpkg/info/.postinst -f sudo dpkg --configure  sudo apt-get 
install -yf #To fix dependencies|


24 июня 2017 г., 9:43 пользователь Артём Н. mailto:artio...@yandex.ru>> написал:

Обновился апач.
И у меня когда-то уже была такая ошибка:
Настраивается пакет apache2 (2.4.25-3+deb9u1) …
info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
ERROR: Conf apache2-doc does not exist!
dpkg: ошибка при обработке пакета apache2 (--configure):
 подпроцесс установлен сценарий post-installation возвратил код ошибки 1
При обработке следующих пакетов произошли ошибки:
 apache2
E: Sub-process /usr/bin/dpkg returned an error code (1)

При этом, apache2-doc установлен и не обновляется.
Aptitude выдаёт Internal error.
Из-за такой дурацкой ошибки я не могу работать с другими пакетами: 
удаление, обновление и установка всего остального падают на этом.
Надёжность на уровне.

Что это за фигня и почему оно вообще появляется?
И на кой делается a2enconf apache2-doc (причём, для пакета, которого может 
не быть)?



После нескольких приседаний апач запустился, но это как-то не тянет на Debian 
stable.

Re: NAS

*** Артём Н.  [2017-06-24 01:17]:
>> В зеркале вы получаете полезного места только на три.
>При этом, получая высокую надёжность.

Я вас не понимаю. Может вылететь половина, но не любые диски из неё. В
RAID5 или RAID6 может вылететь любой (1 или 2). О какой надёжности речь?

>Вылететь могут они как одновременно (диски покупаются одновременно и есть 
>вероятность брака в партии, например),
>так и в процессе перестройки рэйда.

Одновременно -- я такого не встречал и не слышал что такое бывает. А вот
в процессе перестройки -- да, может. Особенно когда ёмкость дисков стала
огромной и время перестройки массива увеличилось. Поэтому и придуман
RAID6, чтобы выдержать вылет ещё одного диска.

>Кроме того, надо менять диск. А под рукой его может не оказаться, также как 
>может не быть и физического доступа к NAS.

Обычно всегда в массив сразу же добавляют hotspare или хотя бы просто
под рукой из точно такой же партии имеют диск где-то в ящике. Если нет
физического доступа к NAS, то от вылета дисков ничего не спасёт.

>Интересно, а что там говорят про ZFS?

В каком плане? Про его зеркало и RAIDZ? Всё то же самое что и про RAID.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: NAS

*** Артём Н.  [2017-06-24 01:19]:
>Рекомендовал он его затем, что данные не слишком критичные.
>Да, потерялась часть музыки, но это не важно: с другого компа возможно 
>восстановить.

Тогда можно не париться с RAID-ами действительно. Хотя я бы предпочёл
RAID0 чтобы хотя бы быстрее работало. Мне кажется что если кто-то
вылетел в JBOD или RAID0 -- то больше потратишь времени на
разбирательства что пропало и что надо восстановить -- проще всегда
будет восстановить всё.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.


On 24.06.2017 01:17, Tim Sattarov wrote:

On 06/23/17 17:41, Sergey Matveev wrote:

*** Tim Sattarov  [2017-06-24 00:21]:

не знаешь, насколько скорость доступа сравнима с ext4 ? Особенно, когда
в RAIDz ?

Так просто не скажешь.



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

У меня сейчас одна задача с большим количеством (несколько терабайт)
мелких и уже сжатых файлов: это ElasticSearch
причём в AWS. где диски можно подобрать разные, но они все "сетевые"
(EBS), то есть есть некоторая задержка в доступе.
Там же важна скорость чтения.

 На своём ноутбуке с 4 GB памяти
я не замечал разницы в производительности с переходом от XFS к ZFS,

А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
реально интересно.

я потенциально думаю заменить мои LVM тома на ZFS в домашнем хранилище,
но ещё не уверен... жду волшебного пенделя :)


Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там 
RAIDZ есть, но дальше я не интересовался)?
И что будет, если один диск из связки вылетит?
Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и 
остановится ли система)?

Re: NAS

On 24.06.2017 11:33, Sergey Matveev wrote:

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

В зеркале вы получаете полезного места только на три.

При этом, получая высокую надёжность.

Я вас не понимаю. Может вылететь половина, но не любые диски из неё. В
RAID5 или RAID6 может вылететь любой (1 или 2). О какой надёжности речь?

Вылететь могут они как одновременно (диски покупаются одновременно и есть
вероятность брака в партии, например),
так и в процессе перестройки рэйда.

Одновременно -- я такого не встречал и не слышал что такое бывает.

Запросто.
Достаточно одного криворукого индуса в компании-производителе дисков.
Вот здесь есть мануал, как сделать весьма неплохой граммофон из seagate на 3 Тб
(он вылететь может в любой момент):
https://habrahabr.ru/post/251941/

А вот
в процессе перестройки -- да, может. Особенно когда ёмкость дисков стала
огромной и время перестройки массива увеличилось. Поэтому и придуман
RAID6, чтобы выдержать вылет ещё одного диска.

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

Обычно всегда в массив сразу же добавляют hotspare или хотя бы просто
под рукой из точно такой же партии имеют диск где-то в ящике. Если нет
физического доступа к NAS, то от вылета дисков ничего не спасёт.

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

Интересно, а что там говорят про ZFS?

В каком плане? Про его зеркало и RAIDZ? Всё то же самое что и про RAID.

В плане замены рэйдов, LVM и прочего на ZFS.

Re: NAS


On 24.06.2017 11:35, Sergey Matveev wrote:

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

Рекомендовал он его затем, что данные не слишком критичные.
Да, потерялась часть музыки, но это не важно: с другого компа возможно 
восстановить.


Тогда можно не париться с RAID-ами действительно. Хотя я бы предпочёл
RAID0 чтобы хотя бы быстрее работало.

Тогда потеряется всё.


Мне кажется что если кто-то
вылетел в JBOD или RAID0 -- то больше потратишь времени на
разбирательства что пропало и что надо восстановить -- проще всегда
будет восстановить всё.


Разумно, мне вариант с JBOD тоже не особенно нравится.

Re: NAS

*** Артём Н.  [2017-06-24 01:33]:
>Xeon избыточен для NAS, мне так кажется (и это изделие позиционируется не как 
>NAS, а как офисный сервер).
>Для ZFS обязательна (крайне желательна) ECC память?
>И нужен ли ZFS?

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

>А нужен ли RAID или всё-таки ZFS, который многие хвалят, но с которым я пока 
>не разбирался?

ZFS.

>Вышел из строя второй диск, сдох контроллер (в случае аппаратного), зависла ОС 
>(из-за system.d) в процессе пересборки.
>Или:
>> Значит он не рабочий, с багами,
>> кривой? Тогда ничто не поможет.
>Вариантов много.

Ага, понятно. Если вышел из строя второй диск, то только RAID6 или ZFS
RAIDZ2 спасёт. В случае с остальными ошибками -- да, поверю что
rebuild-у станет плохо. Но в случае с ZFS -- абсолютно пофиг: он
продолжит с того же самого места или, пускай с нуля, но гарантированно
ничего не потеряется. Плюс в RAIDZ копируется не полностью весь жёсткий
диск, а только реально полезные данные на нём -- если на диске 50% места
свободно, то только половина его объёма и будет передана.

>> Фактически все RAID уровни расчитаны на
>> надёжность, кроме RAID0, который и не всегда за RAID-то считают.
>> 
>Я имел ввиду надёжность, по сравнению с JBOD.

В JBOD вылетает один -- теряется весь массив, становится бесполезен. В
RAID5/6 -- любой 1-2 диска вылетаеют и всё продолжает работать без
потерь доступности.

>> Само собой своевременно делая rebuild,
>> подставляя новые диски, при утрате старых.
>> 
>Вот последнее как-раз сложно.

Если вы не собираетесь делать rebuild, то да, рано или поздно, когда
вылетят все диски, то массив будет недоступен. Но, опять же, в JBOD-е вы
его сразу же потеряете, в RAID6/RAIDZ6 после двух дисков только.

>В смысле, не держит? Это Debian. Возможно туда впилить ZFS не особо напрягаясь.

Я только на список основных фич и перечисленных в них ФС посмотрел. Если
можно, то ok.

>> Но, в случае ZFS, вам нужно забыть будет про RAID.
>> 
>Почему он не дружит с рэйдами?

Потому-что будет работать хуже. Да и просто бессмысленно это. ZFS сам
себе RAID. Напомню что это не просто ФС, а штука которая *полностью*
заменяет любые RAID/mdadm, LVM и всё такое. RAID тупая штука, которая
оперирует только strip-ами и не знает ничего про данные на них. Его
можно запустить поверх RAID, но будет только хуже.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: NAS

*** Артём Н.  [2017-06-24 11:44]:
>> Одновременно -- я такого не встречал и не слышал что такое бывает.
>Запросто.

А я всё-равно не слышал о таком ни у кого на практике :-)
В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
стремительно) -- спасёт RAIDZ2 и RAIDZ3.

>Ну, в том и фишка, что доступа к NAS может не быть неделю (не потащусь же я в 
>другой город диск заменить).

Тогда RAID5/6/Z1/Z2/Z3 чтобы хотя бы какие-то вылеты он переживал, до
полной неработоспособности. В случае с RAID0/stripe/JBOD он откажет
сразу же после одного диска.

>> > Интересно, а что там говорят про ZFS?
>> В каком плане? Про его зеркало и RAIDZ? Всё то же самое что и про RAID.
>В плане замены рэйдов, LVM и прочего на ZFS.

Он полностью заменяет RAID, LVM и всё прочее. Всё так и есть. Лично по
мне, так настолько удобнее и лучше, что кроме ZFS ничего не хочется
использовать впредь.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.

*** Tim Sattarov  [2017-06-24 01:18]:
>У меня сейчас одна задача с большим количеством (несколько терабайт)
>мелких и уже сжатых файлов: это ElasticSearch
>причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>(EBS), то есть есть некоторая задержка в доступе.
>Там же важна скорость чтения.

Мне кажется что тут стоит попробовать ZFS. С мелкими файлами, как и в
XFS, проблем нет. Если это, кстати, сжатые .gz/whatever файлы, то на ZFS
можно включить прозрачное сжатие zlib и тогда на ФС будут хранится
просто файлы, без архивов, но на самом деле сжатые. Просто удобна
прозрачность.

>А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
>реально интересно.

Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
если есть возможность :-)? Как-минимум:

* snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
  откатить назад файлы, то можно сделать snapshot (за секунду
  выполняется) а потом его откатить (снова секунда). Знаю что многие
  люди говорят что я и без этого жил, но это точно так же как
  пользователь CVS или Subversion скажет что ему бранчи не нужны, но
  когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
  Или вот например у меня была система где я rsync-ал репозиторий с RPM
  пакетами, которые могли ломаться время от времени. Так там каждый день
  делался snapshot и я к нему мог обратить по
  /path/to/fs/.zfs/2017-04-05/ пути где полная ФС на тот день. Это очень
  удобно. С LVM не сравниться, потому-что LVM это блочное устройство
  ничего не знающее про ФС на нём, и нужно предпринимать особые действия
  чтобы, во-первых, сделать снимок (например xfs_freeze) безопасно,
  во-вторых восстановить его, в-третьих, обратиться к предыдущим его
  версиям. В ZFS это либо ровно одна команда на всё, либо обращение
  просто по особому пути ФС
* удобство backup-ов, которое тут обсуждают. Сделали snapshot, а дальше
  zfs send snapshot@name и у вас полная копия всех данных/метаданных со
  всеми настройками ФС в удобном stdout-е, который можно на лету сжать,
  зашифровать и передать куда надо. Восстановление -- одна команда zfs
  recv. Нужны инкрементальные backup-ы? Просто указываете что хотите
  дельту вместо полного дампа. Это приятно всё тем, что даже не надо
  думать а сохраняться ли все права или флаги на файлах при
  использовании tar, а какие опции для этого нужны, итд, итд.
* мне например приходилось работать с большими PostgreSQL и MongoDB
  данными. MongoDB хранит всё в JSONB, который очень хорошо сжимается
  даже LZ4. БД например должна занимать 60 GiB диска, но с LZ4 сжатием
  прозрачным, которое на CPU вообще не заметно, оно сокращалось до 20
  GiB. Плюс так как в ZFS свой собственный кэш ФС используется, то и в
  памяти будут кэшироваться именно эти 20 GiB, а не разжатые части 60-ти.
  А у меня 100 GB SSD, где сэкономленные десятки гигабайт это очень приятно.
* я очень переживаю за целостность данных. ОЧЕНЬ. с ZFS и его zfs scrub,
  который мне каждый байтик напротив Skein (раньше напротив SHA256)
  проверит -- убирает психологическое напряжение полностью. У меня в
  cron стоит раз в 4-часа создание очередного snapshot, генерирование
  инкрементального бэкапа и отсылка его в сжатом и зашифрованном виде
  (всё красиво через | xz -0 | gpg -r backup -e | nncp-file - делается)
  в NNCP который раскидывает на две машины. Когда прихожу домой, то
  прозрачно у меня на домашний сервер сбрасываются все недоброшенные
  4-часовые слепки всех данных (из них можно *полностью* восстановить
  всё состояние диска), когда прихожу домой, то прозрачно добрасываются
  на рабочий компьютер. Если внезапно SSD/whatever упадёт, то у меня
  мизерной ценой (а не обмазками всюду shell-скриптами) везде полные
  компактные копии данных. И не надо думать где размещать
  checksum.sha512 или что-то подобное и как его считать. Вся эта
  головная боль убрана.
* в домашнем сервере используется зеркало ZFS-ное. Это конечно мелочь,
  но приятно что я могу просто взять и достать диск, протереть от пыли,
  пропылесосить, вставить, сделать resilvering, который мне покажет что
  "ok, синхронизировал 6 MiB данных, зеркало снова *полностью* в строю",
  потом достать второй диск и всё то же самое. С RAID/LVM это
  невозможно, потому-что они обязаны будут полностью переrebuild-ить все
  эти 3 TB данных. Плюс у меня третий диск есть, в шкафчике, который я
  раз в месяц добавляю, он делает resilvering (не трёх терабайт, а
  только diff-а), убираю снова в шкафчик, зная что там у меня есть
  offline архивная копия всех данных

Если коротко, то я бы это мог сравнить со своими ощущения перехода от
Subversion к Git. Я не понимал чем он лучше, пока не попробовал. Сейчас
SVN/CVS я использую только в страшном сне. ZFS на HDD на машине с 4 GB
памяти действительно работает помедленнее, но я бы докупил память -- оно
стоит того.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.

*** Артём Н.  [2017-06-24 11:39]:
>Я так понимаю, ZFS может быть установлен на связке дисков (у него всякие там 
>RAIDZ есть, но дальше я не интересовался)?
>И что будет, если один диск из связки вылетит?
>Данные по остальным дискам будут восстановлены (вообще, что произоидёт, и 
>остановится ли система)?

Если это RAIDZ1 -- то zpool status скажет что потенциально "массив" в
опасности, вставьте диск чтобы на него произошёл resilvering и не было
страшно. Если RAIDZ2/3, то 2-3 диска аналогично. Если что-то вылетает,
то в системе, с точки зрения user-space, абсолютно ничего не происходит,
всё прозрачно и никто кроме zpool не знает что что-то не так.

Есть очень крутая, по моему, особенность. Я нечаянно, когда был молодым
и неопытным, сделал stripe вместо зеркала, при добавлении диска.
Испугался и диск достал (я ещё не понял что сделал stripe). В случае с
классическим RAID0, это было бы фатально -- никто не знает как
синхронизировать данные назад, никто не знает где данным можно доверять.
Массив и данные потеряны. В ZFS по-умолчанию массив переводится в режим
когда все чтения/записи с него просто блокируются/останавливаются. Я
достал диск -- весь IO встал. Я вставил диск -- он моментально понял что
с целостностью всё ok и прозрачно продолжил работу. В ZFS всё-всё-всё
сделано в виде криптографически связанных деревьев, как в Git, поэтому
он и понимает насколько диск зеркала "отстал" от основного, всё ли в
порядке со stripe-ом, итд.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: NAS

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

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

Меня спасло только то, что я как-то давно получил проблему с заполнением
стореджа данными пользователей и в итоге нерабочую систему, поэтому начал
делить диски на два пула - один пул для системы, второй - для данных. В
итоге я потерял только пул с системой, чтобы было не критично.
Опять же удобно если 3 диска , то для системы сделать пул зеркало из трех
разделов, чтобы гарантированно запустилась система, и raidz для данных,
если не критична скорость доступа.

Re: Стратегия поддержания резервных копий. Деградация носителей.

>
> Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
> если есть возможность :-)? Как-минимум:
>

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

З.Ы. Никто не задумывается, сколько времени занимает чекдиск на обычной
журналируемой системе - на текущий объемах дисков это может длиться часами.

Re: Стратегия поддержания резервных копий. Деградация носителей.

*** Sergey Matveev [2017-06-24 12:22]:
>Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
>если есть возможность :-)? Как-минимум:

Кроме того, масса мелочей из серии:

* включить/отключить atime -- zfs set atime=... mypool/fs, включить
отключить sync или перевести в режим бОльшего кэширования -- опять же,
один zfs set. Никаких редактирований fstab и перемонтирований.
* хочется расшарить директорию/ФС по NFS: zfs set sharenfs= Не надо
вспоминать по какому там пути, редактировать exports, передёргивать
mountd.
* надо сделать образ диска для виртуалки из серии dd if=/dev/zero of=hdd
bs=1M count=1024 && losetup ... -- делается zfs create -V 1G
mypooo/fs/hdd и сразу же будет сделан блочный loopback. Причём со
всеми фишками типа возможности snapshot-ов или, в данном случае
clone-ов.

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

--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF

Re: NAS



24.06.2017 11:52, Sergey Matveev пишет:
> *** Артём Н.  [2017-06-24 11:44]:
>>> Одновременно -- я такого не встречал и не слышал что такое бывает.
>> Запросто.
> 
> А я всё-равно не слышал о таком ни у кого на практике :-)
Ну вот есть статистика на больших объёмах, хотя вероятность и мала,
согласен.

> В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
> стремительно) -- спасёт RAIDZ2 и RAIDZ3.
> 
Короче, вы всё-таки агитируете за ZFS?

>> Ну, в том и фишка, что доступа к NAS может не быть неделю (не потащусь же я 
>> в другой город диск заменить).
> 
> Тогда RAID5/6/Z1/Z2/Z3 чтобы хотя бы какие-то вылеты он переживал, до
> полной неработоспособности. В случае с RAID0/stripe/JBOD он откажет
> сразу же после одного диска.
> 
JBOD не откажет, там откажет один диск, но JBOD меня как-то не привлекает.

 Интересно, а что там говорят про ZFS?
>>> В каком плане? Про его зеркало и RAIDZ? Всё то же самое что и про RAID.
>> В плане замены рэйдов, LVM и прочего на ZFS.
> 
> Он полностью заменяет RAID, LVM и всё прочее. Всё так и есть. Лично по
> мне, так настолько удобнее и лучше, что кроме ZFS ничего не хочется
> использовать впредь.
> 
Ok, придётся про него всё-таки почитать.

Re: NAS



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 памятью).
> 
Дело не столько в том, за сколько его возможно купить, сколько в том,
что он мощный и требует охлаждения.
А зачем? Если бы у меня была пара свободных полуподвальных помещений
(которые не затопляются), я бы не думал о шумности и прочем, а когда это
стоит в квартире и постоянно работает, совсем не хочется слышать шум
вентиляторов.


>> Вышел из строя второй диск, сдох контроллер (в случае аппаратного), зависла 
>> ОС (из-за system.d) в процессе пересборки.
>> Или:
>>> Значит он не рабочий, с багами,
>>> кривой? Тогда ничто не поможет.
>> Вариантов много.
> 
> Ага, понятно. Если вышел из строя второй диск, то только RAID6 или ZFS
> RAIDZ2 спасёт. В случае с остальными ошибками -- да, поверю что
> rebuild-у станет плохо. Но в случае с ZFS -- абсолютно пофиг: он
> продолжит с того же самого места или, пускай с нуля, но гарантированно
> ничего не потеряется.
Почему?

> Плюс в RAIDZ копируется не полностью весь жёсткий
> диск, а только реально полезные данные на нём -- если на диске 50% места
> свободно, то только половина его объёма и будет передана.
> 
Да, вот вспомнил про минус ZFS: он в каком-то из режимов, который
как-раз используется в NAS, требует немалого объёма памяти (там
начиналось от 8 Гб).

>>> Само собой своевременно делая rebuild,
>>> подставляя новые диски, при утрате старых.
>>>
>> Вот последнее как-раз сложно.
> 
> Если вы не собираетесь делать rebuild, то да, рано или поздно, когда
> вылетят все диски, то массив будет недоступен. Но, опять же, в JBOD-е вы
> его сразу же потеряете, в RAID6/RAIDZ6 после двух дисков только.
>
Ok, ясно.

>> В смысле, не держит? Это Debian. Возможно туда впилить ZFS не особо 
>> напрягаясь.
> 
> Я только на список основных фич и перечисленных в них ФС посмотрел. Если
> можно, то ok.
> 
Можно.

>>> Но, в случае ZFS, вам нужно забыть будет про RAID.
>>>
>> Почему он не дружит с рэйдами?
> 
> Потому-что будет работать хуже. Да и просто бессмысленно это. ZFS сам
> себе RAID. Напомню что это не просто ФС, а штука которая *полностью*
> заменяет любые RAID/mdadm, LVM и всё такое. RAID тупая штука, которая
> оперирует только strip-ами и не знает ничего про данные на них. Его
> можно запустить поверх RAID, но будет только хуже.
> 
А дружит ли он с LUKS?
Ведь ему плевать должно быть, если я ему даю шифрованные разделы, в
качестве нижнего уровня?
И что имеется ввиду под знанием ZFS о данных?

Re: NAS

*** artiom  [2017-06-24 12:55]:
>> В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
>> стремительно) -- спасёт RAIDZ2 и RAIDZ3.
>Короче, вы всё-таки агитируете за ZFS?

Лично я -- да, всеми руками. Одно но, о котором не сказал раньше: я
использую FreeBSD (HardenedBSD) и мало знаю о поддержке ZFS в GNU/Linux.
Не исключаю что с ней хуже -- поэтому тут ничего не могу сказать и опыта
не имею. Но, будь моя машина, рискнул бы.

Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
дорого стоят как время потраченное на вылет хотя бы одного из массива и
его восстановление. Если у вас нет возможности поменять hotspare диски,
то хотя бы это сильно увеличит время работы этого массива пока вылетит
то один, то другой диск (или третий в случае с RAIDZ3).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: NAS



24.06.2017 12:40, Vasiliy P. Melnik пишет:
> Лично я, поработав с ZFS уже три года, абсолютно ни с чем больше дела
> иметь не хочу. И я говорю про домашние компьютеры, где 1-2 диска сейчас.
> ECC -- чтобы не думалось, чтобы лучше "перебздеть". Xeon -- чтобы
> был ECC.
> Самые младшие модели стоили довольно дёшево. Сейчас вот например на
> nix.ru  Xeon за 6.5 тыс.руб. вон можно купить -- я бы
> брал не раздумывая,
> так как это плата за спокойствие (само собой с ECC памятью).
> 
> 
> Я сталкивался с ситуацией, когда монтирование раздела приводило к крашу
> системы. Как потом выяснилось - всему виной была мертвая планка
> оперативки, которая в паре с другой работала и сервер заводился, а сама
> по себе отказывалась работать.
> 
> Меня спасло только то, что я как-то давно получил проблему с заполнением
> стореджа данными пользователей и в итоге нерабочую систему, поэтому
> начал делить диски на два пула - один пул для системы, второй - для
> данных. В итоге я потерял только пул с системой, чтобы было не критично.
> Опять же удобно если 3 диска , то для системы сделать пул зеркало из
> трех разделов, чтобы гарантированно запустилась система, и raidz для
> данных, если не критична скорость доступа.
Данные невозможно было восстановить или просто не имело смысла, т.к.
проще переустановить?

Re: NAS

по текущей лицензии зфс я линуксе из коробки мы не увидим, но есть модули
собранные.

24 июня 2017 г., 12:58 пользователь Sergey Matveev 
написал:

> *** artiom  [2017-06-24 12:55]:
> >> В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
> >> стремительно) -- спасёт RAIDZ2 и RAIDZ3.
> >Короче, вы всё-таки агитируете за ZFS?
>
> Лично я -- да, всеми руками. Одно но, о котором не сказал раньше: я
> использую FreeBSD (HardenedBSD) и мало знаю о поддержке ZFS в GNU/Linux.
> Не исключаю что с ней хуже -- поэтому тут ничего не могу сказать и опыта
> не имею. Но, будь моя машина, рискнул бы.
>
> Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
> дорого стоят как время потраченное на вылет хотя бы одного из массива и
> его восстановление. Если у вас нет возможности поменять hotspare диски,
> то хотя бы это сильно увеличит время работы этого массива пока вылетит
> то один, то другой диск (или третий в случае с RAIDZ3).
>
> --
> Sergey Matveev (http://www.stargrave.org/)
> OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF
>
>

Re: NAS



24.06.2017 12:58, Sergey Matveev пишет:
> *** artiom  [2017-06-24 12:55]:
>>> В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
>>> стремительно) -- спасёт RAIDZ2 и RAIDZ3.
>> Короче, вы всё-таки агитируете за ZFS?
> 
> Лично я -- да, всеми руками. Одно но, о котором не сказал раньше: я
> использую FreeBSD (HardenedBSD) и мало знаю о поддержке ZFS в GNU/Linux.
> Не исключаю что с ней хуже -- поэтому тут ничего не могу сказать и опыта
> не имею. Но, будь моя машина, рискнул бы.
> 
Думаю, принципиальной разницы нет, да и выбрать конкретный софт я всегда
успею.
Пока надо про железо понять.

> Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
> дорого стоят как время потраченное на вылет хотя бы одного из массива и
> его восстановление. Если у вас нет возможности поменять hotspare диски,
> то хотя бы это сильно увеличит время работы этого массива пока вылетит
> то один, то другой диск (или третий в случае с RAIDZ3).
> 
Слабо представляю, как это в домашнем NAS реализовать.
Просто держать один диск резервным и неиспользуемым?
И вручную отслеживать проблемы, его включать, в случае вылета кого-либо
из рабочих?

Re: NAS



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

> 24 июня 2017 г., 12:58 пользователь Sergey Matveev
> mailto:stargr...@stargrave.org>> написал:
> 
> *** artiom mailto:artio...@yandex.ru>>
> [2017-06-24 12:55]:
> >> В любом случае, даже пускай 2 или 3 вылетят (хотя вероятность падает
> >> стремительно) -- спасёт RAIDZ2 и RAIDZ3.
> >Короче, вы всё-таки агитируете за ZFS?
> 
> Лично я -- да, всеми руками. Одно но, о котором не сказал раньше: я
> использую FreeBSD (HardenedBSD) и мало знаю о поддержке ZFS в GNU/Linux.
> Не исключаю что с ней хуже -- поэтому тут ничего не могу сказать и опыта
> не имею. Но, будь моя машина, рискнул бы.
> 
> Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
> дорого стоят как время потраченное на вылет хотя бы одного из массива и
> его восстановление. Если у вас нет возможности поменять hotspare диски,
> то хотя бы это сильно увеличит время работы этого массива пока вылетит
> то один, то другой диск (или третий в случае с RAIDZ3).
> 
> --
> Sergey Matveev (http://www.stargrave.org/)
> OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF
> 
>

Re: NAS

>
> Данные невозможно было восстановить или просто не имело смысла, т.к.
> проще переустановить


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

Re: NAS

*** artiom  [2017-06-24 13:06]:
>> Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
>> дорого стоят как время потраченное на вылет хотя бы одного из массива и
>> его восстановление. Если у вас нет возможности поменять hotspare диски,
>> то хотя бы это сильно увеличит время работы этого массива пока вылетит
>> то один, то другой диск (или третий в случае с RAIDZ3).
>> 
>Слабо представляю, как это в домашнем NAS реализовать.
>Просто держать один диск резервным и неиспользуемым?

Ну... да. Hotspare диски это называется. В mdadm или ZFS оно spare так и
называется. Если кто-то вылетел, то mdadm/ZFS автоматически диск
подхватывают в массив. По хорошему они и питание на диск должны
отключить, чтобы он не крутился пока бездействует.

>И вручную отслеживать проблемы, его включать, в случае вылета кого-либо
>из рабочих?

Если питание не отключить (или в корзине нет места для spare диска), то
да, мониторинг и ручное вмешательство.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: NAS

*** Vasiliy P. Melnik  [2017-06-24 13:04]:
>по текущей лицензии зфс я линуксе из коробки мы не увидим, но есть модули
>собранные.

Там просто же ещё вопрос интеграции ZFS со всем остальным окружением. В
последний раз когда я видел ZFS на GNU/Linux, то в top-е ничего о нём не
было. А в FreeBSD в top-е показывается состояние всех его кэшей:

Mem: 299M Active, 286M Inact, 1369M Wired, 773M Buf, 5867M Free
ARC: 299M Total, 54M MFU, 233M MRU, 437K Anon, 4121K Header, 8092K Other
 186M Compressed, 398M Uncompressed, 1.33:1 Ratio, 102M Overhead

Автоматическое монтирование/передёргивание NFS mountd демона, iSCSI
демона (чтобы блочные volume-ы zfs set-ом пробрасывать) или SMB. Хотя в
FreeBSD тоже iSCSI/SMB поддержки такой нет. Мелочи, а приятно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Плееры на Linux


On 19.06.2017 23:46, Артём Н. wrote:

Подскажите, чем удобно играть музыку "в фоне"?
В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не 
обязательно).
Также, желательно не GTK.
Попробовал Clementine, хороший, но не нравится управление.
Amarok как-то в последнее время разочаровывает.
Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже 
Clementine удобнее и функциональнее.
mpg321 не предлагать.



Вот ещё пара плееров, которые поставились и которыми, на первый взгляд вполне 
возможно пользоваться:
http://www.guayadeque.org/
http://getnightingale.com/all-versions.php

Последний из распакованного в локальный каталог тарбола.

Re: NAS

On 24.06.2017 13:25, Sergey Matveev wrote:

*** artiom [2017-06-24 13:06]:

Даже если не ZFS, то я агитирую за RAID6, вместо JBOD-ов. Диски не так
дорого стоят как время потраченное на вылет хотя бы одного из массива и
его восстановление. Если у вас нет возможности поменять hotspare диски,
то хотя бы это сильно увеличит время работы этого массива пока вылетит
то один, то другой диск (или третий в случае с RAIDZ3).

Слабо представляю, как это в домашнем NAS реализовать.
Просто держать один диск резервным и неиспользуемым?

Ну... да. Hotspare диски это называется. В mdadm или ZFS оно spare так и
называется. Если кто-то вылетел, то mdadm/ZFS автоматически диск
подхватывают в массив. По хорошему они и питание на диск должны
отключить, чтобы он не крутился пока бездействует.

И вручную отслеживать проблемы, его включать, в случае вылета кого-либо
из рабочих?

Если питание не отключить (или в корзине нет места для spare диска), то
да, мониторинг и ручное вмешательство.

Так программное управление питанием дисков через штатные средства или там
какой-то специальный контроллер?

Re: NAS


On 24.06.2017 13:06, Vasiliy P. Melnik wrote:

Данные невозможно было восстановить или просто не имело смысла, т.к.
проще переустановить


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

На любой системе?
Т.е., подключение пула в другую систему или загрузка в ремонтной системе и 
последующее монтирование тоже крашились?
С kernel panic что-ли?

Re: NAS

*** Артём Н.  [2017-06-24 13:33]:
>Так программное управление питанием дисков через штатные средства или там 
>какой-то специальный контроллер?

Точно не знаю, но вроде это типа какая-то SCSI (?) команда есть для
backplane к которому подключены диски чтобы он отключил питание. Или
команда на сам жёсткий диск идёт. Специальных backplane/controller я не
вроде видел где написано что они могут отключать питание -- наверное оно
и так предусматривается, кроме дешёвых систем.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

сортировка файлов

2017-06-24 Пенетрантность serge


Подскажите, кто знает - можно как-нибудь сделать, чтобы файлы во всех
программах сортировались по имени как в ls, mc, geeqie, feh?
В подавляющем большинстве программ (thunar, pcmanfm, emelfm2 итд)
сортировка, мягко говоря, странная. 
Из-за этого происходят непонятки следующего типа: 
в emelfm2 открываешь первый в директории png файл с помощью geeqie и в
открывшейся программе этот файл где-то в середине директории.

Debian oldstable, Xfce 
-- 
Claws Mail version 3.11.1
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u1
(2017-06-18) i686 GNU/Linux

Re: Стратегия поддержания резервных копий. Деградация носителей.

On 2017-06-24, Sergey Matveev wrote:

>   пользователь CVS или Subversion скажет что ему бранчи не нужны, но
>   когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.

В современном SVN бранчи удобные если извращенные воркфловы не делать.

И даже "продвинутые", т.к. информация о мержах это список ревизий. Я не совсем
понял чери-пики в Git как то отслеживаются или нет. В Subversion 1.6 и выше из
коробки, с оговоркой что но во все стороны мигрирються ченджи.

-- 
http://defun.work/

ZFS

2017-06-24 Пенетрантность Жанибек Нагашыбай

Граждане, раз уж пошла такая пьянка.

Я правильно понимаю, что если я, допустим, хочу хранить
бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
раздела?

А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
так же на два раздела, на первых сделать raid1 с системой, а на вторых
собирать raidz?

Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
файловой системе штатными средствами бутовой флешки доберусь?

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

И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
из всего этого уже забито, я собираюсь ставить 4-терабайтник,
вероятно. На работе имеется в виду держать зеркало из пары
4-терабайтников.

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

Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
ее можно включить/выключить на ходу, или это надо делать в момент
создания FS?)

Re: сортировка файлов

В Sat, 24 Jun 2017 14:37:09 +0300
serge  пишет:

> Подскажите, кто знает - можно как-нибудь сделать, чтобы файлы во всех
> программах сортировались по имени как в ls, mc, geeqie, feh?
> В подавляющем большинстве программ (thunar, pcmanfm, emelfm2 итд)
> сортировка, мягко говоря, странная. 
> Из-за этого происходят непонятки следующего типа: 
> в emelfm2 открываешь первый в директории png файл с помощью geeqie и в
> открывшейся программе этот файл где-то в середине директории.
> 
> Debian oldstable, Xfce 

Можно только правкой исходников. По-другому никак.

Re: сортировка файлов

serge -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 14:37:09 +0300:

 > Подскажите, кто знает - можно как-нибудь сделать, чтобы файлы во всех
 > программах сортировались по имени как в ls, mc, geeqie, feh?
 > В подавляющем большинстве программ (thunar, pcmanfm, emelfm2 итд)
 > сортировка, мягко говоря, странная. 
 > Из-за этого происходят непонятки следующего типа: 
 > в emelfm2 открываешь первый в директории png файл с помощью geeqie и в
 > открывшейся программе этот файл где-то в середине директории.

 > Debian oldstable, Xfce 

Я боюсь тебя огорчить, но ls знает очень немало способов
сортировки. Например, по дате.

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

Re: Стратегия поддержания резервных копий. Деградация носителей.

On 2017-06-24, Sergey Matveev wrote:

> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
> целостностью всё ok и прозрачно продолжил работу.

Какие физические интерфейсы поддерживают - вынять/вставить?

Что можно себе дома поставить?

Я работал по старинке - ATX размера коробка или лаптоп. Туда хотплаг только по
USB ))

Сейчас есть e-SATA, я не сильно понимаю на сколько оно полезно для накопителей
и вроде питание не передает интерфейс...

-- 
http://defun.work/

Re: NAS

On 2017-06-23, artiom wrote:

> - RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял
> часть данных, упал диск в рэйде - рейд может и не пересобраться,
> потеряются все данные, упало два - капут). Это верно?
> - Mirror - слишком дорого, не стоит его ставить на домашний NAS?

Обычно говорят что RAID повышает *доступность*. Меньше простоя.

Когда говорят о надожности в RAID - приводят пример легитимной операции
удаления файла )) Где же надежность?

Дома за доступностьплатить нет смысла. А за надежность есть.

Но достигается надежность избыточностью, бекапами и архивированием.

-- 
http://defun.work/

Re: NAS

On 2017-06-23, Sergey Matveev wrote:

> то Western Digital, но ни в коем случае
> не всякие Green модели, типа тихие, экологичные и прочее -- насколько
> знаю, это просто бракованные модели которые на пониженных
> нагрузках/мощностях хоть как-то тянуть. У меня все зелёные модели
> сдыхали довольно быстро -- табу на их приобретение.

Добавлю свою небольшую статистику по всем двум зеленым, которые были, дохнут
заразы. За годик.Но было это давно, лет 5 назад.

-- 
http://defun.work/

Re: NAS


On 24.06.2017 16:05, Oleksandr Gavenko wrote:

On 2017-06-23, Sergey Matveev wrote:


то Western Digital, но ни в коем случае
не всякие Green модели, типа тихие, экологичные и прочее -- насколько
знаю, это просто бракованные модели которые на пониженных
нагрузках/мощностях хоть как-то тянуть. У меня все зелёные модели
сдыхали довольно быстро -- табу на их приобретение.


Добавлю свою небольшую статистику по всем двум зеленым, которые были, дохнут
заразы. За годик.Но было это давно, лет 5 назад.


См. выше, там есть статистика от backblaze.

Re: NAS


On 24.06.2017 15:54, Oleksandr Gavenko wrote:

On 2017-06-23, artiom wrote:


- RAID, кроме mirror, не дают повышения надёжности (упал диск - потерял
часть данных, упал диск в рэйде - рейд может и не пересобраться,
потеряются все данные, упало два - капут). Это верно?
- Mirror - слишком дорого, не стоит его ставить на домашний NAS?


Обычно говорят что RAID повышает *доступность*. Меньше простоя.

Когда говорят о надожности в RAID - приводят пример легитимной операции
удаления файла )) Где же надежность?


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


Дома за доступностьплатить нет смысла. А за надежность есть.

Но достигается надежность избыточностью, бекапами и архивированием.


С NAS?
Репликацией в облако?

Re: Стратегия поддержания резервных копий. Деградация носителей.

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 
15:38:16 +0300:

 >> Я достал диск -- весь IO встал. Я вставил диск -- он моментально понял что с
 >> целостностью всё ok и прозрачно продолжил работу.

 > Какие физические интерфейсы поддерживают - вынять/вставить?

 > Что можно себе дома поставить?

 > Я работал по старинке - ATX размера коробка или лаптоп. Туда хотплаг только 
 > по
 > USB ))

 > Сейчас есть e-SATA, я не сильно понимаю на сколько оно полезно для 
 > накопителей
 > и вроде питание не передает интерфейс...

SATA на практике (ну, современная) вполне переживает
вынуть-вставить. Мне казалось, что она изначально была на это
рассчитана, ибо сразу целилась в тот сегмент, где винчестеры суют в
rack-mount.

Re: ZFS

On Sat, 2017-06-24 at 15:01 +0300, Artem Chuprina wrote:
> Граждане, раз уж пошла такая пьянка.
> 
> Я правильно понимаю, что если я, допустим, хочу хранить
> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
> ставить
> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
> второго
> раздела?
> 
> А если я, допустим, хочу рейд на нескольких дисках, то поделить
> каждый
> так же на два раздела, на первых сделать raid1 с системой, а на
> вторых
> собирать raidz?
> 
> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
> файловой системе штатными средствами бутовой флешки доберусь?
> 
> Это я задумываюсь про апгрейд двух серверов - домашнего, который он
> же
> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
> работе - рейд.
> 
> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
> суммой
> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
> вероятно. На работе имеется в виду держать зеркало из пары
> 4-терабайтников.
> 
> В обоих случаях супербыстрый доступ не требуется, но и суровых
> тормозов
> быть не должно. 
> 
> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
> более-менее комфортно? А если я захочу дедупликацию
> включить?  (Кстати,
> ее можно включить/выключить на ходу, или это надо делать в момент
> создания FS?)
> 
Просто технически интересно, а что если, вдруг, раз и поддержу zfs для
линухи прекратят? Что тогда ты будешь делать? Вроде как на замену zfs
пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет тоже
как-то стремно. Приходится пока сидеть на mdadm.

Re: ZFS

Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 18:42:44 
+0300:

 >> Граждане, раз уж пошла такая пьянка.
 >> 
 >> Я правильно понимаю, что если я, допустим, хочу хранить
 >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
 >> ставить
 >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
 >> второго
 >> раздела?
 >> 
 >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
 >> каждый
 >> так же на два раздела, на первых сделать raid1 с системой, а на
 >> вторых
 >> собирать raidz?
 >> 
 >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
 >> файловой системе штатными средствами бутовой флешки доберусь?
 >> 
 >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он
 >> же
 >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
 >> работе - рейд.
 >> 
 >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
 >> суммой
 >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >> вероятно. На работе имеется в виду держать зеркало из пары
 >> 4-терабайтников.
 >> 
 >> В обоих случаях супербыстрый доступ не требуется, но и суровых
 >> тормозов
 >> быть не должно. 
 >> 
 >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >> более-менее комфортно? А если я захочу дедупликацию
 >> включить?  (Кстати,
 >> ее можно включить/выключить на ходу, или это надо делать в момент
 >> создания FS?)
 >> 
 > Просто технически интересно, а что если, вдруг, раз и поддержу zfs для
 > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену zfs
 > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет тоже
 > как-то стремно. Приходится пока сидеть на mdadm.

Что значит "прекратят"? На серверах у меня stable, в рамках stable не
прекратят.

Re: NAS

On 2017-06-24, Артём Н. wrote:

>> Когда говорят о надожности в RAID - приводят пример легитимной операции
>> удаления файла )) Где же надежность?
>>
> Она легитимна, хотя и может быть нужный файл удалён умышленно, это крайне 
> маловероятно.
> Вопрос в том, что будет, если один из пачки дисков откажет, и что выдержит 
> рейд.
>
Если API позволяет удлить файл, то самый важный файл будет удален. Закон Мерфи.

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

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

>> Дома за доступностьплатить нет смысла. А за надежность есть.
>>
>> Но достигается надежность избыточностью, бекапами и архивированием.
>>
> С NAS?
> Репликацией в облако?

Посудите сами, что Вы хотите? Уменьшить цену поддержки данных NAS?

В RAID Вы выжимаете ресурс у 2-3 дисков одновременно. Без RAID Вы держите 1
диск и раз в день/месяц делаете копию, как пожелаете.

Время тратите на средства резервирования данных, вместо настройки RAID.

А делать то копию все равно нужно, если стоит вопрос сохранности данных.

Говорить про надежность RAID особо нечего. Выдержит ли сбой 1/2/3 дисков
одновременно. Тоже и про распаралеливание чтений / записей много не
поговоришь. Даже на Wikipedia все написано.

-- 
http://defun.work/

Re: Стратегия поддержания резервных копий. Деградация носителей.

Sergey Matveev -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 12:22:04 
+0300:

 > * snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
 >   откатить назад файлы, то можно сделать snapshot (за секунду
 >   выполняется) а потом его откатить (снова секунда). Знаю что многие
 >   люди говорят что я и без этого жил, но это точно так же как
 >   пользователь CVS или Subversion скажет что ему бранчи не нужны, но
 >   когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
 >   Или вот например у меня была система где я rsync-ал репозиторий с RPM
 >   пакетами, которые могли ломаться время от времени. Так там каждый день
 >   делался snapshot и я к нему мог обратить по
 >   /path/to/fs/.zfs/2017-04-05/ пути где полная ФС на тот день. Это очень
 >   удобно. С LVM не сравниться, потому-что LVM это блочное устройство
 >   ничего не знающее про ФС на нём, и нужно предпринимать особые действия
 >   чтобы, во-первых, сделать снимок (например xfs_freeze) безопасно,
 >   во-вторых восстановить его, в-третьих, обратиться к предыдущим его
 >   версиям. В ZFS это либо ровно одна команда на всё, либо обращение
 >   просто по особому пути ФС

Я правильно понимаю, что для создания снапшота ей не нужно отдельного
незадействованного места на диске, как LVM?

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

Re: ZFS

On Sat, 2017-06-24 at 19:23 +0300, Artem Chuprina wrote:
> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
> 18:42:44 +0300:
> 
>  >> Граждане, раз уж пошла такая пьянка.
>  >> 
>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
>  >> ставить
>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
>  >> второго
>  >> раздела?
>  >> 
>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
>  >> каждый
>  >> так же на два раздела, на первых сделать raid1 с системой, а на
>  >> вторых
>  >> собирать raidz?
>  >> 
>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен
> я к
>  >> файловой системе штатными средствами бутовой флешки доберусь?
>  >> 
>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который
> он
>  >> же
>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск,
> на
>  >> работе - рейд.
>  >> 
>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
>  >> суммой
>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>  >> вероятно. На работе имеется в виду держать зеркало из пары
>  >> 4-терабайтников.
>  >> 
>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых
>  >> тормозов
>  >> быть не должно. 
>  >> 
>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>  >> более-менее комфортно? А если я захочу дедупликацию
>  >> включить?  (Кстати,
>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>  >> создания FS?)
>  >> 
>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
> для
>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
> zfs
>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
> тоже
>  > как-то стремно. Приходится пока сидеть на mdadm.
> 
> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
> прекратят.
> 
Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
линухи махнут на него рукой.

Re: ZFS

Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 19:33:32 
+0300:

 >>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
 >> для
 >>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
 >> zfs
 >>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
 >> тоже
 >>  > как-то стремно. Приходится пока сидеть на mdadm.
 >> 
 >> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
 >> прекратят.
 >> 
 > Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
 > оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
 > линухи махнут на него рукой.

Поясняю. Прямо на ходу поддержка не пропадет. Чтобы пропала, надо
сапгрейдиться на следующую major версию. Это будет запас года два как минимум.

Re: ZFS

On Sat, 2017-06-24 at 19:51 +0300, Artem Chuprina wrote:
> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
> 19:33:32 +0300:
> 
>  >>  > Просто технически интересно, а что если, вдруг, раз и поддержу
> zfs
>  >> для
>  >>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на
> замену
>  >> zfs
>  >>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs
> чет
>  >> тоже
>  >>  > как-то стремно. Приходится пока сидеть на mdadm.
>  >> 
>  >> Что значит "прекратят"? На серверах у меня stable, в рамках
> stable не
>  >> прекратят.
>  >> 
>  > Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
>  > оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs
> для
>  > линухи махнут на него рукой.
> 
> Поясняю. Прямо на ходу поддержка не пропадет. Чтобы пропала, надо
> сапгрейдиться на следующую major версию. Это будет запас года два как
> минимум.
> 
Просто интересно много-ли народу пили zfs для linux. Тоже подумывал о
переходе на него но чет пока сомневаюсь.

Re: Плееры на Linux

2017-06-24 Пенетрантность Melleus

Артём Н.  writes:

> On 19.06.2017 23:46, Артём Н. wrote:
>> Подскажите, чем удобно играть музыку "в фоне"?
>> В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не 
>> обязательно).
>> Также, желательно не GTK.
>> Попробовал Clementine, хороший, но не нравится управление.
>> Amarok как-то в последнее время разочаровывает.
>> Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже 
>> Clementine удобнее и функциональнее.
>> mpg321 не предлагать.
>>

Все же рекомендовал бы еще раз глянуть в сторону mpd+mpc. Вполне себе
может локально работать на лаптопе, причем, весьма экономно по ресурсам,
в сравнении с той же клементиной. А если чего-то не умеет делать, то
наверняка найдется сторонний плагин/клиент/модуль, который это
сделает. А если не найдется, то скорее всего оно и не надо исполнять ото
странное желание. Если mpc - слишком сложно, то есть куча гуев, хоть
консольных, хоть иксовых. Даже для имакса есть свой гуи. Разживетесь
выделенным сервером если, просто клиент перенастроите тогда на него и
все. Не нужно будет опять новый плеер искать.

Re: Стратегия поддержания резервных копий. Деградация носителей.

*** Oleksandr Gavenko  [2017-06-24 22:49]:
>Какие физические интерфейсы поддерживают - вынять/вставить?

Обычный SATA. Только backplane (в который диск вставляется) должен это
поддерживать. Ну и салазки для диска соответствующие. Как во всех
серверах.

>Что можно себе дома поставить?

Лично у меня две вот таких железки дома: 
http://netberg.ru/products/netberg-demos-p200-m3/

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Стратегия поддержания резервных копий. Деградация носителей.

*** Artem Chuprina  [2017-06-24 22:49]:
>Я правильно понимаю, что для создания снапшота ей не нужно отдельного
>незадействованного места на диске, как LVM?

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

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

Моментально:

# zfs list -t snap
NAME   USED  AVAIL  REFER  MOUNTPOINT
secure@backup 26.0M  -   117M  -
stcvol@backup   55K  -   175M  -
stcvol/remote@backup  16.3M  -   412M  -
zroot@backup  7.10M  -  5.95G  -
zroot/home@backup 45.4M  -  7.03G  -

Колонка USED говорит сколько затрачено места именно для хранения дельты.
То есть то, что освободится после удаления snapshot.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

*** Artem Chuprina  [2017-06-24 22:49]:
>Я правильно понимаю, что если я, допустим, хочу хранить
>бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
>раздела?
>
>А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>так же на два раздела, на первых сделать raid1 с системой, а на вторых
>собирать raidz?
>
>Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>файловой системе штатными средствами бутовой флешки доберусь?

Не знаю как в GNU/Linux, но не могу представить в чём может быть
проблема или подстава достучаться до ФС с бутовой флешки? Загрузились на
"LiveCD" с флешки, сделали zpool import mypool и всё. Ну ok, как правило
оно захочет подмонтировать сразу же и поэтому перед этим надо указать
другую директорию монтирования. Я так делал много раз, просто указывая
какой-нибудь /tmp/mypool. Я не понял в чём проблемы держать систему на
ZFS. Там это очень кстати бы было если например делается какой-нибудь
dist-upgrade и хочется откатиться до начального состояния в случае
проблем.

>И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>вероятно. На работе имеется в виду держать зеркало из пары
>4-терабайтников.
>
>В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>быть не должно. 
>
>Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>ее можно включить/выключить на ходу, или это надо делать в момент
>создания FS?)

8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
хочется включить дедупликацию, то, личного опыта нет, но говорят что
нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в
случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
можно включить на уже работающей системе, когда угодно, как и выключить.
А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
вот дедупликация... я за несколько лет так и не смог увидеть в домашних
условиях где бы это могло помочь. Если делаются какие-то "ответвления"
типа clone или там snapshot (например есть chroot какой-нибудь ОС,
хочется из него наделать разных других chroot-ов для контейнеров) -- то
там и так только дельты хранятся. Где-то я чуть ли не в официальных
мануалах Sun-а (Oracle?) видел что зачастую правильное использование
clone-ов (snapshot и прочего) решает большинство проблем с
избыточностью, где люди думают о дедупликации. Хотя если это
какой-нибудь там хостинг картиночек, где одни и те же кошечки тысячами
пользователей заливаются, то там поможет. В ZFS есть команда zdb -S
mypool которая "эмулирует" дедупликацию и показывает поможет ли она или
нет. Буквально вчера на одном из разделов её делал у себя (подумал что
может пора?):

# zdb -S storage
Simulated DDT histogram:

bucket  allocated   referenced
__   __   __
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
--   --   -   -   -   --   -   -   -
 18.87M   1.11T   1.10T   1.10T8.87M   1.11T   1.10T   1.10T
 26.31K807M782M782M13.0K   1.63G   1.57G   1.57G
 4  250   31.2M   27.2M   27.2M1.08K138M120M120M
 8   11   1.38M653K653K  102   12.8M   5.61M   5.61M
167896K134K134K  156   19.5M   2.38M   2.38M
321128K   20.5K   20.5K   52   6.50M   1.04M   1.04M
 Total8.88M   1.11T   1.10T   1.10T8.89M   1.11T   1.11T   1.11T

dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 
1.01

Видно что о ней думать не приходится совершенно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: сортировка файлов

2017-06-24 Пенетрантность serge

On Sat, 24 Jun 2017 15:32:48 +0300
Artem Chuprina  wrote:

> serge -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 14:37:09
> +0300:
> 
>  > Подскажите, кто знает - можно как-нибудь сделать, чтобы файлы во
>  > всех программах сортировались по имени как в ls, mc, geeqie, feh?
>  > В подавляющем большинстве программ (thunar, pcmanfm, emelfm2 итд)
>  > сортировка, мягко говоря, странная. 
>  > Из-за этого происходят непонятки следующего типа: 
>  > в emelfm2 открываешь первый в директории png файл с помощью geeqie
>  > и в открывшейся программе этот файл где-то в середине директории.
> 
>  > Debian oldstable, Xfce 
> 
> Я боюсь тебя огорчить, но ls знает очень немало способов
> сортировки. Например, по дате.
> 
> Я подозреваю примерно три способа получить разную сортировку, так тебя
> удивившую. И если ты сможешь описать, как эти программы сортируют твои
> файлы, то скорее всего, станет понятно, какую настройку искать.
> 


 Мы с вами на брудершафт не пили. Если вы читаете не между строк, то я
 явно указал "сортировались по имени".
Разницу в сортировке можно увидеть на скриншоте:

http://autogrom.ru/files/screenshot-1.png

-- 
Claws Mail version 3.11.1
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u1
(2017-06-18) i686 GNU/Linux

Re: сортировка файлов

2017-06-24 Пенетрантность serge

On Sat, 24 Jun 2017 18:04:09 +0600
Жанибек Нагашыбай  wrote:

> В Sat, 24 Jun 2017 14:37:09 +0300
> serge  пишет:
> 
> > Подскажите, кто знает - можно как-нибудь сделать, чтобы файлы во
> > всех программах сортировались по имени как в ls, mc, geeqie, feh?
> > В подавляющем большинстве программ (thunar, pcmanfm, emelfm2 итд)
> > сортировка, мягко говоря, странная. 
> > Из-за этого происходят непонятки следующего типа: 
> > в emelfm2 открываешь первый в директории png файл с помощью geeqie
> > и в открывшейся программе этот файл где-то в середине директории.
> > 
> > Debian oldstable, Xfce 
> 
> Можно только правкой исходников. По-другому никак.
> 

Про исходники понятно, я знаю где и как поправить код в emelfm2, но не
править же все программы. Я думал, может есть какая глобальная
настройка типа LC_COLLATE для gtk программ.

-- 
Claws Mail version 3.11.1
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u1
(2017-06-18) i686 GNU/Linux

Re: NAS



24.06.2017 19:25, Oleksandr Gavenko пишет:
> On 2017-06-24, Артём Н. wrote:
> 
>>> Когда говорят о надожности в RAID - приводят пример легитимной операции
>>> удаления файла )) Где же надежность?
>>>
>> Она легитимна, хотя и может быть нужный файл удалён умышленно, это крайне 
>> маловероятно.
>> Вопрос в том, что будет, если один из пачки дисков откажет, и что выдержит 
>> рейд.
>>
> Если API позволяет удлить файл, то самый важный файл будет удален. Закон 
> Мерфи.
> 
Это уровень ПО: возможно сделать архивы "только для чтения" (immutable,
например поставить).
RAID же всё-таки уровень железа.

> Я отписался только из-за терминологии и ожиданиях, которое люди вкладывают,
> когда говорят о RAID. Ваше реакция - типична на мое замечание и пример с
> удалением файла не убеждает отказаться от "надежности" и начать говорить об
> "доступности". Как хотите, по сути это философская позиция ))
> 
Ok, доступность, так доступность, возможно терминологически корректнее.

> RAID позволяет уменьшить время простоя в случае апаратных проблем, увеличить
> скорость чтения, распаралелить чтение, делает линейным раздробленное
> пространство дисков. Может еще что то делает, я их не готовил.
> 
Но тоже самое делает ZFS?
Нет у меня особого желания заниматсья рэйдами: мне нужно девайс сделать.
Если их возможно заменить (весь комплекс с рэйд-лвм-фс) на что-то одно,
я буду только рад.

>>> Дома за доступностьплатить нет смысла. А за надежность есть.
>>>
>>> Но достигается надежность избыточностью, бекапами и архивированием.
>>>
>> С NAS?
>> Репликацией в облако?
> 
> Посудите сами, что Вы хотите? Уменьшить цену поддержки данных NAS?
> 
> В RAID Вы выжимаете ресурс у 2-3 дисков одновременно. Без RAID Вы держите 1
> диск и раз в день/месяц делаете копию, как пожелаете.
> 
> Время тратите на средства резервирования данных, вместо настройки RAID.
> 
> А делать то копию все равно нужно, если стоит вопрос сохранности данных.
> 
> Говорить про надежность RAID особо нечего. Выдержит ли сбой 1/2/3 дисков
> одновременно. Тоже и про распаралеливание чтений / записей много не
> поговоришь. Даже на Wikipedia все написано.
> 
Читал я, но давно, тут просто ещё вопрос про контроллер ранее был.

Re: Плееры на Linux



24.06.2017 21:03, Melleus пишет:
> Артём Н.  writes:
> 
>> On 19.06.2017 23:46, Артём Н. wrote:
>>> Подскажите, чем удобно играть музыку "в фоне"?
>>> В идеале, ещё и одиночный файл, чтобы возможно было проиграть (хотя, это не 
>>> обязательно).
>>> Также, желательно не GTK.
>>> Попробовал Clementine, хороший, но не нравится управление.
>>> Amarok как-то в последнее время разочаровывает.
>>> Раньше был XMMS, который сейчас QMMP, но меня не он не порадовал: даже 
>>> Clementine удобнее и функциональнее.
>>> mpg321 не предлагать.
>>>
> 
> Все же рекомендовал бы еще раз глянуть в сторону mpd+mpc. Вполне себе
> может локально работать на лаптопе, причем, весьма экономно по ресурсам,
> в сравнении с той же клементиной.
Ресурсы для меня (память и CPU) не особенно критичны: плеер не сожрёт
столько, сколько даст лептоп (i7, 12 Gb) или десктоп (i5, 20 Gb).

> А если чего-то не умеет делать, то
> наверняка найдется сторонний плагин/клиент/модуль, который это
> сделает. А если не найдется, то скорее всего оно и не надо исполнять ото
> странное желание.
Далеко не факт.

> Если mpc - слишком сложно, то есть куча гуев, хоть
> консольных, хоть иксовых.
Да не сложно, просто меня коробит от мысли, что я буду CLI плеер юзать в
GUI среде.
Мне это какие-то продукты от Борланда старые в среде Windows напоминает
в далёкие годы.

> Даже для имакса есть свой гуи. Разживетесь
> выделенным сервером если, просто клиент перенастроите тогда на него и
> все. Не нужно будет опять новый плеер искать.
Я не против MPD, но мне более нравятся клементиноподобные плееры.
Всё в ней нормально, просто не очень нравится управление.
А когда разживусь сервером, плагин для MPD поставлю.

Re: ZFS



24.06.2017 19:33, Igor Savlook пишет:
> On Sat, 2017-06-24 at 19:23 +0300, Artem Chuprina wrote:
>> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
>> 18:42:44 +0300:
>>
>>  >> Граждане, раз уж пошла такая пьянка.
>>  >> 
>>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
>>  >> ставить
>>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
>>  >> второго
>>  >> раздела?
>>  >> 
>>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
>>  >> каждый
>>  >> так же на два раздела, на первых сделать raid1 с системой, а на
>>  >> вторых
>>  >> собирать raidz?
>>  >> 
>>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен
>> я к
>>  >> файловой системе штатными средствами бутовой флешки доберусь?
>>  >> 
>>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который
>> он
>>  >> же
>>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск,
>> на
>>  >> работе - рейд.
>>  >> 
>>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
>>  >> суммой
>>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>>  >> вероятно. На работе имеется в виду держать зеркало из пары
>>  >> 4-терабайтников.
>>  >> 
>>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых
>>  >> тормозов
>>  >> быть не должно. 
>>  >> 
>>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>>  >> более-менее комфортно? А если я захочу дедупликацию
>>  >> включить?  (Кстати,
>>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>>  >> создания FS?)
>>  >> 
>>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
>> для
>>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
>> zfs
>>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
>> тоже
>>  > как-то стремно. Приходится пока сидеть на mdadm.
>>
>> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
>> прекратят.
>>
> Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
> оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
> линухи махнут на него рукой.
> 
Крайне сомнительно.
Нафиг тогда нужен будет ZFS?
Или они из принципа: будут соляру и BSD развивать?

Re: ZFS


>> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>> вероятно. На работе имеется в виду держать зеркало из пары
>> 4-терабайтников.
>>
>> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>> быть не должно. 
>>
>> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>> ее можно включить/выключить на ходу, или это надо делать в момент
>> создания FS?)
> 
> 8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
> хочется включить дедупликацию, то, личного опыта нет, но говорят что
> нужно примерно 5 гигабайт RAM на каждый терабайт данных.
Вот, кстати. Память она жрёт, при включенном дедупе, я вспомнил.
И память с ECC, соответственно, тоже нужна при включении дедупа.
Вот только нужен и он на хранилище?

> То есть в
> случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
> можно включить на уже работающей системе, когда угодно, как и выключить.
> А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
> я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
> вот дедупликация...
Там и сжатие есть?

> я за несколько лет так и не смог увидеть в домашних
> условиях где бы это могло помочь. Если делаются какие-то "ответвления"
> типа clone или там snapshot (например есть chroot какой-нибудь ОС,
> хочется из него наделать разных других chroot-ов для контейнеров) -- то
> там и так только дельты хранятся. Где-то я чуть ли не в официальных
> мануалах Sun-а (Oracle?) видел что зачастую правильное использование
> clone-ов (snapshot и прочего) решает большинство проблем с
> избыточностью, где люди думают о дедупликации. Хотя если это
> какой-нибудь там хостинг картиночек, где одни и те же кошечки тысячами
> пользователей заливаются, то там поможет. В ZFS есть команда zdb -S
> mypool которая "эмулирует" дедупликацию и показывает поможет ли она или
> нет. Буквально вчера на одном из разделов её делал у себя (подумал что
> может пора?):
> 
> # zdb -S storage
> Simulated DDT histogram:
> 
> bucket  allocated   referenced
> __   __   __
> refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
> --   --   -   -   -   --   -   -   -
>  18.87M   1.11T   1.10T   1.10T8.87M   1.11T   1.10T   1.10T
>  26.31K807M782M782M13.0K   1.63G   1.57G   1.57G
>  4  250   31.2M   27.2M   27.2M1.08K138M120M120M
>  8   11   1.38M653K653K  102   12.8M   5.61M   5.61M
> 167896K134K134K  156   19.5M   2.38M   2.38M
> 321128K   20.5K   20.5K   52   6.50M   1.04M   1.04M
>  Total8.88M   1.11T   1.10T   1.10T8.89M   1.11T   1.11T   1.11T
> 
> dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 
> 1.01
> 
> Видно что о ней думать не приходится совершенно.
> 
У вас прям по ZFS сплошные плюсы.
Вы, случаем, не её разработчик, так нахваливаете? :-)
Минусы-то, недоработки и баги у неё какие есть?

Re: ZFS

*** artiom  [2017-06-25 00:21]:
>Там и сжатие есть?

Я вот тут упомянул: 
https://lists.debian.org/debian-russian/2017/06/msg00618.html
что у меня на практике 60 GB MongoDB превратилась в 20 GB занятого места
и соответственно в памяти кэш ФС тоже в три раза меньше жрёт. Это если
LZ4 сжатие, которое очень CPU дешёвое. По-умолчанию оно отключено, если что.

>У вас прям по ZFS сплошные плюсы.
>Вы, случаем, не её разработчик, так нахваливаете? :-)
>Минусы-то, недоработки и баги у неё какие есть?

Я очень консервативен и моё внимание сложно привлечь новинкой, чаще я
скажу "очередное хипсторское поделие" (честно говоря я с Debian ушёл
из-за его systemd по-умолчанию, хотя использовал 7 лет). Но вот ZFS,
действительно удивительно, оказалась для меня неким Святым Граалем в
мире ФС/RAID/LVM/etc. Нет, я не её разработчик, денег за хорошие слова в
её сторону не получаю :-). Просто в искреннем восторге от неё и за все
годы знакомства с ней и использования жалел только о том, что раньше и
активнее не начал её использовать.

Минус наверное могу сказать только тот, что не всегда понятно как лучше
поднастроить её для хорошей производительности например под СУБД. RAIDZ
можно сконфигурировать так, что там будут очень большие потери места
впустую. Все эти шаманства с разными размерами блоков... без этого
никуда, ведь ZFS не может же знать какие прикладные задачи поверх неё вы
применяете. Хотя наверное это относится к любой ФС/mdadm/LVM -- tuning
касается всего, но на ZFS это может отражаться в десятках процентах или
даже разов. В общем опыт и понимание нужны.

Дорогая она. Например нужно иметь пустого места достаточно, чтобы
фрагментация не убила производительность в ноль. То есть, вместо 10 TB
диска вы получите 8 чтобы всё было более менее (хотя если речь про
хранение последовательно записанных файлов только для чтения, типа
хранилки фильмов, музыки, архивов с бэкапами, то можно чуть ли не битком
набивать). На 32-бит системах она вроде как официально даже не
поддерживается.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS


> Дорогая она. Например нужно иметь пустого места достаточно, чтобы
> фрагментация не убила производительность в ноль. То есть, вместо 10 TB
> диска вы получите 8 чтобы всё было более менее (хотя если речь про
> хранение последовательно записанных файлов только для чтения, типа
> хранилки фильмов, музыки, архивов с бэкапами, то можно чуть ли не битком
> набивать).
O_O
Вы хотите сказать, что она жрёт 20% места под метаданные?!
Или что она просто начинает сильно фрагментироваться, при заполнении?
Во втором случае, ведь должна быть онлайн дефрагментация...

> На 32-бит системах она вроде как официально даже не
> поддерживается.
> 
32 бита ушли из того сегмента, где нужна ZFS.

Re: ZFS

*** artiom  [2017-06-25 00:54]:
>Вы хотите сказать, что она жрёт 20% места под метаданные?!
>Или что она просто начинает сильно фрагментироваться, при заполнении?

Из-за её copy-on-write природы она начинает сильно фрагментироваться,
верно. Любое изменение данных это создание полной копии и блока данных и
сопутствующей метаинформации. Само собой перед записью они агрегируются,
но всё-равно при записи большого файла на диск он никогда не будет
размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы --
то есть на диске идут сколько-то блоков данных файла, потом всякая
метаинформация, снова блоки, потом метаинформация. Причём каждый набор
метаинформации создаваемый в последующих 1-5 секунд делает неактуальным
предыдущую. То есть она потенциально становится свободным местом.
Например *X*FS реально абсолютно последовательно может разместить файл
на диске, а ZFS нет -- поэтому и нужно много памяти под кэш чтобы
сгладить всё это, не создавая огромный IO на диск.

Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать
определённое количество дисков и определённый размер блока (recordsize),
то можно, фактически, просто так потерять 50% места буквально в пустую.
Вот тут есть тема про это: 
https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
RAIDZ сделан так, что добавляет чётность, но кол-во получившихся блоков
для данных+parity должны быть кратны чему-то там и поэтому там будет
создан блок чисто для padding-а, для выравнивания некоего, не несущего
полезных данных. Статья эта подчёркивает что в RAIDZ на parity всё же
будет больше затрачено места чем в аналогичных уровнях RAID, как
правило.

>Во втором случае, ведь должна быть онлайн дефрагментация...

Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
resilvering-а, то бишь rebuild-а на диски, при котором на них будет
дефрагментированный образ создан. Можно сделать полный zfs send и
восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не
всегда допустимо и возможно. Есть хаки в виде просто копирования файла:
cp file file.tmp && mv file.tmp file, чтобы сделать его
дефрагментированным, если, например, он был медленно записан (то бишь,
из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они
говорят что создание online дефрагментации это жутко нетривиальная вещь,
требующая чуть ли не переписывания всего кода, ибо везде всё одна
крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так,
чтобы гарантировать "железную" надёжность и поэтому не будут делать.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS



25.06.2017 01:06, Sergey Matveev пишет:
> *** artiom  [2017-06-25 00:54]:
>> Вы хотите сказать, что она жрёт 20% места под метаданные?!
>> Или что она просто начинает сильно фрагментироваться, при заполнении?
> 
> Из-за её copy-on-write природы она начинает сильно фрагментироваться,
> верно. Любое изменение данных это создание полной копии и блока данных и
> сопутствующей метаинформации. Само собой перед записью они агрегируются,
> но всё-равно при записи большого файла на диск он никогда не будет
> размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы --
> то есть на диске идут сколько-то блоков данных файла, потом всякая
> метаинформация, снова блоки, потом метаинформация. Причём каждый набор
> метаинформации создаваемый в последующих 1-5 секунд делает неактуальным
> предыдущую. То есть она потенциально становится свободным местом.
> Например *X*FS реально абсолютно последовательно может разместить файл
> на диске
Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал,
посмотрел e4defrag-ом, меньше двух процентов.

> а ZFS нет -- поэтому и нужно много памяти под кэш чтобы
> сгладить всё это, не создавая огромный IO на диск.
> 
Так всё-таки RAM или дисковое пространство свободное больше требуется?

> Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать
> определённое количество дисков и определённый размер блока (recordsize),
> то можно, фактически, просто так потерять 50% места буквально в пустую.
> Вот тут есть тема про это: 
> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
Почитаю, но пока начал с педивикии.

> RAIDZ сделан так, что добавляет чётность, но кол-во получившихся блоков
> для данных+parity должны быть кратны чему-то там и поэтому там будет
> создан блок чисто для padding-а, для выравнивания некоего, не несущего
> полезных данных. Статья эта подчёркивает что в RAIDZ на parity всё же
> будет больше затрачено места чем в аналогичных уровнях RAID, как
> правило.
> 

>> Во втором случае, ведь должна быть онлайн дефрагментация...
> 
> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
> resilvering-а, то бишь rebuild-а на диски, при котором на них будет
> дефрагментированный образ создан.
Условно: mv всего на другой раздел?

> Можно сделать полный zfs send и
> восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не
> всегда допустимо и возможно. Есть хаки в виде просто копирования файла:
> cp file file.tmp && mv file.tmp file, чтобы сделать его
> дефрагментированным, если, например, он был медленно записан (то бишь,
> из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они
> говорят что создание online дефрагментации это жутко нетривиальная вещь,
> требующая чуть ли не переписывания всего кода, ибо везде всё одна
> крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так,
> чтобы гарантировать "железную" надёжность и поэтому не будут делать.
> 
А нет a-la e4defrag?

Re: ZFS

*** artiom  [2017-06-25 01:36]:
>Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал,
>посмотрел e4defrag-ом, меньше двух процентов.

На моём ноутбуке сейчас :-):

# zpool list
NAME SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH
secure  1008M   149M   859M -68%14%  1.00x  ONLINE
stcvol  15.9G  1.83G  14.0G -42%11%  1.00x  ONLINE
zroot 89G  32.3G  56.7G -44%36%  1.00x  ONLINE

>Так всё-таки RAM или дисковое пространство свободное больше требуется?

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

>> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
>> resilvering-а, то бишь rebuild-а на диски, при котором на них будет
>> дефрагментированный образ создан.
>Условно: mv всего на другой раздел?

Да, можно и так. Суть одна. Заставить прочитать и записать в другое
место. Чтение пускай не очень быстрое (из-за фрагментированного файла),
но запись уже более быстрая (менее разряженно).

>А нет a-la e4defrag?

Нету ни этого, ни xfs_fsr. Только вот хаки. Которые метаинформацию никак
не трогают. Повторюсь: проблема фрагментации зависит от режимов
нагрузки. Но достаточно, в большинстве случаев, просто иметь место про
запас и не париться.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

*** artiom [2017-06-25 00:21]:
>У вас прям по ZFS сплошные плюсы.

Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов
от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы
консистентность данных была в порядке, то при записи вы обязаны сделать
атомарную запись всех stripe-ов на все диски. А сделать это атомарно на
три (или более) аппаратных диска просто невозможно. Внезапное выключение
питания запросто приведёт к тому что на каком-то диске что-то
недозаписано. И встаёт проблема: кому доверять и как понять на ком
недочёт. Решают аппаратные контроллеры её за счёт использования памяти,
подпитываемой батарейкой (или SSD в контроллере), где хранится
информация о записанных данных. При восстановлении питания, он тогда
сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры.
Программно так не сделать и при внезапном выключении питания вы сильно
рискуете реально потерять данные в stripe массива. С RAIDZ всё что
увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей
или нет. При пропаже питания вы безусловно рискуете потерять то что не
смогло быть чисто физически записано на диск, но никакого нарушения
целостности. То есть фича дорогих аппаратных контроллеров с батарейкой
или SSD на боту -- бесплатно в софте.

--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF

Re: ZFS