On Sun, Jan 19, 2014 at 06:58:01PM +0700, Eugene Grosbein wrote: > On 19.01.2014 18:05, Anton Sayetsky wrote: > > 19 января 2014 г., 9:46 пользователь Eugene Grosbein > > <[email protected]> написал: > >> fsck для UFS давно необязателен аж двумя способами - SUJ и gjournal. > > Но лишь до тех пор, пока не побьётся сам журнал, не так ли? :) > >> SUJ сыровато, если записи относительно чтения мало, то gjournal самое то. > >> gcache поверх массива крайне рекомендуется в случае UFS. > > Первый юзал некоторое время на десктопе и сейчас работает на > > PXE-сервере - так что по сути на больших инсталляциях не пользовал, а > > на маленьких вроде проблем нет. > > Потому и говорю, что SUJ сыровато - у меня на одном сервере > на 9.2-STABLE стабильно воспроизводится повреждение журнала SUJ, > достаточно просто систему дернуть при помощи IPMI "Reset Server". > > С повреждениями журнала у gjournal при исправном железе не сталкивался, > хотя активно использую. > > > В общем-то, всё равно получается усложнение и так громоздкой > > конструкции - юзать graid или RAID-контроллер, наворачивать на это > > gcache... > > Можно подумать, ZFS проста как три копейки... > А отсутствие fsck это палка о двух концах :-) > Может получиться момент, когда fsck очень захочется, а нету. > > > Да и UFS, ЕМНИП, весьма неторопливая ФС, особенно когда > > начинается random access. > > У UFS всё прекрасно со скоростью при random access, > разумеется, пока рабочий объем данных в кеш влазит: > http://dadv.livejournal.com/141752.html > > Когда влазить перестанет, у любой FS начнутся проблемы на HDD, > тут кроме SSD или аналогов ничего не спасёт. ZFS разве отличается > высокой скоростью при недостатке памяти под кеш? >
все зависит от того, как готовить. но при озвученных вводных самый плохой random access уложится в требования по производительности.
