Хочу патч к extfs, суть такова: есть флаг expire с некой датой. Когда секунды unix timestamp нагибают, то файлы удаляются. ЭТО ЖЕ ТАК ПРОСТО БЛЯДЬ И НИХУЯ НИГДЕ ТАКОГО НЕТ!
в момент обращения к иноде. Если текущее время больше заданного, то коцаем иноду + переделываем битмап свободного места. Вроде все, не? Вот все линки удалить сложнее, поэтому мы и правим саму иноду.
1. Сядь, напиши тулзу, которая будет указанные файлики и дату, когда их дропнуть добавлять в текстовый файл — 5 минут, 10-20 строк на баше. А лучше дату кодировать в имя файла. 2. Напиши тулзу, которая будет просматривать этот список и удалять файлы с диска и из списка (в случае, когда даты записаны в имени файла со списком всё вообще просто) — 5-30 минут, в зависимости от твоих скиллов, продуманности решения и языка для реализации. 3. Пропиши этот скрипт в крон с удобным интервалом (раз в час или в сутки будет вполне ок).
Блядь, у тебя всё это в кэш поместится, естественно оно быстрое. К тому же какой-нибудь locate/updatedb работает. Ты сам то веришь, что он за полсекунды 150К файлов с диска прочекает? Вот данные с tmpfs 236677
real 0m0.818s user 0m0.260s sys 0m0.588s
И чего ты хочешь сказать? Что у тебя диск быстрее оперативки, толстяк? raid5, ext4 создан с оптимизацией под него, la за время операции вырос раза в три: 5225476
нахера ему файлы чекать? Ему кроме метаданных нихрена не нужно же. И таки я хочу сказать что что-то у тебя сделано через жопу, если всё так тормозно. И оперативка у тебя медленная лол.
С ним то заебись всё, это ты какую-то хуйню городишь, утверждая что find это ок. Блин, оно так и работает сейчас и это МЕДЛЕННО СУКА, а исправить это практически никак нельзя. dd if=/dev/sda of=/dev/null bs=1M count=5000 5242880000 bytes (5.0 GB) copied, 15.076229 secs, 331.4 MB/s
Алсо, по теме: проводить построчный анализ файла, где десяток лямов строк может посоветовать только полный мудак, никогда не сталкивавшийся с высокими нагрузками. Ты бы мне его ещё в БД бы предложил запихнуть, уёба.
у меня задача проста: удалять через некоторое время кэширующиеся файлы. Сейчас это сделано с помощью find'а в cron'е, что заставляет серваки вставать раком в каждый момент запуска скрипта. Был предложен интересный концепт для решения проблемы на уровне ФС, и тут ты такой с говном и ахуительными советами.
Организуй группировку файлов так, чтобы ты мог удалить разом одну/несколько папок с файлами рекурсивно без дополнительных проверок. И почитай Танненбаума :)
давно на торрентах не раздаю: ещё не хватало чтобы менты ко мне домой пришли и бутылку шампанского подарили за распространение всякого контрафактного дерьма.
это было в моей CMS, которую я когда-то начинал лепить, а она базировалась на самодельной ФС.
это нихуя не просто и не дешево.
поэтому этого нигде и нет.
ленивые пидоры
Ну, положим, изуродовать иноду можно парой байт. Файл удален не будет, но содержимое покоцано
хуйню сказал. дело очевидно не в иноде.
тогда в чем? обесни
в какой момент ты будешь это делать?
в момент обращения к иноде. Если текущее время больше заданного, то коцаем иноду + переделываем битмап свободного места. Вроде все, не? Вот все линки удалить сложнее, поэтому мы и правим саму иноду.
ну вот и нахуй это в таком виде нужно?
а чо не так?
cron @ find
ага блядь, на разделе с 20тб знаешь как оно диск ебать будет?
зависит от очень многих параметров. Если хуёво зделано, то сильно, ага.
1. Сядь, напиши тулзу, которая будет указанные файлики и дату, когда их дропнуть добавлять в текстовый файл — 5 минут, 10-20 строк на баше. А лучше дату кодировать в имя файла.
2. Напиши тулзу, которая будет просматривать этот список и удалять файлы с диска и из списка (в случае, когда даты записаны в имени файла со списком всё вообще просто) — 5-30 минут, в зависимости от твоих скиллов, продуманности решения и языка для реализации.
3. Пропиши этот скрипт в крон с удобным интервалом (раз в час или в сутки будет вполне ок).
И НЕ ЕБИ ЛЮДЯМ МОЗГ.
typical perl programmer
ноно, я тоже перлокодер
Нет, ты гей.
Typical old school linux developer // fixed.
> 15 лямов файлов
> разделы в десятки терабайт
> просматривать этот список и удалять файлы с диска и из списка
сука, какой же ты тупой.
$ time find /mnt/torrents/ -mtime +5 | wc -l
155249
real 0m0.691s
user 0m0.112s
sys 0m0.299s
раздел на терабайт. ЧЯДНТ?
ext4, ага
Блядь, у тебя всё это в кэш поместится, естественно оно быстрое. К тому же какой-нибудь locate/updatedb работает. Ты сам то веришь, что он за полсекунды 150К файлов с диска прочекает?
Вот данные с tmpfs
236677
real 0m0.818s
user 0m0.260s
sys 0m0.588s
И чего ты хочешь сказать? Что у тебя диск быстрее оперативки, толстяк?
raid5, ext4 создан с оптимизацией под него, la за время операции вырос раза в три:
5225476
real 12m39.552s
user 0m9.542s
sys 1m1.594s
нахера ему файлы чекать? Ему кроме метаданных нихрена не нужно же. И таки я хочу сказать что что-то у тебя сделано через жопу, если всё так тормозно. И оперативка у тебя медленная лол.
> что-то сделано через жопу
например?
> оперативка у тебя медленная лол.
комплектная в dell r510
журнал маловат, например. Странный вопрос, ибо всё-таки твоя [а не моя] работа — разбираться с конфигурацией и производительною хранилища.
С ним то заебись всё, это ты какую-то хуйню городишь, утверждая что find это ок. Блин, оно так и работает сейчас и это МЕДЛЕННО СУКА, а исправить это практически никак нельзя.
dd if=/dev/sda of=/dev/null bs=1M count=5000
5242880000 bytes (5.0 GB) copied, 15.076229 secs, 331.4 MB/s
хуйню порешь
скажи где и я исправлюсь ._.
Ты нихуя не понял. Только не говори, что работаешь разработчиком или сисадмином. Я бы тебя нахуй уволил.
> find
> update/locatedb
Убейся.
гейчую этого утроса, кстати
я жду конструктивных ответов, а не кококо от местных петушков, меряющих производителность дисковой подсистемы на говнодиске с торрентами :cf:
#ogttts/30
я там только метания какашками вижу. %%бля, я тебя более адекватным считал%%
а у меня в шиндошсе всё работает и так
Хуже долбоёба только долбоёб, который не понимает, что он долбоёб.
приятно, что ты осознаёшь это.
Алсо, по теме: проводить построчный анализ файла, где десяток лямов строк может посоветовать только полный мудак, никогда не сталкивавшийся с высокими нагрузками. Ты бы мне его ещё в БД бы предложил запихнуть, уёба.
Как сформулировал задачу, такой ответ и получил.
у меня задача проста: удалять через некоторое время кэширующиеся файлы. Сейчас это сделано с помощью find'а в cron'е, что заставляет серваки вставать раком в каждый момент запуска скрипта. Был предложен интересный концепт для решения проблемы на уровне ФС, и тут ты такой с говном и ахуительными советами.
Организуй группировку файлов так, чтобы ты мог удалить разом одну/несколько папок с файлами рекурсивно без дополнительных проверок.
И почитай Танненбаума :)
Проектированием архитектуры занимаюсь не я — работаю с тем что есть.
Плохо. Сказал, что все уебаны и пусть чинят.
Ну и плюс разобраться чокак и починить самому.
>155249
админ порнотрекера детектед.
Он знает какую порнуху ты смотришь!
ну да, чем в файле держать лучше в фокспро засунуть, побыстрее будет.
давным давно уже прон с торентов не качаю, лол.
давно на торрентах не раздаю: ещё не хватало чтобы менты ко мне домой пришли и бутылку шампанского подарили за распространение всякого контрафактного дерьма.
кокойты примерный гражданин.
Фокспро есть под линуксы?
Ок.
>Отдано
>97.15 TB
gagaga
хуя ты дал. У меня с 2006 года в сперморепозитории отдано чуть больше трёх ТБ.
слабак
дурак
пёс
есть под пинукс и есть под дос. под шиндошс — только некошерное поделие с похожим названием. и не спрашивай меня откуда я это знаю.
Мои соболезнования.