Файловые системы и большое количество файлов

[metaclass]

Поведение NTFS на диске с порядка полмиллиона файлов меня как-то огорчает. Сейчас переношу с одного диска на другой - оно минут 15 только структуру папок сканировало.
Как линуксовые FS себя ведут в подобных случаях?

Comments

[inhate.livejournal.com]

чуда не будет. полмиллиона файлов - это очень-очень дорого везде.

[alll]

для dd вовсе не дорого :)

[norguhtar.livejournal.com]

Везде хреново. Ну reiserfs немного получше, но не сильно уж чтоб получше.

[plumqqz.livejournal.com]

А кстати что там с ней сейчас?

[norguhtar.livejournal.com]

Все плохо :) Рейзера заточили, 4 ветку не приняли ибо нехрен свои реализации VFS плодить.

[plumqqz.livejournal.com]

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

[norguhtar.livejournal.com]

Ну работает, но использовать все же чревато. Особенно при наличии ext4.

[plumqqz.livejournal.com]

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

Не подхватил.

[potan.livejournal.com]

Смысл использовать ext4, когда есть btrfs? Последняя дает гораздо больше возможностей, а ext4 ни чем не лучше старых стабильных XFS и JFS, и несовместима с ext2/3.

[norguhtar.livejournal.com]

Смысл в том что она сейчас mainstream. А btrfs до сих пор не имеет стабильной файловой структуры.

[http://users.livejournal.com/_slw/]

смысл использовать ext4/3/2, btrfs, reiserfs когда есть zfs?

[potan.livejournal.com]

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

[http://users.livejournal.com/_slw/]

хорошая там лицензия.
и что из функциональности там отсутствует?

[potan.livejournal.com]

Записываемые снапшеты.
А почему в Linuxовое ядро она тогда так долго попадала?

[http://users.livejournal.com/_slw/]

Записываемые снапшеты.
а какие они там?!

А почему в Linuxовое ядро она тогда так долго попадала?
проблемы негров...

[potan.livejournal.com]

В zfs только для чтения. В btrfs можно смотнировать на запись.

У меня сейчас слишком много на Linux завязано, что бы я безболезнено всезде вернулся на FreeBSD или перешел на Солярку. То есть zfs мне по расовому признаку не подошел.

[(Anonymous)]

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

[zelanton.livejournal.com]

вот поэтому, а так же потому, что вы знаете про и вам нужен только 1% из этого говна, человечеству нужна бытовая БД, вместо этой файловой поделки.

[kiryl.livejournal.com]

А чем fs не бытовая db?

[zelanton.livejournal.com]

да ничем

[kiryl.livejournal.com]

всё с вами ясно.

[zelanton.livejournal.com]

не за что

[permea-kra.livejournal.com]

Бытовая БД - это профанация. А не бытовая, с адаптацией ко всем приложениям и приличной скоростью... Нуну.

[zelanton.livejournal.com]

Я слышу в вашем "нуну" "это невозможно"

[permea-kra.livejournal.com]

Я сильно удивлюсь, если нечто такое в приличном качестве выкатят за разумные деньги.

[zelanton.livejournal.com]

ребе, тот рынок ужас как работает от объёмов. От ахренительных между прочим объёмов. Там таже опенсорсное бесплатное ПО нормально себя чувствует, а вы тут намекаете, что мол себестоимость невероятная. Глупо. Дело в нормальном мире давно не в себестоимости, а в том, сколько готов заплатить потребитель. Ибо себестоимость много, много ниже. На тех-то объёмах.

[metaclass.livejournal.com]

С мейнстримными языками программирования это возможно только если микрософт+гугл+эппл пригрозят нечеловеческими анальными карами каждому программисту, который вместо СУБД будет использовать файлы.

[zelanton.livejournal.com]

основания так думать?

[permea-kra.livejournal.com]

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

[zelanton.livejournal.com]

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

А на самом деле никаких барьеров нет.

Никаких проблем к встраиванию БД в ОС нету. Да, MS уже пыталась и у неё вышла тыква. Если что, когда-то с MS Word была та же история. И ещё много с чем. Просто цикл инвестирования предполагает накопление опыта. Будет нам БД, никуда не денемся. А усложнения не будет, будет упрощение, ибо низкий уровень знать нафик не надо будет.

[permea-kra.livejournal.com]

>>Никаких проблем к встраиванию БД в ОС нету
Не знаю, как в венде (хотя по доходящим до меня слухам там ситуация похожа), а в линупсах многие тулзы и драйвера завязаны на sysfs/procfs. Многие проги (обоснованно полагая, что разбираются в данном вопросе лучше) хранят свои данные в виде битового потока. И вы заколупаетесь объяснять разработчикам, что они неправы. Представление флешек в виде подмонтируемых каталогов, опять же. Т. е. по сути, для _перехода_ на системную БД потребуется переписать половину системного софта и придумать новый шелл плюс принять стандарты на апи. И проехаться по ушам всем железячникам для переписывания дров.

А прикрутить сбоку проблемой не является, да. Но это неинтересно.

[zelanton.livejournal.com]

есть в БД такая штука - блоб. Тот самый битовый поток.

Я заколупаюсь? Придёт Билли или этот, которой из Apple, как там его... И все возьмут под козырёк. Я на миллиардера пока что не тяну. Не там родился.

А API да, невероятная проблема. Нормальный API к БД прикрутить к БД невозможно - мне про это уже все уши прожужали. Только я до сих пор не понял почему.

А переписывать да, придётся. На том мы все (и не только мы) и наживёмся. И не я это придумал, если что.

[permea-kra.livejournal.com]

>>А переписывать да, придётся.
Вот я и говорю - поначалу скорее всего выйдет дорого, поскольку затраты нужно будет отбить ( а там выйдут гигабайты кода)

>>есть в БД такая штука - блоб. Тот самый битовый поток.
А зачем тогда бд ? Древовидная система объектов, с некоторыми из которых ассоциированы битовые потоки, уже есть сколько лет. Называется - fs.

>>Нормальный API к БД прикрутить к БД невозможно
Не в этом дело. надо
- принять стандарт
- этот стандарт должен учитывать тонкости подключения хранилищ
- этот стандарт должен работать с объектами заранее неизвестной структуры (т. е. быть расширяемым)
Т.е. это будет новый xml с жабами и червями.

[zelanton.livejournal.com]

Давайте предметно: чьи затраты, кто должен отбивать и кто на этом наживётся. Вышел линукс. Дрова нужны иные. Кто-то умер? Переписать было невозможно?

FS действительно формально попадает под определение БД, но существующие FS имеют массу ограничений, работуют с ориентацией на битовый поток, причём обязательно "один объект (файл) - один набор байтов", а данные там сбоку бантик. Кроме того FS изначально доступна пользователю, а концепция БД в принципе строиться на абстрагировании данных от пользователя, пользователю даётся интерфейс. Причём для каждого вида данных - свой.

А стандарт принимать необязательно. Рынок-то между гигантами попилен. Например, что майкрософт скажет, то мы и возьмём под козырёк. Кто-то может повыпендривается, но из откровенной хуйни никто не попробует революцию делать, так что никуда не денемся.

[permea-kra.livejournal.com]

>>Давайте предметно: чьи затраты, кто должен отбивать и кто на этом наживётся. Вышел линукс. Дрова нужны иные.
Не только дрова. Ну, давайте предметно: линукс показывает устройства в виде файлов в /dev и /sys и экспортирует кучу данных в /proc . На это точены все дрова (т. е. как минимум придется переписывать все дрова из ядра), интерфейс работа с консолью (stdin/stdout, терминалы и пр показываются программе в виде файловых дескрипторов), все системные приложения (udev, xorg-server, системы записи дисков, dd, etc, etc). В случае, если это дело перетаскивать под БД все это надо переписывать. Только ядро линупса - это 30 мб сжатого кода, а все вместе под гигабайт набежит. Человек пишет в лучшем случае 10 кб осмысленного кода в день, итого имеем порядка 3000000 человеко-дней, т. е. порядка нескольких сот человеко-лет только на разработку, а ещё нужно тестирование и документация. Т. е. проект потребует несколько тысяч людей. Пусть это индусы с оплатой $1000/мес, это $50/раб. день Тогда затраты составять 15 000 000 млн. На выходе же будет абсолютно новый продукт, требующий ещё затрат на рекламу и усилий по переносу всего и вся.

>>FS действительно формально попадает под определение БД, но существующие FS имеют массу ограничений, работуют с ориентацией на битовый поток, причём обязательно "один объект (файл) - один набор байтов", а данные там сбоку бантик.

И кто мешает эти недостатки устранять? Майкрософт вот этим в NTFS занялась.

[metaclass.livejournal.com]

Да достаточно условия "программисты согласны ее использовать вместо файловой системы", чтобы от разработчиков такой БД/системного API/фреймворка потребовались невероятные чудеса.
"И вообще, все это невозможно без метапрограммирования".

[zelanton.livejournal.com]

а вот вы преувеличиваете значение программистов. Это примерно, как заявить что у автомобилях "инженеры согласны размещать мотор только вот так", и плевать им на пользовательские характеристики.

Ребе, всё решает потребитель.

[metaclass.livejournal.com]

В данном случае программисты и есть потребители. API делается для них. И если микрософт выкатит какую-нибудь неудобоваримую хрень, народ слиняет в вебо-гугло-линукс какой-нибудь и это будет смерть для микрософта. Потому как программисты согласные ебаться с API OS для реализации прикладного софта, обеспечивают эту OS конечными пользователями.

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

[zelanton.livejournal.com]

API? Ребе, API - это такой гайковёрт. Гайковёрт (фреза, молоток, паяльник и т.д.) потребителю не видел должен быть. А если виден, то тут уже ни хера не инженер решает как оно должно быть. Ну пару процентов решает, не более того.

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

[metaclass.livejournal.com]

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

[zelanton.livejournal.com]

Ребе, а давайте вы мне покажите, где легаси такое сказали?

И ребе потребитель - не программист. Если бы fs пользовался только он то да. Но 99% "пользований" fs приходится не на него.

[metaclass.livejournal.com]

http://metaclass.livejournal.com/545548.html?thread=7306764

И по моему, файловой системой больше пользуются программисты, нежели обычные пользователи. Обычный пользователь открывает один документ из списка, в лучшем случае найдя его поиском, в худшем - тупо перебором пока не увидит знакомое имя. И потом работает исключительно внутри этого документа.
Я, для начала, вижу одно преимущество fs перед СУБД - в случае необходимости выдрать кусок из fs и скомбинировать с другой частью (т.е. перенести часть файлов в другую папку) сильно проще, чем сделать то же самое с СУБД - я просто удолбался, например, писать синхронизатор/импортер данных для обновления наших баз под Firebird. В новой версии софта модуль делающий примерно то же самое, будет использовать просто список файлов, т.к. функции СУБД кроме "найти по ключу" там не используются.

[c-a-s-u-s.livejournal.com]

как бы все же орет он не users....

[zelanton.livejournal.com]

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

[norguhtar.livejournal.com]

BeFS вам в руки. Практически все бытовые потребности ее индексирование покрывает.

[vk11.livejournal.com]

ты еще права доступа попробуй изменить :))))

[vaddimka.livejournal.com]

SSD спасет человечество

[f-dv.livejournal.com]

А вы не майтесь фигнёй типа Total, VC, MC и Far. Вы сделайте простой cd и сp(mv/move/rm/del) и будет вам счастье. Хоть на in_memory_cool_FS и 40-ка ядерном хосте сканирование 500000 файлов таки займёт не мало времени. А потом ещё имя каждого из них при обработке показать вам. Это же логично. Чем вы думаете?

[devnu11.livejournal.com]

из консоли при mv значительно быстрее происходит, чем из mc/чегонибудьгуевое - отрисовка жутко тормозит процесс, вроде у ребе белнетмона был пост про видеокарту

попробовал переместить дерево портов (130 тыс файлов)
slayer # find /usr/portage -type f |wc -l
129364

сбросил файловый кэш:
slayer # echo 3 > /proc/sys/vm/drop_caches

с ext4 на reiser3, с обнуленным кешем:
slayer # time mv /usr/portage /home/
real 11m54.194s
user 0m1.896s
sys 0m55.675s

обратно, кеш не трогал:

slayer # time mv /home/portage /usr/

real 4m13.231s
user 0m1.211s
sys 0m30.927s