Файлопомойка

[Alex Keda]

Тут на работе спор возник...
Что лучше ставить на файлопомойку - винду, фрю с UFS, или линух с extfs
ну, моё мнение понятно, упавшей UFS я ни разу не видел.
Винду со слетевшей NTFS я видел три дня назад (из-за чего движения и пошли), есть примеры из жизни падения всяких ext2/3?
и вообще - кто что думает по этому вопросу.
=========
добавление - файлопомойка черезвычайно ответственная....

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[serge]

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

[Alex Keda]

на самом деле не в этом вопрос - что хочется, что нет.
вопрос в том что нужно - а нужно минимальное время простоя, и вероятность потери данных.
Заодно, желательно, чтобы подымать было попроще.
==========
а винда...
когда мы тут всем отделом медитировали напротив экрана, когда chkfs бежал полдня по поломанному MFT и ругался через раз

"чё-то там про плохой иноде, делетинг этот самый иноде"

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

[serge]

Вот нехочется имеено из-за соображений надежности.
Хотя то что, бэкап неотработал, скорее всего, недоработка админа тамошнего . А восстановление ФС под виндой, как ни крути будет небыстрое и не 100% надежное. Соответственно время восстановления из бэкапа включит в себя и время на установку винды (если совсем все помрет конечно). Либо делать периодически бэкап всего образа диска и разворачивать через Acronis, тут время восстановления намного меньше, но софт платный.
Подобные проблемы могут и под *nix возникнуть. ufs у меня не умирала, но на полумертвом hdd периодически терялись файлы.
Хорошим вариантом здесь будет зеркальный raid + бэкап. ОС какой-нить *nix.

[Alex Keda]

да зеркало/бэкапы - разумеется.
а вот дальше выбор ОС - менения, как я сказал разделились... натрое

[Adekamer]

ext3 на моей памяти и памяти моих знакомых непадало
это журналируемая ФС - уровень журналирования выьираете сами - понятно что выигрывая в надежности (ставя маниакальный уровень журналирования) проигрываете в производительности и наоборот - гонясь за производительностью - повышаете шансы на потерю данных
ext3 в частности хороша еше тем - что у нее естть возможность выставления дополнительных пермишенов - в некоторых случаях очень удобно

Код: Выделить всё

ATTRIBUTES
       When a file with the ’A’ attribute set is accessed, its atime record is not modified.  This
       avoids a certain amount of disk I/O for laptop systems.

       A file with the ‘a’ attribute set can only be open in append mode for  writing.   Only  the
       superuser  or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this
       attribute.

       A file with the ‘c’ attribute set is automatically compressed on the disk by the kernel.  A
       read from this file returns uncompressed data.  A write to this file compresses data before
       storing them on the disk.  Note: please make sure to read the bugs and limitations  section
       at the end of this document.

       When  a  directory  with  the  ‘D’  attribute set is modified, the changes are written syn-
       chronously on the disk; this is equivalent to the ‘dirsync’ mount option applied to a  sub-
       set of the files.

       A  file  with the ‘d’ attribute set is not candidate for backup when the dump(8) program is
       run.
 The ’E’ attribute is used by the experimental compression patches to indicate that  a  com-
       pressed file has a compression error.  It may not be set or reset using chattr(1), although
       it can be displayed by lsattr(1).

       The ’I’ attribute is used by the htree code to indicate that a directory is  being  indexed
       using  hashed  trees.   It may not be set or reset using chattr(1), although it can be dis-
       played by lsattr(1).

       A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no  link
       can  be created to this file and no data can be written to the file.  Only the superuser or
       a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

       A file with the ‘j’ attribute has all of its data written to the ext3 journal before  being
       written  to  the  file  itself,  if  the  filesystem  is mounted with the "data=ordered" or
       "data=writeback" options.  When the filesystem is mounted with  the  "data=journal"  option
       all  file  data is already journalled and this attribute has no effect.  Only the superuser
       or a process possessing the CAP_SYS_RESOURCE capability can set or clear this attribute.

       When a file with the ‘s’ attribute set is deleted, its blocks are zeroed and  written  back
       to the disk.  Note: please make sure to read the bugs and limitations section at the end of
       this document.

       When a file with the ‘S’ attribute set is modified, the changes are  written  synchronously
       on  the  disk;  this  is  equivalent  to the ‘sync’ mount option applied to a subset of the
       files.
A directory with the ’T’ attribute will be deemed to be the top  of  directory  hierarchies
       for  the  purposes  of  the  Orlov  block allocator (which is used in on systems with Linux
       2.5.46 or later).

       A file with the ’t’ attribute will not have a partial block fragment at the end of the file
       merged with other files (for those filesystems which support tail-merging).  This is neces-
       sary for applications such as LILO which read the  filesystem  directly,  and  which  don’t
       understand  tail-merged  files.   Note: As of this writing, the ext2 or ext3 filesystems do
       not (yet, except in very experimental patches) support tail-merging.

       When a file with the ‘u’ attribute set is deleted, its contents are saved.  This allows the
       user  to  ask  for its undeletion.  Note: please make sure to read the bugs and limitations
       section at the end of this document.

       The ’X’ attribute is used by the experimental compression patches to indicate  that  a  raw
       contents  of  a  compressed  file can be accessed directly.  It currently may not be set or
       reset using chattr(1), although it can be displayed by lsattr(1).

       The ’Z’ attribute is used by the experimental compression patches to indicate a  compressed
       file is dirty.  It may not be set or reset using chattr(1), although it can be displayed by
       lsattr(1).

[Andy]

да зеркало/бэкапы - разумеется.
а вот дальше выбор ОС - менения, как я сказал разделились... натрое

Винду сразу на помойку, а вот в целях экскремента стоит попробовать ext3. Может быть
Линукс окажется не таким уж и плохим, а Лис?
p.S: Ну Райзер ты сам ставить вряд ли будешь

[serge]

А может стоит попробовать ZFS... Много чего в ней хорошего придумади и для производительности и для надежности. Тада линух снова не нужен будет

[Alex Keda]

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

[helloworld]

Поставь RHEL 5 или CentOS 5 c ext3 и забудь про нее. Очень стабильная как ос так и фс.

[Alex Keda]

БСД с УФС тоже...
я аргументов хочу за то или иное...
Пока рассуждения на воде.
Журнал это хорошо, NTFS, кстати, тоже очень стабильная файловая система, и очень устойчивая. И журналируемая.
Однако - я видел то что видел - как улетают данные.
На UFS я такого не видел. Плюс восстанавливать проще будет - тут большую часть вреемни прыгали как поднять ОС - чтобы загрузиться - там таких проблем не будет, можно будет сразу к делу перейти.

[Andy]

Теперь о восстановлении данных с ufs подробнее. Статья Дикенса отличная, но...
Если тачка виндовая, к примеру? Какой софт применять для восстановления файлов, информации,
и тд?

[skeletor]

Скажу из опыта.
У нас на работе тестеры по несколько раз в день ресторят винду с помощью Acronis. Не хочет ресториться с ФС UFS по сети. Вернулись обратно на винду NTFS - всё хорошо.
Имхо - надо подходить к кадой задачи индивидуально. Для одних задач одна ФС подходит, для других - возникают проблемы.

[helloworld]

БСД с УФС тоже...
я аргументов хочу за то или иное...
Пока рассуждения на воде.
Журнал это хорошо, NTFS, кстати, тоже очень стабильная файловая система, и очень устойчивая. И журналируемая.
Однако - я видел то что видел - как улетают данные.
На UFS я такого не видел. Плюс восстанавливать проще будет - тут большую часть вреемни прыгали как поднять ОС - чтобы загрузиться - там таких проблем не будет, можно будет сразу к делу перейти.

Аргументы:
Есть сервер с Centos 5, на нем 4 винта в рейде 10, ext3.
Есть сервер с FreeBSD 6.2, на нем 2 винта в рейде 1, ufs.
Оба как файловые хранилища. Как запустил 65 дней назад, так оба работают до сих пор. Ниодного глюка с "зависанием" процессов не было.
Какие еще примеры привести не знаю, все работает как часы.

Почему склоняюсь к ext3 - имхо с нее просче вытянуть данные чем с ufs если винты умрут.

[Alex Keda]

чтоб винты не мёрли - избыточность и бэкапы
вопрос в вытягивании если порушилась ФС...

[100kg]

думаю что камень ножницы и бумага, решит ваш вопрос
мне и лин и вин и бсд нравиться

[Fastman]

UFS ни разу не видел тоже слетевшей.
NTFS несмотря на простоту и устойчивость, вижу упавшие постоянно.
Так как современное телевещание не обходится без массивов... то я их повидал достаточно.
Для примера, ставили сервачек который должен был держать туеву хучу мелкого файла (30-120 кб один файл - Ключевые кадры из видео),
так вот при достижении в одной папке количества файла 7-10 тысяч NTFS дружно лапки вверх задирает. Пришлось
писать разработчикам программного обеспечения чтобы это файло хотя бы по папкам раскладывалась. Работает...
но лучше не стало, тормозит нещадно и в случае пропадания питания (один раз была авария и упсы выжрало) 2 террабайтный этот массивчик
пришлось подымать 3 дня.
Из хорошо зарекомендовавших - XFS линуксовая.
Ну и недавно пощупал ZFS На BSD - понравилось ) Пока не буду делать выводов потому как еще не так долго работет.

[serge]

Ну и недавно пощупал ZFS На BSD - понравилось )

Заметку в виде статьи не сделаешь? Тоже интересно с ней повозиться.

[Alex Keda]

пока не стабле - в продакшен не пойдёт....

[serge]

так вот пока не стайбл нужно самим освоить

[schizoid]

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

[Fastman]

Ну и недавно пощупал ZFS На BSD - понравилось )

Заметку в виде статьи не сделаешь? Тоже интересно с ней повозиться.

Ну честно нечего писать... Подгружаешь модуль и вперед.. кстати где то на
форуме ссылочка валялась вот по ней и делал. Там делов то на 5 минут.
Вообще нехорошо конечно в продакшн пихать вещи которые не стэйбл...
но у меня выбора не было, ufs помедленней оказалась... да еще и через самбу
с нее видео по сетке нужно раздавать... на 50 пользователях работает не вопрос
без тормозов.... когда за 100 - уже видно что не летает. Заказчик зажал хорошее
железо поставить... вот пока временное решение

[serge]

В плане поставить я понимаю что не сложно. Интересны ее настройки. А их там по моей поверхностой оценке хватает
Щас, например, читаю про ZFS на http://citkit.ru/articles/475/

[Andy]

Касаемо zfs - может быть http://sunhelp.ru/ чем-то поможет.

[Гость]

а zfs не стейбл по одной простой причине: паника вида kmem map too small слишком живучая. Эту панику я вижу еще с момента импорта в cvs-src в мае. До сих пор данные целы. Даже когда мой hdd проказничал (постоянные read error переваливали за тысячу и ставили систему на лопатки) ничего не изменилось, просто zpool clear после того как хард исправится и можно дальше ехать.
Если и не ошибаюсь, то и из-за этой же паники swap на zfs не рекомендуется, но последнее время у мя даже после того как переполняется tmpfs (неа, не старая tmpmfs, а та, что портирована с netbsd) спокойно переносит перегрузки без сильного урона к быстродействию.

zfs не променяю. Т.к. теперь я точно уверен, что мои данные не повреждены. В случае с ufs такой уверенности не было, т.к. если во время background_fsck пройзойдет ребут... Жаль что только пока приходиться загружаться с cd-rom'а, иначе все харды под эту фс целиком не отправить, бо загрузчик boot0 пока не научился с ней работать, зато он умеет работать с cd9660 .

Кстати, насчет журналируемой фс. Никто не в курсе что там с lfs? Вроде ее проект netbsd собирался доработать.