8 марта 2014 г., 16:13 пользователь Slawa Olhovchenkov <[email protected]> написал: > On Sat, Mar 08, 2014 at 04:06:39PM +0200, Anton Sayetsky wrote: > >> 8 марта 2014 г., 16:01 пользователь Slawa Olhovchenkov <[email protected]> >> написал: >> > On Sat, Mar 08, 2014 at 03:57:50PM +0200, Anton Sayetsky wrote: >> > >> >> 8 марта 2014 г., 15:54 пользователь Slawa Olhovchenkov <[email protected]> >> >> написал: >> >> > On Sat, Mar 08, 2014 at 03:40:55PM +0200, Anton Sayetsky wrote: >> >> > >> >> > >> >> >> > root@slw:/home/slw # zpool replace ztest md1 md2 >> >> >> > root@slw:/home/slw # zpool list ztest >> >> >> > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> >> >> > ztest 19.9G 234K 19.9G 0% 1.00x ONLINE - >> >> >> man zpool >> >> >> /autoexpand >> >> >> > autoexpand=on | off >> >> >> > Controls automatic pool expansion when the underlying LUN is grown. >> >> >> Похоже, без zfsd ни autoreplace, ни autoexpand работать не будут >> >> >> принципиально. Только вот я до сих пор не могу понять, какого хрена >> >> >> для этого нужен демон, почему этим не занимается сама ФС. >> >> > >> >> > вот покажи на солярке пример. >> >> > а то творческой трктовкой документации можно долго заниматься. >> >> Под рукой нету, но HSP там тоже управляет FMD, а не сама ZFS. С >> >> autoexpand - не в курсе. Но блин, зачем такой изврат? Почему все >> >> остальные существующие реализации RAID сами делают replace, а ZFS - >> >> нет? %) >> > >> > когда они делают expand? при скрытом оффлайновом изменении размера? >> > тут тебе ни FMD ни zfsd не помогут -- в момент expand соответсвующий >> > zfs -- offline. >> Ещё раз - читаем внимательно. >> Как и чем должен делаться expand - я не в курсе, не видел. Судя по >> ману - при установленном autoexpand должно само. И, кстати, ничего не >> мешает увидеть при импорте пула, что размер vdev стал больше, и >> расширить пул. > > на все -- воля аллаха^W программиста. > и очевидно что в данном месте оно не системно-зависимо. > т.е. на солряке будет то же самое. Вероятно. Значит, при autoexpand=on какой-то демон или скрипт должен это делать.
>> Второе же предложение было о том, что ZFS не умеет _сама_ делать >> replace в redundant-конфигурациях. Под солярой для этого нужен FMD, >> под фрёй - ждём zfsd. И я выразил сожаление, что ZFS - единственная >> реализация RAID, которая _требует_ что-либо, кроме самой себя, дабы >> починить degraded-массив. > > а по мне так и хорошо, поскольку позволяет скриптами получить нужное > поведение. > например для случая супермикровксих коробок на 72 диска, когда в одной > корзине два диска -- в этом случае надо очень тщательно выбирать на > кого заменяться. Adaptec - turn off automatic failover, gmirror - configure -F|configure -n. Как там в LSI RAID, mdraid и т.п. - не помню уже. В общем-то, для ZFS - это то самое свойство autoreplace. Но суть в том, что все остальные как аппаратные, так и программные реализации RAID умеют отключать автоматическую синхронизацию и не требуют лишних сущностей для её выполнения. А у нас под фрёй из-за этого беда - ФС автосинхронизацию делать не умеет, а демона, который бы её пинал - нет. Поэтому приходится пейсать костыли с zfs status -x | grep и т.д.
