forum.opennet.ru - "Раздел полезных советов: Решение проблем с удалением файлов ..." (105)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Раздел полезных советов: Решение проблем с удалением файлов ..."

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Решение проблем с удалением файлов ..."		+/–
Сообщение от auto_tips (??) on 01-Сен-09, 13:54
Попытка удаления файла, имеющего размер порядка 7 Тб, приводит к зависанию Linux сервера с ФС ext4 или reiser на несколько часов. Решение: проблема исчезает при использовании файловой системы XFS. URL: http://community.livejournal.com/ru_linux/2289534.html Обсуждается: http://www.opennet.dev/tips/info/2154.shtml
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Решение проблем с удалением файлов гигантского размера в Lin..., anonymous, 13:54 , 01-Сен-09, (1)

Решение проблем с удалением файлов гигантского размера в Lin..., User294, 22:37 , 03-Сен-09, (76)

Решение проблем с удалением файлов гигантского размера в Lin..., abigor, 14:35 , 01-Сен-09, (2)

Решение проблем с удалением файлов гигантского размера в Lin..., svn, 14:53 , 01-Сен-09, (4)

Решение проблем с удалением файлов гигантского размера в Lin..., cvsup, 15:25 , 01-Сен-09, (7)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 16:40 , 01-Сен-09, (15)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 01:03 , 02-Сен-09, (28)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 01:44 , 02-Сен-09, (33)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 01:57 , 02-Сен-09, (34)
Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 01:57 , 02-Сен-09, (35)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 02:05 , 02-Сен-09, (36)
Решение проблем с удалением файлов гигантского размера в Lin..., Админ Веня, 09:23 , 02-Сен-09, (39)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 12:53 , 02-Сен-09, (44)

Решение проблем с удалением файлов гигантского размера в Lin..., Админ Веня, 23:09 , 05-Сен-09, (104)

Решение проблем с удалением файлов гигантского размера в Lin..., aborland, 23:52 , 05-Сен-09, (106)

Решение проблем с удалением файлов гигантского размера в Lin..., Админ Веня, 12:57 , 06-Сен-09, (107)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 02:17 , 02-Сен-09, (37)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 02:22 , 02-Сен-09, (38)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 10:08 , 02-Сен-09, (42)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 02:48 , 03-Сен-09, (67)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 17:35 , 03-Сен-09, (74)

Решение проблем с удалением файлов гигантского размера в Lin..., Iv945n, 18:25 , 02-Сен-09, (52)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 20:41 , 02-Сен-09, (54)

Решение проблем с удалением файлов гигантского размера в Lin..., Iv945n, 21:11 , 02-Сен-09, (56)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 05:05 , 04-Сен-09, (94)

Решение проблем с удалением файлов гигантского размера в Lin..., нер, 15:48 , 05-Сен-09, (102)

Решение проблем с удалением файлов гигантского размера в Lin..., lora, 12:02 , 02-Сен-09, (43)

Решение проблем с удалением файлов гигантского размера в Lin..., timon, 14:49 , 01-Сен-09, (3)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 15:55 , 01-Сен-09, (10)

Решение проблем с удалением файлов гигантского размера в Lin..., Timon, 23:34 , 02-Сен-09, (61)

Решение проблем с удалением файлов гигантского размера в Lin..., Serg, 14:53 , 01-Сен-09, (5)

Решение проблем с удалением файлов гигантского размера в Lin..., Анонумоис, 16:07 , 01-Сен-09, (12)

Решение проблем с удалением файлов гигантского размера в Lin..., Zenitur, 00:19 , 02-Сен-09, (27)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 20:52 , 01-Сен-09, (22)

Решение проблем с удалением файлов гигантского размера в Lin..., terminus, 15:39 , 01-Сен-09, (9)

Решение проблем с удалением файлов гигантского размера в Lin..., mmm62, 11:14 , 09-Сен-09, (113)

Решение проблем с удалением файлов гигантского размера в Lin..., makiavelli, 15:59 , 01-Сен-09, (11)
Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 16:20 , 01-Сен-09, (13)

Решение проблем с удалением файлов гигантского размера в Lin..., User294, 22:40 , 03-Сен-09, (77)

Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 23:46 , 03-Сен-09, (83)

Решение проблем с удалением файлов гигантского размера в Lin..., MoHaX, 17:12 , 01-Сен-09, (16) +1

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 17:27 , 01-Сен-09, (17)

Решение проблем с удалением файлов гигантского размера в Lin..., Warhead Wardick, 18:33 , 01-Сен-09, (19) +1

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 19:45 , 01-Сен-09, (20)

Решение проблем с удалением файлов гигантского размера в Lin..., vitek, 14:04 , 02-Сен-09, (45)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 16:59 , 02-Сен-09, (48)

Решение проблем с удалением файлов гигантского размера в Lin..., vitek, 01:05 , 03-Сен-09, (66)
Решение проблем с удалением файлов гигантского размера в Lin..., User294, 22:44 , 03-Сен-09, (78)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 01:15 , 02-Сен-09, (29)

Решение проблем с удалением файлов гигантского размера в Lin..., Filosof, 20:01 , 01-Сен-09, (21)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 20:54 , 01-Сен-09, (23)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 23:50 , 01-Сен-09, (24)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 00:18 , 02-Сен-09, (26)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 01:28 , 02-Сен-09, (30)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 01:32 , 02-Сен-09, (31)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 17:05 , 02-Сен-09, (49)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 01:37 , 02-Сен-09, (32)
Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 09:34 , 02-Сен-09, (41)
Решение проблем с удалением файлов гигантского размера в Lin..., John Lepikhin, 08:23 , 03-Сен-09, (69)

Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 09:28 , 02-Сен-09, (40)

Решение проблем с удалением файлов гигантского размера в Lin..., pavlinux, 17:17 , 02-Сен-09, (50)

Решение проблем с удалением файлов гигантского размера в Lin..., Zenitur, 00:18 , 02-Сен-09, (25)

Решение проблем с удалением файлов гигантского размера в Lin..., Aleksey, 16:57 , 02-Сен-09, (47)

Решение проблем с удалением файлов гигантского размера в Lin..., Aleksey, 15:58 , 02-Сен-09, (46)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 20:57 , 02-Сен-09, (55)

Решение проблем с удалением файлов гигантского размера в Lin..., lora, 22:17 , 02-Сен-09, (58)
Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 23:47 , 02-Сен-09, (63)

Решение проблем с удалением файлов гигантского размера в Lin..., lora, 23:50 , 02-Сен-09, (64)
Решение проблем с удалением файлов гигантского размера в Lin..., Developer, 14:24 , 03-Сен-09, (72)
Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 23:38 , 03-Сен-09, (80)

Решение проблем с удалением файлов гигантского размера в Lin..., Aleksey, 00:33 , 03-Сен-09, (65)

Решение проблем с удалением файлов гигантского размера в Lin..., Developer, 17:28 , 03-Сен-09, (73)

Решение проблем с удалением файлов гигантского размера в Lin..., _umka_, 18:19 , 03-Сен-09, (75)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 23:56 , 03-Сен-09, (85)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 00:22 , 04-Сен-09, (88)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 22:59 , 03-Сен-09, (79)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 23:43 , 03-Сен-09, (81) –1

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 23:46 , 03-Сен-09, (82)
Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 23:50 , 03-Сен-09, (84)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 00:04 , 04-Сен-09, (86)
Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 00:16 , 04-Сен-09, (87)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 00:37 , 04-Сен-09, (89)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 01:01 , 04-Сен-09, (90)

Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 01:22 , 04-Сен-09, (92)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 02:39 , 04-Сен-09, (93)
Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 09:48 , 04-Сен-09, (95)
Решение проблем с удалением файлов гигантского размера в Lin..., lora, 12:55 , 04-Сен-09, (98)
Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 23:43 , 06-Сен-09, (110)
Решение проблем с удалением файлов гигантского размера в Lin..., Karbofos, 23:48 , 06-Сен-09, (111)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 01:02 , 04-Сен-09, (91)

Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 21:20 , 15-Сен-09, (115)

Решение проблем с удалением файлов гигантского размера в Lin..., lora, 12:52 , 04-Сен-09, (97)

Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 23:34 , 05-Сен-09, (105)

Решение проблем с удалением файлов гигантского размера в Lin..., lora, 13:15 , 06-Сен-09, (108)

Решение проблем с удалением файлов гигантского размера в Lin..., iZEN, 20:41 , 06-Сен-09, (109)

Решение проблем с удалением файлов гигантского размера в Lin..., Аноним, 18:24 , 02-Сен-09, (51)

Решение проблем с удалением файлов гигантского размера в Lin..., Pilat, 18:27 , 02-Сен-09, (53)

Решение проблем с удалением файлов гигантского размера в Lin..., _umka_, 09:26 , 03-Сен-09, (70)

Решение проблем с удалением файлов гигантского размера в Lin..., _umka_, 09:40 , 03-Сен-09, (71)

Решение проблем с удалением файлов гигантского размера в Lin, i, 22:09 , 02-Сен-09, (57)

Решение проблем с удалением файлов гигантского размера в Lin, vvs, 16:34 , 05-Сен-09, (103)

Раздел полезных советов: Решение проблем с удалением файлов ..., Slavaz, 19:02 , 04-Сен-09, (101)
Раздел полезных советов: Решение проблем с удалением файлов ..., eplumber, 16:43 , 08-Сен-09, (112)

Раздел полезных советов: Решение проблем с удалением файлов ..., Karbofos, 23:25 , 12-Сен-09, (114)

Решение проблем с удалением файлов гигантского размера в Lin..., Игорь, 17:08 , 22-Сен-09, (116)

Сообщения по теме [Сортировка по времени | RSS]

1. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от anonymous (??) on 01-Сен-09, 13:54

Все гениальное просто

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

76. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от User294 (ok) on 03-Сен-09, 22:37

>Все гениальное просто
Тем не менее, удаление файла ~30 секунд XFSом я видел :P. Всего-то 4Gb торент сдуру слитый без преаллокации. Представляю себе что будет если такой же вермишелью записать 7Tb...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от abigor on 01-Сен-09, 14:35

Понимаю, что это флуд. Но что может занимать столько места одним файлом? Делаю предположение, что это может быть видео?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от svn (??) on 01-Сен-09, 14:53

база данных например

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от cvsup (ok) on 01-Сен-09, 15:25

На 7ТБ? база данных чего?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 01-Сен-09, 16:40

>На 7ТБ? база данных чего?
http://community.livejournal.com/ru_linux/2289534.html
> PS. Предвосхищая вопросы. Железка это многоузловой промконтроллер, управляющих огромным
> (450 тыс. тонн) газохранилищем. В связи с событиями на СШ ГЭС, начальством было
> приказано debuglevel увеличить на 2 пункта (условно с 1 до 4 при максимальном 6).
> Если раньше 7Тб эти набегали в лучшем случае за 50-60 суток, то сейчас эти 7 Тб
> заполняются за 18-20 часов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 01:03

фигасе, и это все дело одним файлом? в принципе, объясняет многое уровень русского языка у того коллеги. совсем плохо, если он живет в России. уровень языков программирования, надеюсь, у него выше...
оттого и бешеные проблемы преодолением трудностей, которые создали себе сами. дебаг-инфу можно создавать и в компактной форме, вплоть до битовой кодировки. а дальше уже и на лету компримировать и прочее, если мощности позволяют.
да, конечно, зависит от "запущенности" софта

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 02-Сен-09, 01:44

>объясняет многое уровень русского языка у того коллеги.
Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
Объясняет все "Конфиг Core2Quad 6600/8 Гиг ECC/i3000 Некий java софт от большой технологической железки пишет огромный файл до 7 Тб".
Выводов несколько. Софт писали недавно, оборудование закупили недавно, писали на java, но не в этом дело, еще дело в "технологической железке", которая генерирует файлы по 7ТБ за сутки.
Что бы они делали десять лет назад (в 1999), покупали бы CRAY? Там внутри явно проблемы с оптимизацией, т.к. сейчас, куда не плюнь, практически все данные передаются/хранятся в сжатом виде и сжимаются по многу десятков раз (ethernet/SDH/PCI express/DOCx/PDF/JPG/MP3/FLAC/MP4...). Только сжимаются они не в ZIP архив 7ТБ базу, а на том уровне, на котором проще всего её осмыслить. Как минимум в голову приходит PNG.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 01:57

основная проблема это "Некий java софт"? проверить, не так уж и сложно, экспериментируя с меньшими размерами файла проверять элементарно в top, что происходит. есть и другие подручные средства линукс

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 02-Сен-09, 01:57

>Как минимум в голову приходит PNG.
Это если данные от датчиков поступают в бинарном виде. Если это лог, то сжимать его еще проще, т.к. 90%(из головы взял) данных одинаковые. Ну не верю я, что датчик выдает каждую секунду разные данные + штамп времени, там меняется всего 1,2,3 бита! Идентификатор датчика не меняется вовсе. Есть преобразования Фурье, есть, да чего только нет... Было бы желание.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 02-Сен-09, 02:05

>Далее этот файл сжимается зипом до приемлимых размеров (до 200-400 Гб)
Полный звездец! Значит база легко может весить 200-400Гб сама по себе. А если применять специальные методы (выше написал, что сразу пришло в голову), реальный размер этой базы - сотни мегабайт и даже мегабайты!
На таком железе данные из LOG'а извлекутся мгновенно, а вот из 7ТБ базы в ZIP на ленте - ПОЛНЫЙ ЗВЕЗДЕЦ!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Админ Веня on 02-Сен-09, 09:23

Разрабатывали систему, меньшего масштаба, для "мобильных "электростанций. При условий что датчиков от 50 до 500, при постоянной работе двигателей, и без усреднения данных(т.е. данные пишутся примерно от 10000 в секунду), база занимала за 3 месяца около 40 гиг.
база мускул (ембедед), 2гига память. решение используется уже на нескольких десятках объектов в течении 4х лет

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 02-Сен-09, 12:53

>база мускул
MySQL - база данных специально для критически важных объектов, а вот 5 формул из 2 курса любого вуза применить - все, сломается все критическая надежность, этого же нельзя допустить!
Еще раз говорю, даже процессор без злых алгоритмов + алгоритмов самопроверки и т.д. не работает. Почему нельзя записывать показания датчиков в "сжатом" виде? Неужели у нас нет на это ГОСТов? Как записывали показания датчиков до 1998 года?
Зачем записывать в MySQL (где тоже могут быть ошибки) базу явно одни и те же цифИри? Чтобы отвязались? Мы вот мол логи пишем, если чего, это не мы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

104. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Админ Веня on 05-Сен-09, 23:09

Таки нет, цифры разные при старте двигателей и во время работы оного. не синхронные они.
следить нужно.
а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

106. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от aborland on 05-Сен-09, 23:52

>Таки нет, цифры разные при старте двигателей и во время работы оного.
>не синхронные они.
>следить нужно.
>а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?
Дык и на интербейз посмотреть можно и на sqlite
и даж свое ченить на коленке слабать

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

107. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Админ Веня on 06-Сен-09, 12:57

_СТАВИТЬ_ сервер баз данных для этого???
у нас "мускул ембедед"

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 02:17

> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
часто показывает на уровень образования. к примеру, мне тут один птушник пыталя давеча доказать, что логические и битовые операции - вещи идентичные.
но, с русским языком я могу и заблуждаться. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 02-Сен-09, 02:22

>> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
>
>часто показывает на уровень образования. к примеру, мне тут один птушник пыталя
>давеча доказать, что логические и битовые операции - вещи идентичные.
>
>но, с русским языком я могу и заблуждаться. :)
Правильное владение русским языком очень важно. Наприимер, сколько Ваших, Karbofos, сообщений в этом топике я ни прочитал - столько раз был в замешательстве: что Вы хотите сказать, какую точку зрения поддерживаете? А всего-то плохое владение языком. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

42. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 10:08

если бы я конкретно пощупал систему, на которой этот гемор происходит, где допустили ТАКОГО рода раздолбайство с протоколированием на некоем ява софте... а так, кроме общих рекомендаций по поиску причин зависонов, которых аффтар явно не знает, аки простые методы диагностирования, нечего и сказать. а если и скажу, так аффтар этого, скорее, не поймет.
так что лично Вы можете быть в замешательстве от каждой буквы, написанной мной. если уж так сильно хотите. io wait тоже вызывает недоумение?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

67. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 03-Сен-09, 02:48

Вы об каких логических операциях говорите, в формальной логике или в математической?
И можно повторить то место, в котором ПТУшнег с вами наконец согласился.



Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

74. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 03-Сен-09, 17:35

он утверждал, что
(boolTest1 ^ boolTest2) // boolTest1, boolTest2 are bool
одно и тоже с
(int32x1 ^ int32x2) // int32x1 int32x2 are integer
(опреация исключаещего или в сях)
пришлось даже программу писать, ибо в книжки он заглядывать не любит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

52. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Iv945n (ok) on 02-Сен-09, 18:25

> Как минимум в голову приходит PNG.
Чо? Газохранилище генерирует картинки (фотографии газа? :-)) ) и сохраняет их в базу (нафига? учили же что лучше в файловой системе картинки хранить).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

54. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 02-Сен-09, 20:41

Да, Karbofos оказался прав.
>учили же что лучше в файловой системе картинки хранить
А меня учили базы данных хранить в RAW разделах.
>Газохранилище генерирует картинки
В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как можно осознанно, эффективно и без потерь сжать битовую последовательность.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

56. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Iv945n (ok) on 02-Сен-09, 21:11

>>учили же что лучше в файловой системе картинки хранить
>А меня учили базы данных хранить в RAW разделах.
Оффтопик, речь о файловых системах. И что мешает завести под блобы отдельный раздел с подходящей файловой системой?
>>Газохранилище генерирует картинки
>В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от
>изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как
>можно осознанно, эффективно и без потерь сжать битовую последовательность.
Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны именно на графику и звук соответственно, иначе бы жали и графику во FLAC и музыку в PNG.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

94. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 04-Сен-09, 05:05

>Оффтопик, речь о файловых системах.
Честно говоря, я совсем не понял о чем речь в данной статье. Какие-то mysql базы невероятного размера на нестабильной версии файловой системы...
>Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны
>именно на графику и звук соответственно, иначе бы жали и графику
>во FLAC и музыку в PNG.
Может я изъясняюсь непонятно... Мне показалась странной база в 7ТБ, которую каждые пол дня пытаются удалить... Вот я и предположил, что по аналогии с музыкой и звуком можно и эту информацию как нибудь сжать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

102. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от нер on 05-Сен-09, 15:48

> Уровень русского языка ничего не объясняет
Заблуждение. Невозможно много читать и не знать языка. Плохой русский - мало читал. Какой он тогда, к жукам майским, специалист, если он за всю жизнь 3 книги прочёл? Под хвост сразу таких гнать надо с таких проектов. Понимаете?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

43. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora on 02-Сен-09, 12:02

А что не так с русским языком у автора того топика на ЖЖ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от timon on 01-Сен-09, 14:49

ха, а решить задачу на ext4 слабо?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 01-Сен-09, 15:55

# unlink /BIGFILE.sql
не?
mount -o remount,barrier=0 /dev/superraid
не?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

61. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Timon on 02-Сен-09, 23:34

дайте массив на 10ТБ, проверю :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Serg (??) on 01-Сен-09, 14:53

Однако, решение никак не коррелирует с заголовком статьи ;( Если уже есть файл, поменять ФС вряд ли удастся на лету. Лучше наябедничать разработчикам, чтобы поправили явный баг.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Анонумоис on 01-Сен-09, 16:07

А Линус кого нибудь не придушит? :D Помню, предыдущие "явные" баги в емаксах, "жёстких дисках", "сетевых картах", самбах вели в хозяйство Линуса, а он на попытки их исправить обвинял бедолагу в неадекватности, говорил про вещества :D Угрожал покинуть пост, как в мультике "либо он, либо я" :D

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Zenitur on 02-Сен-09, 00:19

Прям как злые тролли в России. Которые тоже не понимают очевидность бага и отвечают несерьёзно. "Тормозит KDE 4? У тебя просто кривые руки".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 01-Сен-09, 20:52

Это не явный и не баг, это давно известная проблема ext2-3

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от terminus (ok) on 01-Сен-09, 15:39

echo "0" > ./bigfile.db
rm ./bigfile.db
?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

113. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от mmm62 on 09-Сен-09, 11:14

>echo "0" > ./bigfile.db
>rm ./bigfile.db
>
>?
нет
time echo 1 > big0
real    0m2.705s
user    0m0.000s
sys     0m0.367s
time rm -f big0
real    0m2.370s
user    0m0.001s
sys     0m0.347s

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от makiavelli on 01-Сен-09, 15:59

А тот же експеремент с jfs как?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 01-Сен-09, 16:20

Use ZFS, Luke!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

77. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от User294 (ok) on 03-Сен-09, 22:40

>Use ZFS, Luke!
И, конечно, это панацея и всем станет хорошо? :) А вы, к слову, проверяли ее под такой нагрузкой? А то реально любопытно как оно будет выкручиваться если такой файл записать на нее в виде вермишели (мелкими порциями без преаллокации). А то версионники сами то к фрагментации склонны (дозапись логов же). Если специально подогнать клинический случай то что будет? Любопытно :). Вы хотите это любопытство удовлетворить? Камон, you're welcome.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

83. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 03-Сен-09, 23:46

>>Use ZFS, Luke!
>
>И, конечно, это панацея и всем станет хорошо? :)
"В общем, да." (c) Парацельс
>А вы, к слову, проверяли ее под такой нагрузкой?
Зачем спрашивать? Нет ещё.
>А то реально любопытно как оно будет выкручиваться если такой файл записать на нее в виде
>вермишели (мелкими порциями без преаллокации).
Вот и мне тоже. Любопытно. Хотелось бы посмотреть динамику изменения потребляемой оперативки прежде всего.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Решение проблем с удалением файлов гигантского размера в Lin..." +1 +/–

Сообщение от MoHaX (ok) on 01-Сен-09, 17:12

пробил колесо на машине, при попытке ехать с пробитым колесом машину тянет в сторону...
Решение: купить новую машину...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 01-Сен-09, 17:27

Не эквивалентное сравнение, уместнее было бы сравнивать с дорогой по которой ездите.
Думается Ваша Ламборджина от Сургута до Норильска долго будет ехать.
А колесо, это например используемая софтина.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Решение проблем с удалением файлов гигантского размера в Lin..." +1 +/–

Сообщение от Warhead Wardick on 01-Сен-09, 18:33

Тем кто тут умничал - В САД!
У парня производство а не ваши домашние суперкластеры ... У него под управлением большая пром система, ему в игры "отправь баг главному пингвину и посмотри как он станет красиво прыгать и ругаЦЦЦО" играть некогда. В такой ситуации нужно искать выход, ЗДЕСЬ И СЕЙЧАС! И он не струсил - не вернул всё в виндовс (где всё работало) - а пофиксил ситуацию.
Но вам, супер админам супер домашних супер кластеров этого не понять, с ваших высот такую "бытовуху" не видно :))

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 01-Сен-09, 19:45

>Тем кто тут умничал - В САД!
>У парня производство а не ваши домашние суперкластеры ... У него под
>управлением большая пром система, ему в игры "отправь баг главному пингвину
>и посмотри как он станет красиво прыгать и ругаЦЦЦО" играть некогда.
>В такой ситуации нужно искать выход, ЗДЕСЬ И СЕЙЧАС! И он
>не струсил - не вернул всё в виндовс (где всё работало)
>- а пофиксил ситуацию.
>
>Но вам, супер админам супер домашних супер кластеров этого не понять, с
>ваших высот такую "бытовуху" не видно :))
Не надо обобщать...
Я к примеру, не имею такой роскоши как "не вернуть всё в виндовс (где всё работает)"
И посему, на всё что больше 1Тб ставим XFS...
А почему, - да потому что, мы тиоретеги дох..я читаем документации,
и в пендюрить ext4 на 14 Тб массив у нас мозга не хватит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от vitek (??) on 02-Сен-09, 14:04

причём  сразу, а не после того как проблема появилась.
да ещё и на lvm, ij, снепшоты были - http://en.wikipedia.org/wiki/XFS#Snapshots
зы:
а "впендюрить ext4" - а она с каком-либо дистром с поддержкой (rhel, sles,..) уже идёт?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

48. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 02-Сен-09, 16:59

rhel, sles - неа, а вот Убунта идет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

66. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от vitek (??) on 03-Сен-09, 01:05

lts?
врядли

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

78. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от User294 (ok) on 03-Сен-09, 22:44

>rhel, sles - неа, а вот Убунта идет.
Она там пока идет как не-дефолтная ФС. В таком виде она и остальных есть - ядро у всех кроме наиболее махровых некрофилов уже давно умеет с ней работать. А юзеж неумолчательных настроек... позволю себе боянную цитату про рис.1 :)
---------
Мы установили немало умолчаний. Они нам нравятся. Если бы это было не так, мы бы сделали умолчаниями что-нибудь другое. Так что уберите свои грязные руки от наших умолчаний. Не трогайте их. Считайте их предопределенными. "Предопределенные умолчания" - звучит неплохо! Если вы их измените и ваша система зависнет, заткнитесь. См. pис. 1.
---------

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 01:15

как-бы приходится работать с протоколированием работы буровых островов (развернутого типа). как этот (не распальцовки ради ;) :
http://images.pennnet.com/articles/os/thm/th_0805offbure2.jpg
протоколирование - только небольшая часть задачи. так что если софтина с самого начала продумана, то подобные проблемы возникают не в таких пропорциях и не там.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Filosof on 01-Сен-09, 20:01

exFat поддерживает до 2х ексабайт - разделы -:)))))
кажется так они хвастались. Правда как он посмотрит на 7ТБ  файл мне действительно
интересно
Автору - незачёт. Тема не разкрыта.
В коментах вижу более интересные решения.
Зающие товарищи, подпишите пожалуйста, кто из них работает?
XFS -это кончено хорошо, и мне нравится. Но формтить ради операции удаления... Вы простите.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 01-Сен-09, 20:54

>Автору - незачёт. Тема не разкрыта.
как раз раскрыта, решение найдено. В коментах другого проверенного нет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 01-Сен-09, 23:50

Ни куя не раскрыто
http://i007.radikal.ru/0909/30/86b5c9a798b6.png

80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb свободной оператифки.
7терабаб должны за ~300 сек. удалится, думается будет быстрее.
Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 02-Сен-09, 00:18

>80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb
>свободной оператифки.
>
>7терабаб должны за ~300 сек. удалится, думается будет быстрее.
>
>Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....
7 терабайт фигурирует в сообщении, а не 7 гигабайт и не 70 гигабайт, это совершенно разные вещи и из удаления 80-гигабайтного файла никаких выводов сделать нельзя.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 02-Сен-09, 01:28

Да ну?! Доказательства в студию?
Скорость винта? Щаз. При 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 часа).
-------
Не уж-то все 80 Гб в ОЗУ влезли и оттуда удалились???
3 Гига, и пипец...

Да, 80Гб не 7 Тб, но оба размера гораздо больше всевозможных кэшей, аптимизилок, LARGEFILE64, PAE, итп...
Так что я убежден что оно пойдет линейно, а именно за 300 сек. исчезнет, 7Тб.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

31. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 02-Сен-09, 01:32

>Да ну?! Доказательства в студию?
Человек привёл доказательство в первом же посте. Можно ему верить, можно не верить, но аргументировать своё недоверие некорректно проведённым тестом нельзя.
Как аргумент в защиту ТС: http://inf.by/linux/?tgid=4204

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

49. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 02-Сен-09, 17:05

>>Да ну?! Доказательства в студию?
>
>Человек привёл доказательство в первом же посте. Можно ему верить, можно не верить
Я ему верю, в том что них..я не работает, но не в том, что виновата ext4
Он это вывел методом исключения, учёл почти всё кроме самодельной сборки ядра 2.6.30.5,
на сколько мне известно, ни в одном дистрибутиве его ещё нет!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 01:37

да можно даже создать табличку зависимостей скорости удаления от размера файла. ;) ежели человек не верит. только в реале еще может быть куча трансакций к этому винчестеру, отчего io wait может прыгнуть вверх.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 02-Сен-09, 09:34

>Да ну?! Доказательства в студию?
>
>Скорость винта? Щаз. При 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)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

69. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от John Lepikhin (ok) on 03-Сен-09, 08:23

1. Как минимум, странно мерить скорость винта, читая из медленного /dev/urandom. Читайте из /dev/zero.
2. Не надо мерить скорость винта, записывая файлик 100MB размером. Либо выключите write-cache, либо пишите в несколько раз больше, чем есть оперативки.
3. Нет линейной зависимости между размером файла и скоростью его удаления. И размер файла — далеко не единственный фактор, влияющий на это. В особенности при удалении с раздела, находящегося на программном рейде.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 02-Сен-09, 09:28

>exFat поддерживает до 2х ексабайт - разделы -:)))))
>кажется так они хвастались. Правда как он посмотрит на 7ТБ  файл
>мне действительно
>интересно
>
>Автору - незачёт. Тема не разкрыта.
>В коментах вижу более интересные решения.
>Зающие товарищи, подпишите пожалуйста, кто из них работает?
Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов HDD.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от pavlinux (ok) on 02-Сен-09, 17:17

>[оверквотинг удален]
>>мне действительно
>>интересно
>> Автору - незачёт. Тема не разкрыта.
>> В коментах вижу более интересные решения.
>> Зающие товарищи, подпишите пожалуйста, кто из них работает?
> Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких
> дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов
> HDD.
Купи, потесть, и расскажи другим.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Zenitur on 02-Сен-09, 00:18

лоол! И как это добавили? И сколько времени это стирается на XFS? Минута? Секунда?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

47. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Aleksey (??) on 02-Сен-09, 16:57

В блоге написали:
"Народ, попробовав xfs все поехало как надо, стирание не более 1 минуты занимает."

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

46. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Aleksey (??) on 02-Сен-09, 15:58

Капец. Это называется форум администраторов. У человека возникла проблема с удалением файла, а ему говорят, что нефиг создавать такие большие файлы (писать на русском языке, использовать БД и т.д.).
Типа его кто-то спрашивает о том, какого размера файлы надо создавать. Его задача - решать конкретные производственные задачи (в данном случае упаковывать логи и записывать на носитель), все остальное - вне уровня его компетенции. Такое ощущение, что в крупных организациях никто не работал.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

55. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 02-Сен-09, 20:57

1. это не только форум админов
2. решение проблемы подразумевает также объяснение причин. решения типа "если программа не работает, переустановите виндовс" можно считать решениями? если начальство после этого отстанет - может даже и прокатит. а если сложные ситуации возникают систематически и начальству нужно объяснение причины?
3. птушные знания порождают птушные решения, уж извините.
4. выше было приведено несколько способов диагностики и установления причин. ссылки на возможные причины тоже были приведены, но опять же: прочитанное в сетке совсем не означает действительное на конкретной системе, потому что от многих факторов зависит.
5. ситуация с файлами описана очень неконкретно, обычно идет разбор полетов после более деталированного описания. методом тыка нашли решение?
6. если у автора после найденного решения пропала головная боль, то это может и хорошо для него, только другим подобные решения не могут подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу некоторых причин, поменять.
7. тут уж не к автору, но тем не менее: за подобные софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по рукам - за решения на яве. налабали шустро пионэры чего-то там за пару дней и как-бы на данный момент это всех устраивает. а через неделю?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

58. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora on 02-Сен-09, 22:17

>2. решение проблемы подразумевает также объяснение причин. решения типа "если программа не
>работает, переустановите виндовс" можно считать решениями? если начальство после этого отстанет
>- может даже и прокатит. а если сложные ситуации возникают систематически
>и начальству нужно объяснение причины?
Объяснения были даны: ext и reiser из рук вон плохо работают с большими файлами. Большего для решения задачи поставленной автором и не нужно.
>3. птушные знания порождают птушные решения, уж извините.
Афтар тот может быть кандидатом наук или доктором, между прочем, и заниматься он совсем не программингом и админством, а совсем другими делами, коих дофига на подобных объектах. Ему не нужно лезть в нюансы линукса, он решил свою задачу. То что вас отчислили из ПТУ это ваши личные половые проблемы. Да и так никто и не дождался, в чем проблема с грамотностью у автора??? Покажите пожалуста.
>5. ситуация с файлами описана очень неконкретно, обычно идет разбор полетов после
>более деталированного описания. методом тыка нашли решение?
Еще раз внимательно читайте тот топик в ЖЖ, там ясно сказали, reiser и ext плохо работают с большими файлами, или грамотность не позволяет читать?
>6. если у автора после найденного решения пропала головная боль, то это
>может и хорошо для него, только другим подобные решения не могут
>подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу
>некоторых причин, поменять.
У кого нет возможности поменять, тот пускай разбирается, у автора того топика была простейшая задача положить ВРЕМЕННО файл, завернуть в архив и удалить.
>7. тут уж не к автору, но тем не менее: за подобные
>софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по
>рукам - за решения на яве. налабали шустро пионэры чего-то там
>за пару дней и как-бы на данный момент это всех устраивает.
>а через неделю?
Это да, по Российски, наверняка еще и бабла стоит немерянно. Откат рулит.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

63. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 02-Сен-09, 23:47

>7. тут уж не к автору, но тем не менее: за подобные
>софтверные решения, типа террабайтных лог-файлов принято по башке стучать и по
>рукам - за решения на яве. налабали шустро пионэры чего-то там
>за пару дней и как-бы на данный момент это всех устраивает.
>а через неделю?
пионеры... налабали... Вам хоть раз доверяли делать софт такого уровня?
И заметьте, у человека был-таки припасён дисковый массив на 7 терабайт, наверно не случайно. Хорошо что всё работает - и именно это является критерием качества, а не эстетика.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

64. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora (??) on 02-Сен-09, 23:50

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

72. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Developer on 03-Сен-09, 14:24

то есть ты сейчас начинаешь рассуждать о материях, в которых даже не разбираешься (это про софт такого уровня)?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

80. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 03-Сен-09, 23:38

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

65. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Aleksey (??) on 03-Сен-09, 00:33

> 6. если у автора после найденного решения пропала головная боль, то это может и хорошо для него, только другим подобные решения не могут подойти вовсе. хотя бы, потому что файловую систему нельзя, в силу некоторых причин, поменять.
Странно, файловую систему менять нельзя, а программный комплекс переписывать значится можно. Оригинальная логика. Я бы из двух этих вариантов однозначно выбрал смену ФС, т.к. это наиболее простая и легко осуществимая операция.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

73. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Developer on 03-Сен-09, 17:28

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

75. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от _umka_ (??) on 03-Сен-09, 18:19

угу. и начинать тестирование с 0 ибо потом окажется что запись в log вызвала свиг по времени выполнения и вылез какой нить race conditionals который и раньше был - но был менее вероятным.
Ну есть еще ошибки в коде самого логера - который может уронить систему.. в прочем чего объяснять - вы же и так знаете ?:)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

85. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 03-Сен-09, 23:56

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

88. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 04-Сен-09, 00:22

извиняюсь, не ко мне было адресовано...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

79. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 03-Сен-09, 22:59

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

81. "Решение проблем с удалением файлов гигантского размера в Lin..." –1 +/–

Сообщение от Karbofos (??) on 03-Сен-09, 23:43

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

82. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 03-Сен-09, 23:46

>для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим,
>плюс запас на будущее. вы про такое не слышали? есть даже
>книжки по этой тематике.
Как-то я читал воспоминания одного научного сотрудника. Он работал в институте, занимающемся усовершенствованием атомных электростанций. По его словам, все их предложения принимались, высоко оценивались, но никогда не внедрялись. Потому что есть старый инженерный принцип - "работает - не трогай". Подтверждений ему - море.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

84. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 03-Сен-09, 23:50

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

86. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 04-Сен-09, 00:04

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

87. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 04-Сен-09, 00:16

>>для этого существует тестирование вообще-то. тестирование поризводится в условиях, приближенных к рабочим,
>>плюс запас на будущее. вы про такое не слышали? есть даже
>>книжки по этой тематике.
>
>Я представляю начальника, к которому приходит администратор с предложением остановить завод на
>месяц для тестирования новой системы логов. Или тот же начальник, слушающий
>сообщение админа, что из-за недостатка места в дисковом массиве придётся запустить
>тестирование системы и на это надо миллион баксов и пол-года человекочасов...
Тестовая конфигурация не так уж дорого стоит:
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-архитектуре.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

89. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 04-Сен-09, 00:37

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

90. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 04-Сен-09, 01:01

>точно также может обстоять дело с человекочасами... и может оказаться, чтобы симулировать
>поведение оборудования, достаточно написать небольшой скриптик... :)
А когда реальное оборудование откажется эмулировать поведение скриптика...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

92. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 04-Сен-09, 01:22

вы просто даже не в курсе... не больно стоять на своем?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

93. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 04-Сен-09, 02:39

>вы просто даже не в курсе... не больно стоять на своем?
Как-то я читал про отличие ученика из школы для отсталых от ученика обычной школы. Задают им задачу:
- шёл мальчик по улице, нашёл две конфеты. Потом нашёл ещё три конфеты. Сколько конфет нашёл мальчик?
Обычный школьник скажет "Пять", ну может ошибётся скажет "Четыре". Отсталый же школьник может начать изучать вопрос куда шёл мальчик, откуда, кто потерял конфеты, какие конфеты, нельзя ли пойти на улицу посмотреть нет ли там конфет...
Так вот, вспомнил я эту особенность некоторых... Тема про то что ext4 не справилась с большим файлом, а не про то что логи неправильно формируются и надо написать новую программу, отладить...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

95. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 04-Сен-09, 09:48

нет, вы элементарно не смогли объяснить причину так называемого косяка ext4. кроме постранных ссылок на ошибку в кернеле.
историю с учеником сами придумали? может вам надо было писателем пойти? талантище пропадает!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

98. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora (??) on 04-Сен-09, 12:55

>нет, вы элементарно не смогли объяснить причину так называемого косяка ext4. кроме
>постранных ссылок на ошибку в кернеле.
А у вас есть мнение относительно такого поведения ext4 на большом файле? Озвучте его нам, мы слушаем!
(ЗЫ. Самый большой файл который я видел был 39Гб аля образ Blu-Ray диска), стирался он на ext около 20 сек.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

110. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 06-Сен-09, 23:43

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

111. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Karbofos (??) on 06-Сен-09, 23:48

опечатка: 5400 оборотов в минуту

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

91. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 04-Сен-09, 01:02

>Итого: ~ 75000 руб.
>-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.
Гениально...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

115. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 15-Сен-09, 21:20

>>Итого: ~ 75000 руб.
>>-- цена, сопоставимая со стоечным 2U-сервером на x86-архитектуре.
>
>Гениально...
Вот тачка: http://www.3dnews.ru/news/kak_sozdat_petabaitnii_klaster_za_...
"Рассмотрев коммерческие решения, компания посчитала, что выгоднее будет разработать кластер собственными силами. В итоге, каждый 67-Тб сервер форм-фактора 4U обошёлся в $7867. Петабайт - $117 тыс."

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

97. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora (??) on 04-Сен-09, 12:52

>Тестовая конфигурация не так уж дорого стоит:
>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 тыр.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

105. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 05-Сен-09, 23:34

>>ОС 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 т.р.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

108. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от lora (??) on 06-Сен-09, 13:15

>>>ОС 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 т.р.
Вы туда набейте винтов, и поглядите сколько будет стоить.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

109. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от iZEN (ok) on 06-Сен-09, 20:41

>[оверквотинг удален]
>>
>>Я высказался про альтернативу. Ведь Linux не может предложить ничего более вменяемого,
>>кроме XFS.
>>
>>>2U приличные гораздо дороже стоят. Примерно от 100 тыр.
>>
>>2U: IBM System x3650 (Xeon E5504, до 128ГБ RAM, ServeRAID-BR10i, до 12
>>HDD 2.5" SAS/SATA/SSD) ~ цена от 70 т.р.
>
>Вы туда набейте винтов, и поглядите сколько будет стоить.
А мне не нужно ТУДА набивать винтов. Я предложил АЛЬТЕРНАТИВНУЮ тачку (PC), сравнимую по ценам с ЭТИМИ, уже набитую.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Аноним (??) on 02-Сен-09, 18:24

Эм, а ничего что ext3 файлы на 7 ТБ не поддерживает?
http://www.nixp.ru/articles/linux_ext3_faq_russian#012

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

53. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Pilat (ok) on 02-Сен-09, 18:27

>Эм, а ничего что ext3 файлы на 7 ТБ не поддерживает?
>
А ничего что ext4 ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

70. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от _umka_ (??) on 03-Сен-09, 09:26

>>Эм, а ничего что 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.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

71. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от _umka_ (??) on 03-Сен-09, 09:40

>[оверквотинг удален]
>другое, пока что оправдана.
>Проблемы с 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);

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

57. "Решение проблем с удалением файлов гигантского размера в Lin" +/–

Сообщение от i (??) on 02-Сен-09, 22:09

а вот например 2>/BIGFILE тоже не сработало бы ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

103. "Решение проблем с удалением файлов гигантского размера в Lin" +/–

Сообщение от vvs (??) on 05-Сен-09, 16:34

имелось ввиду :> FILE?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

101. "Раздел полезных советов: Решение проблем с удалением файлов ..." +/–

Сообщение от Slavaz (ok) on 04-Сен-09, 19:02

>Решение: проблема исчезает при использовании файловой системы XFS.
А с именованными пайпами поиграться не пробовали?
Типа, создать пайпу с таким же именем, как и этот огроменный файл. С другой стороны к пайпе присоединяется некий демон (на си, перле, питоне, ...), который "нарезает" поток данных из пайпы на порции: архивирует, копирует на ленту и т.д.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

112. "Раздел полезных советов: Решение проблем с удалением файлов ..." +/–

Сообщение от eplumber (??) on 08-Сен-09, 16:43

хм, а у меня недавно XFS на руках умерла...
Всего-то было около 450 Гб. Благо ничего серьезного не содержала, лишь видеонаблюдение за неделю.
Монтируется, а в каталог зайти не дает.. xfs_check молотит минут 15, потом выходит без объяснений.
Что делать? Перешел на reiserfs..

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

114. "Раздел полезных советов: Решение проблем с удалением файлов ..." +/–

Сообщение от Karbofos (??) on 12-Сен-09, 23:25

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

116. "Решение проблем с удалением файлов гигантского размера в Lin..." +/–

Сообщение от Игорь (??) on 22-Сен-09, 17:08

в свое время лет 6 назад, читал про файловые системы чтоб под базу выбрать, тоже остановился на xfs и не пожалел,
хоть старовата но рулит до сих пор, не разу не падвела тьфу-тьфу
кстати на ext4 не пробовали удалять так
"nice -n 19 rm -f bigfile &"
мне помогало продолжить работу, а фоном заканчивалась операция удаления

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
Сообщение от anonymous (??) on 01-Сен-09, 13:54
Все гениальное просто
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от User294 (ok) on 03-Сен-09, 22:37
	>Все гениальное просто Тем не менее, удаление файла ~30 секунд XFSом я видел :P. Всего-то 4Gb торент сдуру слитый без преаллокации. Представляю себе что будет если такой же вермишелью записать 7Tb...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
Сообщение от abigor on 01-Сен-09, 14:35
Понимаю, что это флуд. Но что может занимать столько места одним файлом? Делаю предположение, что это может быть видео?
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от svn (??) on 01-Сен-09, 14:53
	база данных например
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от cvsup (ok) on 01-Сен-09, 15:25
	На 7ТБ? база данных чего?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от pavlinux (ok) on 01-Сен-09, 16:40
	>На 7ТБ? база данных чего? http://community.livejournal.com/ru_linux/2289534.html > PS. Предвосхищая вопросы. Железка это многоузловой промконтроллер, управляющих огромным > (450 тыс. тонн) газохранилищем. В связи с событиями на СШ ГЭС, начальством было > приказано debuglevel увеличить на 2 пункта (условно с 1 до 4 при максимальном 6). > Если раньше 7Тб эти набегали в лучшем случае за 50-60 суток, то сейчас эти 7 Тб > заполняются за 18-20 часов.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Karbofos (??) on 02-Сен-09, 01:03
	фигасе, и это все дело одним файлом? в принципе, объясняет многое уровень русского языка у того коллеги. совсем плохо, если он живет в России. уровень языков программирования, надеюсь, у него выше... оттого и бешеные проблемы преодолением трудностей, которые создали себе сами. дебаг-инфу можно создавать и в компактной форме, вплоть до битовой кодировки. а дальше уже и на лету компримировать и прочее, если мощности позволяют. да, конечно, зависит от "запущенности" софта
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 02-Сен-09, 01:44
	>объясняет многое уровень русского языка у того коллеги. Уровень русского языка ничего не объясняет, он же не поэт и не писатель? Объясняет все "Конфиг Core2Quad 6600/8 Гиг ECC/i3000 Некий java софт от большой технологической железки пишет огромный файл до 7 Тб". Выводов несколько. Софт писали недавно, оборудование закупили недавно, писали на java, но не в этом дело, еще дело в "технологической железке", которая генерирует файлы по 7ТБ за сутки. Что бы они делали десять лет назад (в 1999), покупали бы CRAY? Там внутри явно проблемы с оптимизацией, т.к. сейчас, куда не плюнь, практически все данные передаются/хранятся в сжатом виде и сжимаются по многу десятков раз (ethernet/SDH/PCI express/DOCx/PDF/JPG/MP3/FLAC/MP4...). Только сжимаются они не в ZIP архив 7ТБ базу, а на том уровне, на котором проще всего её осмыслить. Как минимум в голову приходит PNG.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Karbofos (??) on 02-Сен-09, 01:57
	основная проблема это "Некий java софт"? проверить, не так уж и сложно, экспериментируя с меньшими размерами файла проверять элементарно в top, что происходит. есть и другие подручные средства линукс
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 02-Сен-09, 01:57
	>Как минимум в голову приходит PNG. Это если данные от датчиков поступают в бинарном виде. Если это лог, то сжимать его еще проще, т.к. 90%(из головы взял) данных одинаковые. Ну не верю я, что датчик выдает каждую секунду разные данные + штамп времени, там меняется всего 1,2,3 бита! Идентификатор датчика не меняется вовсе. Есть преобразования Фурье, есть, да чего только нет... Было бы желание.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 02-Сен-09, 02:05
	>Далее этот файл сжимается зипом до приемлимых размеров (до 200-400 Гб) Полный звездец! Значит база легко может весить 200-400Гб сама по себе. А если применять специальные методы (выше написал, что сразу пришло в голову), реальный размер этой базы - сотни мегабайт и даже мегабайты! На таком железе данные из LOG'а извлекутся мгновенно, а вот из 7ТБ базы в ZIP на ленте - ПОЛНЫЙ ЗВЕЗДЕЦ!
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Админ Веня on 02-Сен-09, 09:23
	Разрабатывали систему, меньшего масштаба, для "мобильных "электростанций. При условий что датчиков от 50 до 500, при постоянной работе двигателей, и без усреднения данных(т.е. данные пишутся примерно от 10000 в секунду), база занимала за 3 месяца около 40 гиг. база мускул (ембедед), 2гига память. решение используется уже на нескольких десятках объектов в течении 4х лет
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 02-Сен-09, 12:53
	>база мускул MySQL - база данных специально для критически важных объектов, а вот 5 формул из 2 курса любого вуза применить - все, сломается все критическая надежность, этого же нельзя допустить! Еще раз говорю, даже процессор без злых алгоритмов + алгоритмов самопроверки и т.д. не работает. Почему нельзя записывать показания датчиков в "сжатом" виде? Неужели у нас нет на это ГОСТов? Как записывали показания датчиков до 1998 года? Зачем записывать в MySQL (где тоже могут быть ошибки) базу явно одни и те же цифИри? Чтобы отвязались? Мы вот мол логи пишем, если чего, это не мы.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Админ Веня on 05-Сен-09, 23:09
	Таки нет, цифры разные при старте двигателей и во время работы оного. не синхронные они. следить нужно. а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	106. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от aborland on 05-Сен-09, 23:52
	>Таки нет, цифры разные при старте двигателей и во время работы оного. >не синхронные они. >следить нужно. >а мускул почему... чем заменить можно, легковесным и "интеллектуальным"? Дык и на интербейз посмотреть можно и на sqlite и даж свое ченить на коленке слабать
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Админ Веня on 06-Сен-09, 12:57
	_СТАВИТЬ_ сервер баз данных для этого??? у нас "мускул ембедед"
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Karbofos (??) on 02-Сен-09, 02:17
	> Уровень русского языка ничего не объясняет, он же не поэт и не писатель? часто показывает на уровень образования. к примеру, мне тут один птушник пыталя давеча доказать, что логические и битовые операции - вещи идентичные. но, с русским языком я могу и заблуждаться. :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Pilat (ok) on 02-Сен-09, 02:22
	>> Уровень русского языка ничего не объясняет, он же не поэт и не писатель? > >часто показывает на уровень образования. к примеру, мне тут один птушник пыталя >давеча доказать, что логические и битовые операции - вещи идентичные. > >но, с русским языком я могу и заблуждаться. :) Правильное владение русским языком очень важно. Наприимер, сколько Ваших, Karbofos, сообщений в этом топике я ни прочитал - столько раз был в замешательстве: что Вы хотите сказать, какую точку зрения поддерживаете? А всего-то плохое владение языком. :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Karbofos (??) on 02-Сен-09, 10:08
	если бы я конкретно пощупал систему, на которой этот гемор происходит, где допустили ТАКОГО рода раздолбайство с протоколированием на некоем ява софте... а так, кроме общих рекомендаций по поиску причин зависонов, которых аффтар явно не знает, аки простые методы диагностирования, нечего и сказать. а если и скажу, так аффтар этого, скорее, не поймет. так что лично Вы можете быть в замешательстве от каждой буквы, написанной мной. если уж так сильно хотите. io wait тоже вызывает недоумение?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от pavlinux (ok) on 03-Сен-09, 02:48
	Вы об каких логических операциях говорите, в формальной логике или в математической? И можно повторить то место, в котором ПТУшнег с вами наконец согласился.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Karbofos (??) on 03-Сен-09, 17:35
	он утверждал, что (boolTest1 ^ boolTest2) // boolTest1, boolTest2 are bool одно и тоже с (int32x1 ^ int32x2) // int32x1 int32x2 are integer (опреация исключаещего или в сях) пришлось даже программу писать, ибо в книжки он заглядывать не любит.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Iv945n (ok) on 02-Сен-09, 18:25
	> Как минимум в голову приходит PNG. Чо? Газохранилище генерирует картинки (фотографии газа? :-)) ) и сохраняет их в базу (нафига? учили же что лучше в файловой системе картинки хранить).
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 02-Сен-09, 20:41
	Да, Karbofos оказался прав. >учили же что лучше в файловой системе картинки хранить А меня учили базы данных хранить в RAW разделах. >Газохранилище генерирует картинки В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как можно осознанно, эффективно и без потерь сжать битовую последовательность.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Iv945n (ok) on 02-Сен-09, 21:11
	>>учили же что лучше в файловой системе картинки хранить >А меня учили базы данных хранить в RAW разделах. Оффтопик, речь о файловых системах. И что мешает завести под блобы отдельный раздел с подходящей файловой системой? >>Газохранилище генерирует картинки >В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от >изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как >можно осознанно, эффективно и без потерь сжать битовую последовательность. Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны именно на графику и звук соответственно, иначе бы жали и графику во FLAC и музыку в PNG.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	94. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Анонумоис on 04-Сен-09, 05:05
	>Оффтопик, речь о файловых системах. Честно говоря, я совсем не понял о чем речь в данной статье. Какие-то mysql базы невероятного размера на нестабильной версии файловой системы... >Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны >именно на графику и звук соответственно, иначе бы жали и графику >во FLAC и музыку в PNG. Может я изъясняюсь непонятно... Мне показалась странной база в 7ТБ, которую каждые пол дня пытаются удалить... Вот я и предположил, что по аналогии с музыкой и звуком можно и эту информацию как нибудь сжать.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	102. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от нер on 05-Сен-09, 15:48
	> Уровень русского языка ничего не объясняет Заблуждение. Невозможно много читать и не знать языка. Плохой русский - мало читал. Какой он тогда, к жукам майским, специалист, если он за всю жизнь 3 книги прочёл? Под хвост сразу таких гнать надо с таких проектов. Понимаете?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от lora on 02-Сен-09, 12:02
	А что не так с русским языком у автора того топика на ЖЖ?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
Сообщение от timon on 01-Сен-09, 14:49
ха, а решить задачу на ext4 слабо?
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от pavlinux (ok) on 01-Сен-09, 15:55
	# unlink /BIGFILE.sql не? mount -o remount,barrier=0 /dev/superraid не?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Решение проблем с удалением файлов гигантского размера в Lin..."		+/–
	Сообщение от Timon on 02-Сен-09, 23:34
	дайте массив на 10ТБ, проверю :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору