Попытка удаления файла, имеющего размер порядка 7 Тб, приводит к зависанию Linux сервера
с ФС ext4 или reiser на несколько часов.Решение: проблема исчезает при использовании файловой системы XFS.
URL: http://community.livejournal.com/ru_linux/2289534.html
Обсуждается: http://www.opennet.me/tips/info/2154.shtml
Все гениальное просто
>Все гениальное простоТем не менее, удаление файла ~30 секунд XFSом я видел :P. Всего-то 4Gb торент сдуру слитый без преаллокации. Представляю себе что будет если такой же вермишелью записать 7Tb...
Понимаю, что это флуд. Но что может занимать столько места одним файлом? Делаю предположение, что это может быть видео?
база данных например
На 7ТБ? база данных чего?
>На 7ТБ? база данных чего?http://community.livejournal.com/ru_linux/2289534.html
> PS. Предвосхищая вопросы. Железка это многоузловой промконтроллер, управляющих огромным
> (450 тыс. тонн) газохранилищем. В связи с событиями на СШ ГЭС, начальством было
> приказано debuglevel увеличить на 2 пункта (условно с 1 до 4 при максимальном 6).
> Если раньше 7Тб эти набегали в лучшем случае за 50-60 суток, то сейчас эти 7 Тб
> заполняются за 18-20 часов.
фигасе, и это все дело одним файлом? в принципе, объясняет многое уровень русского языка у того коллеги. совсем плохо, если он живет в России. уровень языков программирования, надеюсь, у него выше...
оттого и бешеные проблемы преодолением трудностей, которые создали себе сами. дебаг-инфу можно создавать и в компактной форме, вплоть до битовой кодировки. а дальше уже и на лету компримировать и прочее, если мощности позволяют.
да, конечно, зависит от "запущенности" софта
>объясняет многое уровень русского языка у того коллеги.Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
Объясняет все "Конфиг Core2Quad 6600/8 Гиг ECC/i3000 Некий java софт от большой технологической железки пишет огромный файл до 7 Тб".Выводов несколько. Софт писали недавно, оборудование закупили недавно, писали на java, но не в этом дело, еще дело в "технологической железке", которая генерирует файлы по 7ТБ за сутки.
Что бы они делали десять лет назад (в 1999), покупали бы CRAY? Там внутри явно проблемы с оптимизацией, т.к. сейчас, куда не плюнь, практически все данные передаются/хранятся в сжатом виде и сжимаются по многу десятков раз (ethernet/SDH/PCI express/DOCx/PDF/JPG/MP3/FLAC/MP4...). Только сжимаются они не в ZIP архив 7ТБ базу, а на том уровне, на котором проще всего её осмыслить. Как минимум в голову приходит PNG.
основная проблема это "Некий java софт"? проверить, не так уж и сложно, экспериментируя с меньшими размерами файла проверять элементарно в top, что происходит. есть и другие подручные средства линукс
>Как минимум в голову приходит PNG.Это если данные от датчиков поступают в бинарном виде. Если это лог, то сжимать его еще проще, т.к. 90%(из головы взял) данных одинаковые. Ну не верю я, что датчик выдает каждую секунду разные данные + штамп времени, там меняется всего 1,2,3 бита! Идентификатор датчика не меняется вовсе. Есть преобразования Фурье, есть, да чего только нет... Было бы желание.
>Далее этот файл сжимается зипом до приемлимых размеров (до 200-400 Гб)Полный звездец! Значит база легко может весить 200-400Гб сама по себе. А если применять специальные методы (выше написал, что сразу пришло в голову), реальный размер этой базы - сотни мегабайт и даже мегабайты!
На таком железе данные из LOG'а извлекутся мгновенно, а вот из 7ТБ базы в ZIP на ленте - ПОЛНЫЙ ЗВЕЗДЕЦ!
Разрабатывали систему, меньшего масштаба, для "мобильных "электростанций. При условий что датчиков от 50 до 500, при постоянной работе двигателей, и без усреднения данных(т.е. данные пишутся примерно от 10000 в секунду), база занимала за 3 месяца около 40 гиг.
база мускул (ембедед), 2гига память. решение используется уже на нескольких десятках объектов в течении 4х лет
>база мускулMySQL - база данных специально для критически важных объектов, а вот 5 формул из 2 курса любого вуза применить - все, сломается все критическая надежность, этого же нельзя допустить!
Еще раз говорю, даже процессор без злых алгоритмов + алгоритмов самопроверки и т.д. не работает. Почему нельзя записывать показания датчиков в "сжатом" виде? Неужели у нас нет на это ГОСТов? Как записывали показания датчиков до 1998 года?
Зачем записывать в MySQL (где тоже могут быть ошибки) базу явно одни и те же цифИри? Чтобы отвязались? Мы вот мол логи пишем, если чего, это не мы.
Таки нет, цифры разные при старте двигателей и во время работы оного. не синхронные они.
следить нужно.
а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?
>Таки нет, цифры разные при старте двигателей и во время работы оного.
>не синхронные они.
>следить нужно.
>а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?Дык и на интербейз посмотреть можно и на sqlite
и даж свое ченить на коленке слабать
_СТАВИТЬ_ сервер баз данных для этого???
у нас "мускул ембедед"
> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?часто показывает на уровень образования. к примеру, мне тут один птушник пыталя давеча доказать, что логические и битовые операции - вещи идентичные.
но, с русским языком я могу и заблуждаться. :)
>> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
>
>часто показывает на уровень образования. к примеру, мне тут один птушник пыталя
>давеча доказать, что логические и битовые операции - вещи идентичные.
>
>но, с русским языком я могу и заблуждаться. :)Правильное владение русским языком очень важно. Наприимер, сколько Ваших, Karbofos, сообщений в этом топике я ни прочитал - столько раз был в замешательстве: что Вы хотите сказать, какую точку зрения поддерживаете? А всего-то плохое владение языком. :)
если бы я конкретно пощупал систему, на которой этот гемор происходит, где допустили ТАКОГО рода раздолбайство с протоколированием на некоем ява софте... а так, кроме общих рекомендаций по поиску причин зависонов, которых аффтар явно не знает, аки простые методы диагностирования, нечего и сказать. а если и скажу, так аффтар этого, скорее, не поймет.
так что лично Вы можете быть в замешательстве от каждой буквы, написанной мной. если уж так сильно хотите. io wait тоже вызывает недоумение?
Вы об каких логических операциях говорите, в формальной логике или в математической?И можно повторить то место, в котором ПТУшнег с вами наконец согласился.
он утверждал, что(boolTest1 ^ boolTest2) // boolTest1, boolTest2 are bool
одно и тоже с
(int32x1 ^ int32x2) // int32x1 int32x2 are integer
(опреация исключаещего или в сях)
пришлось даже программу писать, ибо в книжки он заглядывать не любит.
> Как минимум в голову приходит PNG.Чо? Газохранилище генерирует картинки (фотографии газа? :-)) ) и сохраняет их в базу (нафига? учили же что лучше в файловой системе картинки хранить).
Да, Karbofos оказался прав.>учили же что лучше в файловой системе картинки хранить
А меня учили базы данных хранить в RAW разделах.
>Газохранилище генерирует картинки
В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как можно осознанно, эффективно и без потерь сжать битовую последовательность.
>>учили же что лучше в файловой системе картинки хранить
>А меня учили базы данных хранить в RAW разделах.Оффтопик, речь о файловых системах. И что мешает завести под блобы отдельный раздел с подходящей файловой системой?
>>Газохранилище генерирует картинки
>В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от
>изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как
>можно осознанно, эффективно и без потерь сжать битовую последовательность.Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны именно на графику и звук соответственно, иначе бы жали и графику во FLAC и музыку в PNG.
>Оффтопик, речь о файловых системах.Честно говоря, я совсем не понял о чем речь в данной статье. Какие-то mysql базы невероятного размера на нестабильной версии файловой системы...
>Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны
>именно на графику и звук соответственно, иначе бы жали и графику
>во FLAC и музыку в PNG.Может я изъясняюсь непонятно... Мне показалась странной база в 7ТБ, которую каждые пол дня пытаются удалить... Вот я и предположил, что по аналогии с музыкой и звуком можно и эту информацию как нибудь сжать.
> Уровень русского языка ничего не объясняетЗаблуждение. Невозможно много читать и не знать языка. Плохой русский - мало читал. Какой он тогда, к жукам майским, специалист, если он за всю жизнь 3 книги прочёл? Под хвост сразу таких гнать надо с таких проектов. Понимаете?
А что не так с русским языком у автора того топика на ЖЖ?
ха, а решить задачу на ext4 слабо?
# unlink /BIGFILE.sqlне?
mount -o remount,barrier=0 /dev/superraid
не?
дайте массив на 10ТБ, проверю :)
Однако, решение никак не коррелирует с заголовком статьи ;( Если уже есть файл, поменять ФС вряд ли удастся на лету. Лучше наябедничать разработчикам, чтобы поправили явный баг.
А Линус кого нибудь не придушит? :D Помню, предыдущие "явные" баги в емаксах, "жёстких дисках", "сетевых картах", самбах вели в хозяйство Линуса, а он на попытки их исправить обвинял бедолагу в неадекватности, говорил про вещества :D Угрожал покинуть пост, как в мультике "либо он, либо я" :D
Прям как злые тролли в России. Которые тоже не понимают очевидность бага и отвечают несерьёзно. "Тормозит KDE 4? У тебя просто кривые руки".
Это не явный и не баг, это давно известная проблема ext2-3
echo "0" > ./bigfile.db
rm ./bigfile.db?
>echo "0" > ./bigfile.db
>rm ./bigfile.db
>
>?нет
time echo 1 > big0
real 0m2.705s
user 0m0.000s
sys 0m0.367stime rm -f big0
real 0m2.370s
user 0m0.001s
sys 0m0.347s
А тот же експеремент с jfs как?
Use ZFS, Luke!
>Use ZFS, Luke!И, конечно, это панацея и всем станет хорошо? :) А вы, к слову, проверяли ее под такой нагрузкой? А то реально любопытно как оно будет выкручиваться если такой файл записать на нее в виде вермишели (мелкими порциями без преаллокации). А то версионники сами то к фрагментации склонны (дозапись логов же). Если специально подогнать клинический случай то что будет? Любопытно :). Вы хотите это любопытство удовлетворить? Камон, you're welcome.
>>Use ZFS, Luke!
>
>И, конечно, это панацея и всем станет хорошо? :)"В общем, да." (c) Парацельс
>А вы, к слову, проверяли ее под такой нагрузкой?
Зачем спрашивать? Нет ещё.
>А то реально любопытно как оно будет выкручиваться если такой файл записать на нее в виде
>вермишели (мелкими порциями без преаллокации).Вот и мне тоже. Любопытно. Хотелось бы посмотреть динамику изменения потребляемой оперативки прежде всего.
пробил колесо на машине, при попытке ехать с пробитым колесом машину тянет в сторону...Решение: купить новую машину...
Не эквивалентное сравнение, уместнее было бы сравнивать с дорогой по которой ездите.
Думается Ваша Ламборджина от Сургута до Норильска долго будет ехать.А колесо, это например используемая софтина.
Тем кто тут умничал - В САД!
У парня производство а не ваши домашние суперкластеры ... У него под управлением большая пром система, ему в игры "отправь баг главному пингвину и посмотри как он станет красиво прыгать и ругаЦЦЦО" играть некогда. В такой ситуации нужно искать выход, ЗДЕСЬ И СЕЙЧАС! И он не струсил - не вернул всё в виндовс (где всё работало) - а пофиксил ситуацию.Но вам, супер админам супер домашних супер кластеров этого не понять, с ваших высот такую "бытовуху" не видно :))
>Тем кто тут умничал - В САД!
>У парня производство а не ваши домашние суперкластеры ... У него под
>управлением большая пром система, ему в игры "отправь баг главному пингвину
>и посмотри как он станет красиво прыгать и ругаЦЦЦО" играть некогда.
>В такой ситуации нужно искать выход, ЗДЕСЬ И СЕЙЧАС! И он
>не струсил - не вернул всё в виндовс (где всё работало)
>- а пофиксил ситуацию.
>
>Но вам, супер админам супер домашних супер кластеров этого не понять, с
>ваших высот такую "бытовуху" не видно :))Не надо обобщать...
Я к примеру, не имею такой роскоши как "не вернуть всё в виндовс (где всё работает)"
И посему, на всё что больше 1Тб ставим XFS...
А почему, - да потому что, мы тиоретеги дох..я читаем документации,
и в пендюрить ext4 на 14 Тб массив у нас мозга не хватит.
причём сразу, а не после того как проблема появилась.
да ещё и на lvm, ij, снепшоты были - http://en.wikipedia.org/wiki/XFS#Snapshots
зы:
а "впендюрить ext4" - а она с каком-либо дистром с поддержкой (rhel, sles,..) уже идёт?
rhel, sles - неа, а вот Убунта идет.
lts?
врядли
>rhel, sles - неа, а вот Убунта идет.Она там пока идет как не-дефолтная ФС. В таком виде она и остальных есть - ядро у всех кроме наиболее махровых некрофилов уже давно умеет с ней работать. А юзеж неумолчательных настроек... позволю себе боянную цитату про рис.1 :)
---------
Мы установили немало умолчаний. Они нам нравятся. Если бы это было не так, мы бы сделали умолчаниями что-нибудь другое. Так что уберите свои грязные руки от наших умолчаний. Не трогайте их. Считайте их предопределенными. "Предопределенные умолчания" - звучит неплохо! Если вы их измените и ваша система зависнет, заткнитесь. См. pис. 1.
---------
как-бы приходится работать с протоколированием работы буровых островов (развернутого типа). как этот (не распальцовки ради ;) :
http://images.pennnet.com/articles/os/thm/th_0805offbure2.jpg
протоколирование - только небольшая часть задачи. так что если софтина с самого начала продумана, то подобные проблемы возникают не в таких пропорциях и не там.
exFat поддерживает до 2х ексабайт - разделы -:)))))
кажется так они хвастались. Правда как он посмотрит на 7ТБ файл мне действительно
интересноАвтору - незачёт. Тема не разкрыта.
В коментах вижу более интересные решения.
Зающие товарищи, подпишите пожалуйста, кто из них работает?XFS -это кончено хорошо, и мне нравится. Но формтить ради операции удаления... Вы простите.
>Автору - незачёт. Тема не разкрыта.как раз раскрыта, решение найдено. В коментах другого проверенного нет.
Ни куя не раскрытоhttp://i007.radikal.ru/0909/30/86b5c9a798b6.png
80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb свободной оператифки.7терабаб должны за ~300 сек. удалится, думается будет быстрее.
Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....
>80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb
>свободной оператифки.
>
>7терабаб должны за ~300 сек. удалится, думается будет быстрее.
>
>Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....7 терабайт фигурирует в сообщении, а не 7 гигабайт и не 70 гигабайт, это совершенно разные вещи и из удаления 80-гигабайтного файла никаких выводов сделать нельзя.
Да ну?! Доказательства в студию?Скорость винта? Щаз. При 5400 это примерно
# dd if=/dev/urandom of=/TEST count=10 bs=10000k
10+0 записей считано
10+0 записей написано
скопировано 102400000 байт (102 MB), 16,8704 c, 6,1 MB/c6 mb/s - это 80 Гб за 13400 сек.(~4 часа).
-------
Не уж-то все 80 Гб в ОЗУ влезли и оттуда удалились???
3 Гига, и пипец...
Да, 80Гб не 7 Тб, но оба размера гораздо больше всевозможных кэшей, аптимизилок, LARGEFILE64, PAE, итп...Так что я убежден что оно пойдет линейно, а именно за 300 сек. исчезнет, 7Тб.
>Да ну?! Доказательства в студию?Человек привёл доказательство в первом же посте. Можно ему верить, можно не верить, но аргументировать своё недоверие некорректно проведённым тестом нельзя.
Как аргумент в защиту ТС: http://inf.by/linux/?tgid=4204
>>Да ну?! Доказательства в студию?
>
>Человек привёл доказательство в первом же посте. Можно ему верить, можно не веритьЯ ему верю, в том что них..я не работает, но не в том, что виновата ext4
Он это вывел методом исключения, учёл почти всё кроме самодельной сборки ядра 2.6.30.5,
на сколько мне известно, ни в одном дистрибутиве его ещё нет!
да можно даже создать табличку зависимостей скорости удаления от размера файла. ;) ежели человек не верит. только в реале еще может быть куча трансакций к этому винчестеру, отчего io wait может прыгнуть вверх.
>Да ну?! Доказательства в студию?
>
>Скорость винта? Щаз. При 5400 это примерно
>
># dd if=/dev/urandom of=/TEST count=10 bs=10000k
>10+0 записей считано
>10+0 записей написано
> скопировано 102400000 байт (102 MB), 16,8704 c, 6,1 MB/c
>
>6 mb/s - это 80 Гб за 13400 сек.(~4 часа).50МБ/сек на ноутбучном Western Digital серии Scorpio Blue (WD3200BEVT, 320 ГБ; SATA 3 Гб/с; Кэш 8 МБ; 5400 об/мин):
% dd if=/dev/zero of=/dev/ad10p3 bs=100m
dd: /dev/ad10p3: short write on character device
dd: /dev/ad10p3: end of device
3032+0 records in
3031+1 records out
317921280000 bytes transferred in 5836.782166 secs (54468587 bytes/sec)
1. Как минимум, странно мерить скорость винта, читая из медленного /dev/urandom. Читайте из /dev/zero.
2. Не надо мерить скорость винта, записывая файлик 100MB размером. Либо выключите write-cache, либо пишите в несколько раз больше, чем есть оперативки.
3. Нет линейной зависимости между размером файла и скоростью его удаления. И размер файла — далеко не единственный фактор, влияющий на это. В особенности при удалении с раздела, находящегося на программном рейде.
>exFat поддерживает до 2х ексабайт - разделы -:)))))
>кажется так они хвастались. Правда как он посмотрит на 7ТБ файл
>мне действительно
>интересно
>
>Автору - незачёт. Тема не разкрыта.
>В коментах вижу более интересные решения.
>Зающие товарищи, подпишите пожалуйста, кто из них работает?Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов HDD.
>[оверквотинг удален]
>>мне действительно
>>интересно
>> Автору - незачёт. Тема не разкрыта.
>> В коментах вижу более интересные решения.
>> Зающие товарищи, подпишите пожалуйста, кто из них работает?
> Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких
> дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов
> HDD.Купи, потесть, и расскажи другим.
лоол! И как это добавили? И сколько времени это стирается на XFS? Минута? Секунда?
В блоге написали:
"Народ, попробовав xfs все поехало как надо, стирание не более 1 минуты занимает."
Капец. Это называется форум администраторов. У человека возникла проблема с удалением файла, а ему говорят, что нефиг создавать такие большие файлы (писать на русском языке, использовать БД и т.д.).Типа его кто-то спрашивает о том, какого размера файлы надо создавать. Его задача - решать конкретные производственные задачи (в данном случае упаковывать логи и записывать на носитель), все остальное - вне уровня его компетенции. Такое ощущение, что в крупных организациях никто не работал.
1. это не только форум админов2. решение проблемы подразумевает также объяснение причин. решения типа "если программа не работает, переустановите виндовс" можно считать решениями? если начальство после этого отстанет - может даже и прокатит. а если сложные ситуации возникают систематически и начальству нужно объяснение причины?
3. птушные знания порождают птушные решения, уж извините.
4. выше было приведено несколько способов диагностики и установления причин. ссылки на возможные причины тоже были приведены, но опять же: прочитанное в сетке совсем не означает действительное на конкретной системе, потому что от многих факторов зависит.
5. ситуация с файлами описана очень неконкретно, обычно идет разбор полетов после более деталированного описания. методом тыка нашли решение?
6. если у автора после найденного решения пропала головная боль, то это может и хорошо для него, только другим подобные решения не могут подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу некоторых причин, поменять.
7. тут уж не к автору, но тем не менее: за подобные софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по рукам - за решения на яве. налабали шустро пионэры чего-то там за пару дней и как-бы на данный момент это всех устраивает. а через неделю?
>2. решение проблемы подразумевает также объяснение причин. решения типа "если программа не
>работает, переустановите виндовс" можно считать решениями? если начальство после этого отстанет
>- может даже и прокатит. а если сложные ситуации возникают систематически
>и начальству нужно объяснение причины?Объяснения были даны: ext и reiser из рук вон плохо работают с большими файлами. Большего для решения задачи поставленной автором и не нужно.
>3. птушные знания порождают птушные решения, уж извините.
Афтар тот может быть кандидатом наук или доктором, между прочем, и заниматься он совсем не программингом и админством, а совсем другими делами, коих дофига на подобных объектах. Ему не нужно лезть в нюансы линукса, он решил свою задачу. То что вас отчислили из ПТУ это ваши личные половые проблемы. Да и так никто и не дождался, в чем проблема с грамотностью у автора??? Покажите пожалуста.
>5. ситуация с файлами описана очень неконкретно, обычно идет разбор полетов после
>более деталированного описания. методом тыка нашли решение?Еще раз внимательно читайте тот топик в ЖЖ, там ясно сказали, reiser и ext плохо работают с большими файлами, или грамотность не позволяет читать?
>6. если у автора после найденного решения пропала головная боль, то это
>может и хорошо для него, только другим подобные решения не могут
>подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу
>некоторых причин, поменять.У кого нет возможности поменять, тот пускай разбирается, у автора того топика была простейшая задача положить ВРЕМЕННО файл, завернуть в архив и удалить.
>7. тут уж не к автору, но тем не менее: за подобные
>софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по
>рукам - за решения на яве. налабали шустро пионэры чего-то там
>за пару дней и как-бы на данный момент это всех устраивает.
>а через неделю?Это да, по Российски, наверняка еще и бабла стоит немерянно. Откат рулит.
>7. тут уж не к автору, но тем не менее: за подобные
>софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по
>рукам - за решения на яве. налабали шустро пионэры чего-то там
>за пару дней и как-бы на данный момент это всех устраивает.
>а через неделю?пионеры... налабали... Вам хоть раз доверяли делать софт такого уровня?
И заметьте, у человека был-таки припасён дисковый массив на 7 терабайт, наверно не случайно. Хорошо что всё работает - и именно это является критерием качества, а не эстетика.
>пионеры... налабали... Вам хоть раз доверяли делать софт такого уровня?
>И заметьте, у человека был-таки припасён дисковый массив на 7 терабайт, наверно
>не случайно.угу, он же там прямо пишет, что и раньше 7Тб не редкость было, просто набиралось за больший срок.
Хорошо что всё работает - и именно это является
>критерием качества, а не эстетика.И я к этому тоже веду.
то есть ты сейчас начинаешь рассуждать о материях, в которых даже не разбираешься (это про софт такого уровня)?
люди на запорожцах тоже катаются. они же передвигаются, задача решена. значит это - критерий качества. не так ли?а софт подобного уровня приходится писать, да и софт для тестирования нагрузочных способностей программ, даже ошибки в драйверах приходится отлавливать. т.к. система с этим софтом должна справляться с нагрузками и выполнять свою задачу годами. в среднем - от 5 до 10 лет. а что?
> 6. если у автора после найденного решения пропала головная боль, то это может и хорошо для него, только другим подобные решения не могут подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу некоторых причин, поменять.Странно, файловую систему менять нельзя, а программный комплекс переписывать значится можно. Оригинальная логика. Я бы из двух этих вариантов однозначно выбрал смену ФС, т.к. это наиболее простая и легко осуществимая операция.
вы путаете божий дар с яичницей. нарочно? скорее всего - да. ибо вам выгораживать свою глупость, наверное, не привыкать...
писалось о том, что? на сколько я понял, поясняю: далеко не во всех случаях можно просто так поменять файловую систему. а если рухнет однажды серверок и на альтернативной файловой системе вообще ничего восстановить не сможешь? тогда кто по башке получит? подобные шуточки у нас на работе были, оттого и нельзя было в свое время reiserfs3 устанавливать. это чисто наш рабочий пример, в тестирование у нас входит тест на поднятие системы после сбоя системы питания, если электроника не сгорела, то система должна быть запушена без потери работоспособности.софт часто проще переписать, тем более, когда речь идет о простом логгинге инфы. хотя, если люди любят преодолевать трудности, записывая инфу террабайтами...
угу. и начинать тестирование с 0 ибо потом окажется что запись в log вызвала свиг по времени выполнения и вылез какой нить race conditionals который и раньше был - но был менее вероятным.
Ну есть еще ошибки в коде самого логера - который может уронить систему.. в прочем чего объяснять - вы же и так знаете ?:)
да, знаю. не по наслышке. мне вот предстоит переписать симулятор, который заменяет оборудование. причем, переписывать с нуля, за исключением мелочей. потому как старый не расчитан на большие нагрузочные способности (на яве написан). пишется, тестируется программерами. потом тестируется пользователеми. код вылизыватся и все.
просто наступил момент, когда со старым софтом ну вообще никак. и у вас такой момент наступит, рано или поздно. ;)
извиняюсь, не ко мне было адресовано...
>софт часто проще переписать, тем более, когда речь идет о простом логгинге
>инфы. хотя, если люди любят преодолевать трудности, записывая инфу террабайтами...Проще, только самое сложное - найти идиота, который подпишется под приказом переписать работающий софт такого назначения. Потом более простой этап - найти идиота, который согласится сменить испытанный софт на новодел. Ну а потом, после первого же ЧП, проблем вообще не будет.
для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим, плюс запас на будущее. вы про такое не слышали? есть даже книжки по этой тематике.
>для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим,
>плюс запас на будущее. вы про такое не слышали? есть даже
>книжки по этой тематике.Как-то я читал воспоминания одного научного сотрудника. Он работал в институте, занимающемся усовершенствованием атомных электростанций. По его словам, все их предложения принимались, высоко оценивались, но никогда не внедрялись. Потому что есть старый инженерный принцип - "работает - не трогай". Подтверждений ему - море.
>для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим,
>плюс запас на будущее. вы про такое не слышали? есть даже
>книжки по этой тематике.Я представляю начальника, к которому приходит администратор с предложением остановить завод на месяц для тестирования новой системы логов. Или тот же начальник, слушающий сообщение админа, что из-за недостатка места в дисковом массиве придётся запустить тестирование системы и на это надо миллион баксов и пол-года человекочасов...
эти предложения должны обосновано делать программисты-инженеры, с расчетом затрат и последущей экономии. а вы, как администратор, должны молча выполнять то, что скажет начальство.
>>для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим,
>>плюс запас на будущее. вы про такое не слышали? есть даже
>>книжки по этой тематике.
>
>Я представляю начальника, к которому приходит администратор с предложением остановить завод на
>месяц для тестирования новой системы логов. Или тот же начальник, слушающий
>сообщение админа, что из-за недостатка места в дисковом массиве придётся запустить
>тестирование системы и на это надо миллион баксов и пол-года человекочасов...Тестовая конфигурация не так уж дорого стоит:
8 винчестеров по 1ТБ ~ 5000 руб.* 8 = 40000 руб.
Блок питания 1000Вт ~ 7000 руб.
RAID-контроллер SAS/SATA 8 кан. Intel "SRCSASBB8I" 256МБ RAID 0/1/5/6/10/50/60 (PCI-E x8) ~ 18000 руб.
ОС FreeBSD 8.0-BETA3 с ZFSv13 ~ по цене за трафик.
Системник PC, в который не стыдно всё это засунуть ~ 10000 руб.
Итого: ~ 75000 руб.
-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.
точно также может обстоять дело с человекочасами... и может оказаться, чтобы симулировать поведение оборудования, достаточно написать небольшой скриптик... :)
>точно также может обстоять дело с человекочасами... и может оказаться, чтобы симулировать
>поведение оборудования, достаточно написать небольшой скриптик... :)А когда реальное оборудование откажется эмулировать поведение скриптика...
вы просто даже не в курсе... не больно стоять на своем?
>вы просто даже не в курсе... не больно стоять на своем?Как-то я читал про отличие ученика из школы для отсталых от ученика обычной школы. Задают им задачу:
- шёл мальчик по улице, нашёл две конфеты. Потом нашёл ещё три конфеты. Сколько конфет нашёл мальчик?Обычный школьник скажет "Пять", ну может ошибётся скажет "Четыре". Отсталый же школьник может начать изучать вопрос куда шёл мальчик, откуда, кто потерял конфеты, какие конфеты, нельзя ли пойти на улицу посмотреть нет ли там конфет...
Так вот, вспомнил я эту особенность некоторых... Тема про то что ext4 не справилась с большим файлом, а не про то что логи неправильно формируются и надо написать новую программу, отладить...
нет, вы элементарно не смогли объяснить причину так называемого косяка ext4. кроме постранных ссылок на ошибку в кернеле.историю с учеником сами придумали? может вам надо было писателем пойти? талантище пропадает!
>нет, вы элементарно не смогли объяснить причину так называемого косяка ext4. кроме
>постранных ссылок на ошибку в кернеле.А у вас есть мнение относительно такого поведения ext4 на большом файле? Озвучте его нам, мы слушаем!
(ЗЫ. Самый большой файл который я видел был 39Гб аля образ Blu-Ray диска), стирался он на ext около 20 сек.
во-первых, я такие дурацкие трудности не преодолевал, даже когда работал в отделе обработки сейсмоданных. данные с ленты автоматом разбивались на файлы вменяемых размеров. ими проще управлять, с ними проще работать, их проще индекировать и почее. это террабайты данных чисел с плавающей точкой, если это вам о чем-то говорит. в чем я очень сомневаюсь.во-вторых, я уже писал, каким бы образом я диагностировал данную ситуацию. или я должен повторить несколько раз, чтобы до вас дошло? или до вас не доходит, что на другой системе с ext4 такой проблемы может и не быть? например, криво собрали ядро, экспериментируя, накликавши всяких опций. или установив экспериментальное ядро. или рейд-массив прикручен с некорректными параметрами. или с девайсом общается еще куча программ (а может и одна, но очень кривая), которые соответственно влияют на все операции с диском. или...
судя по описанию самого большого файла, который вы видели, я пришел к выводу, что вы даже не в состоянии создать большой файл для диагностики файловой системы. так вот, у меня файл 35 Гб удалился за 2.5 секунды. уж извините, не образы блю-рей дисков, а просто файлик, созданный
dd if=/dev/zero of=image.udf bs=1000k count=35000
и это на
hdparm -tT /dev/sda
на винчестере с 8 мб кэша и 5200 оборотами в минуту.
/dev/sda:
Timing cached reads: 2102 MB in 2.00 seconds = 1051.46 MB/sec
Timing buffered disk reads: 188 MB in 3.02 seconds = 62.24 MB/secтак что можете троллить дальше, флаг вам в руки и барабан на шею.
опечатка: 5400 оборотов в минуту
>Итого: ~ 75000 руб.
>-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.Гениально...
>>Итого: ~ 75000 руб.
>>-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.
>
>Гениально...Вот тачка: http://www.3dnews.ru/news/kak_sozdat_petabaitnii_klaster_za_...
"Рассмотрев коммерческие решения, компания посчитала, что выгоднее будет разработать кластер собственными силами. В итоге, каждый 67-Тб сервер форм-фактора 4U обошёлся в $7867. Петабайт - $117 тыс."
>Тестовая конфигурация не так уж дорого стоит:
>8 винчестеров по 1ТБ ~ 5000 руб.* 8 = 40000 руб.+ 2 диска для системы
>Блок питания 1000Вт ~ 7000 руб.
>RAID-контроллер SAS/SATA 8 кан. Intel "SRCSASBB8I" 256МБ RAID 0/1/5/6/10/50/60 (PCI-E x8)
>18000 руб.У автора того топика большой раид был сделан софтово полностью.
>ОС FreeBSD 8.0-BETA3 с ZFSv13 ~ по цене за трафик.
Linux там был, на BSD в том топике не вспомнил никто.
>-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.
2U приличные гораздо дороже стоят. Примерно от 100 тыр.
>>ОС FreeBSD 8.0-BETA3 с ZFSv13 ~ по цене за трафик.
>Linux там был, на BSD в том топике не вспомнил никто.Я высказался про альтернативу. Ведь Linux не может предложить ничего более вменяемого, кроме XFS.
>2U приличные гораздо дороже стоят. Примерно от 100 тыр.
2U: IBM System x3650 (Xeon E5504, до 128ГБ RAM, ServeRAID-BR10i, до 12 HDD 2.5" SAS/SATA/SSD) ~ цена от 70 т.р.
PC: IBM System x3400 (Xeon E5504, до 96ГБ RAM, ServeRAID-BR10i, до 8 HDD 2.5" SAS) ~ цена от 55 т.р.
>>>ОС FreeBSD 8.0-BETA3 с ZFSv13 ~ по цене за трафик.
>>Linux там был, на BSD в том топике не вспомнил никто.
>
>Я высказался про альтернативу. Ведь Linux не может предложить ничего более вменяемого,
>кроме XFS.
>
>>2U приличные гораздо дороже стоят. Примерно от 100 тыр.
>
>2U: IBM System x3650 (Xeon E5504, до 128ГБ RAM, ServeRAID-BR10i, до 12
>HDD 2.5" SAS/SATA/SSD) ~ цена от 70 т.р.Вы туда набейте винтов, и поглядите сколько будет стоить.
>[оверквотинг удален]
>>
>>Я высказался про альтернативу. Ведь Linux не может предложить ничего более вменяемого,
>>кроме XFS.
>>
>>>2U приличные гораздо дороже стоят. Примерно от 100 тыр.
>>
>>2U: IBM System x3650 (Xeon E5504, до 128ГБ RAM, ServeRAID-BR10i, до 12
>>HDD 2.5" SAS/SATA/SSD) ~ цена от 70 т.р.
>
>Вы туда набейте винтов, и поглядите сколько будет стоить.А мне не нужно ТУДА набивать винтов. Я предложил АЛЬТЕРНАТИВНУЮ тачку (PC), сравнимую по ценам с ЭТИМИ, уже набитую.
Эм, а ничего что ext3 файлы на 7 ТБ не поддерживает?
>Эм, а ничего что ext3 файлы на 7 ТБ не поддерживает?
>А ничего что ext4 ?
>>Эм, а ничего что ext3 файлы на 7 ТБ не поддерживает?
>>
>
>А ничего что ext4 ?тут недавно в ext4 всплывали проблемы с девайсами объемом больше 8Т - где-то упирались в переполнение - так что смена ext4 на что-то другое, пока что оправдана.
Проблемы с soft-lookup упоминаемые выше - собственно - это тажа проблема что в начале топика - длительные операции (больше 10с) без вызова schedule() на что сразу начинает ругаться тупой soft-lookup detector.
Из той же оперы вариант уложиться линух - на 16-32 core system - вызывать sysrq-t на сколько нибудь загруженой машинке (~1k процессов) имея подключеный serial console на 9600,8n1 - (предвидя коментарии скажу что смена на 115200,8n1 - проблемы нефига не решает) - баста - машинка умирает :-) постоянно пытается что-то записать в serial и на другое времени не остается - все забито soft-lookup.
>[оверквотинг удален]
>другое, пока что оправдана.
>Проблемы с soft-lookup упоминаемые выше - собственно - это тажа проблема что
>в начале топика - длительные операции (больше 10с) без вызова schedule()
>на что сразу начинает ругаться тупой soft-lookup detector.
>Из той же оперы вариант уложиться линух - на 16-32 core system
>- вызывать sysrq-t на сколько нибудь загруженой машинке (~1k процессов)
>имея подключеный serial console на 9600,8n1 - (предвидя коментарии скажу что
>смена на 115200,8n1 - проблемы нефига не решает) - баста
>- машинка умирает :-) постоянно пытается что-то записать в serial и
>на другое времени не остается - все забито soft-lookup.в догонку. посмотрев репорты в убунте (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/340628 и прочие)
все это очень сильно напоминает на тот баг в jbd2 что фиксили недавно у себя.
"Добрый" Alan Cox - добавил оптимизацию - что бы уменьшить нагрузку и количество wakeup в системе - в результате чего - время wakeup на таймере транзакции оказывается в "прошлом" - и следующий start transaction дуплил пытаясь дождаться когда же закончится предыдущее.
исправление примерно вот такое
--- linux-2.6.27.21-0.1.orig/fs/jbd2/transaction.c 2009-06-10 11:11:41.000000000 -0600
+++ linux-2.6.27.21-0.1/fs/jbd2/transaction.c 2009-06-10 11:12:32.000000000 -0600
@@ -54,7 +54,7 @@
INIT_LIST_HEAD(&transaction->t_inode_list);
/* Set up the commit timer for the new transaction. */
- journal->j_commit_timer.expires = round_jiffies(transaction->t_expires);
+ journal->j_commit_timer.expires = transaction->t_expires;
add_timer(&journal->j_commit_timer);
J_ASSERT(journal->j_running_transaction == NULL);
а вот например 2>/BIGFILE тоже не сработало бы ?
имелось ввиду :> FILE?
>Решение: проблема исчезает при использовании файловой системы XFS.А с именованными пайпами поиграться не пробовали?
Типа, создать пайпу с таким же именем, как и этот огроменный файл. С другой стороны к пайпе присоединяется некий демон (на си, перле, питоне, ...), который "нарезает" поток данных из пайпы на порции: архивирует, копирует на ленту и т.д.
хм, а у меня недавно XFS на руках умерла...
Всего-то было около 450 Гб. Благо ничего серьезного не содержала, лишь видеонаблюдение за неделю.
Монтируется, а в каталог зайти не дает.. xfs_check молотит минут 15, потом выходит без объяснений.
Что делать? Перешел на reiserfs..
reiserfs тоже не без огрешек. но если вывал будет, всю партицию сложно будет восстановить, если вообще возможно.
в свое время лет 6 назад, читал про файловые системы чтоб под базу выбрать, тоже остановился на xfs и не пожалел,
хоть старовата но рулит до сих пор, не разу не падвела тьфу-тьфукстати на ext4 не пробовали удалять так
"nice -n 19 rm -f bigfile &"
мне помогало продолжить работу, а фоном заканчивалась операция удаления
