- 1
FileInfo[] files = dir.GetFiles().Where(i=>i.Name.EndsWith(".png") || i.Name.EndsWith(".ico")).ToArray();-
C# / Говнокод #19406
−14
Запостил:
d_fomenok,
05 Февраля 2016
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
я все еще помню кошмары когда винды имена файлов которые случайно соответствовали 8.3 формату автоматом апперкейсила. (потому что в файловой системе в ДОС формате directory entry даже на NTFS создавалась.) прога создала файл - а потом его найти не может, потому что забыли case-insensitive сравнение префикса/суффикса делать. один разраб в отчаинии на дедлайне в имена файлов пробелы даже вставлял, что бы предотвратить эту ДОСнутую магию.
Пример обратного: допустим мы смонтировали NFS систему локально, и, допустим наш клиент и сервер умеют пересылать глобы. В таком случае мы не потратим время на пересылку данных, которые можно было отфильтровать уже на сервере.
Мейнфреймы это IBM и совсем не юнихи.
> Файловых систем реализующих Юникс десятки, если не сотни.
Намного меньше. Большинство файловых систем были тупо содраны с BSD'шной реализации, aka UFS.
> Как-то мне слабо верится что во всех такая операция будет столько же времени занимать.
Я и не говорил что на всех систем столько же времени занимает.
> Пример обратного: допустим мы смонтировали NFS систему локально, и, допустим наш клиент и сервер умеют пересылать глобы.
Не умеет.
VFS (virtual file system) интерфейс в кернелах почти везде одинаковый и крутится во круг базовых системных вызовов (open/pread/pwrite/close/opendir/readdir/closedir). NFSы реализуются на основе VFS и дополнительных функций физически предоставить не способны.
а glob() и wordexp() вечно были и навсегда останутся примочками из libc.
> В таком случае мы не потратим время на пересылку данных, которые можно было отфильтровать уже на сервере.
Но все равно каталог надо будет читать полностью, где бы ты его не читал: клиент или сервер. Сетка по сравнению с винтом все еще быстрее.
Ну здесь можно возразить тем, что разгон до топовой скорости у tcp/ip не мгновенный, да и вообще, емнип, недостижим на дефолтном карликовом окне...
И что... IBM разрабатывали и разрабатывают ПО для мейнфреймов, в том числе файловые системы, в том числе и такие, которые реализуют Юникс стандарты (более того, последние - как бы самые популярные).
Откуда инфа про меньше? Есть куча проприетарных систем установленых в датацентрах и т.п. местах, куда только по пропускам. И про "содраны" - это очень смелое заявление. Да, есть популярная книжка, которая использует UFS для иллюстрации того как в принципе можно реализовать файловую систему, но это как бы ничего особо не значит. Ну, к примеру, взять тот же Докер, где они сами написали две файловые системы, совсем не похожие на UFS. Да и вообще, цимес современных файловых систем не в том, как определить структуры данных для файлов и каталогов - это < 1% от всей работы. Интересные проблемы: кластеринг, кеширование, "хотсвоп" и т.п.
Откуда уверенность в том, что NFS не умеет? Я вот на днях к нашему NFS клиенту прикрутил оптимизированое рекурсивное удаление директорий. Если бы было нужно, то и глоб тоже бы прикрутил.
Сетка может быть быстрее флешек, иногда. Но есть очень много уровней перенаправления. На самом деле выиграет тот, кто первый закеширует.
Рынок на столько мелкий что только Veritas какие-то деньги на этом и зарабатывает. Все остальные двигаются в направлении distributed block device.
И бывал я в тех датацентрах в которые только по пропускам... Шумно и холодно.
> И про "содраны" - это очень смелое заявление.
Не просто содраны. Еще лет 10 назад они все еще UFS и назывались. У БСД была своя UFS. У HP-UX была своя. На AIX, SunOS, Solaris, SCO - у всех была "Unix File System" которые слегка с друг-другом были не совместимы.
> Откуда уверенность в том, что NFS не умеет?
Потому что (1) (еще раз) кернелы этого не умеют (glob == userspace), и (2) https://www.ietf.org/rfc/rfc3530.txt
Что касается UFS, то можно это воспринимать как набор свойств файлов и каталогов, т.е. определенный список аттрибутов, привилегий и т.д. А можно воспринимать как отсылку к конкретной реализации, например, описаной в книжке Practical Filesystem Design, на примере BFS. Но в любом случае, речь о том, что то, что общее у этих файловых систем - это тривиально в написании, и не занимает даже 1% от всего кода реализующего ту или другую систему. Разница же в стратегиях чтения-записи, в том реализуется ли система на аппаратном уровне или на уровне приложения, в том как реализованы дефрагментация, логгирование, восстановление, кластеринг, в том, как построить кеширование в зависимости от аппаратной части, и т.д.
Сказать что все файловые системы содраны с UFS потому что в них есть одинаковые аттрибуты у файлов, это как сказать что все програмы содраны с интернет эксплорер 5 потому что в них использованы функции конвертации строк в числа.
Ну и что, что ты системщик? А я вот работаю в компании, которая разрабатывает файловую систему для тех самых датацентров, куда только по пропускам. Мне больше всего довелось разбираться с AUFS докеровской, но я так же немножко знаю и про Btrfs и про XFS. Ну и конечно, про NFS, т.как с этим работаю каждый день.
и куда по твоему уходят сисколлы open()/read() и т.д.?
> Мне больше всего довелось разбираться с AUFS докеровской
8 лет траханий с веритасом. шутка: работает на ура, но стоит столько бабла что никто не покупает, а пользуются NFS. c которым и трахался.
> Сказать что все файловые системы содраны с UFS
мля, да не говорил я этого!
я не уверен что вы на самом деле там "файловую систему" делаете - а не какой очередной "object storage".
Если не веришь - возьми тестовые фреймворки типа SFS2008, SFS2014 или Vdbench - они все пользуются NFS клиентом написаным на Яве, и работают с файловой системой без участия кернела.
> Я не уверен ...
Лол
*facepalm* I weep for your data.
> > Я не уверен ...
> Лол
не ну теперь я точно уверен что это и не файловые системы и не NFS.
Потому что приложения доступаются к файловой системе через ядро.
Потому что кернел это единая точка синхронизации доступа между приложениями.
> Взять ту же fuse
bandwidth хороший, но тормозит на meta data.
> от ядра только посекторное i/o или сокеты понадобятся.
fuse никогда не обгонит ядро из-за overhead'а контекст свитчей. вот такой простой ответ.
и так файловые системы меняются редко, то просто смысла в fuse для больших проектов мало.
object storage по крайней мере решают проблему.
Чтение с диска (даже ссд) уже стало быстрее, чем переключение контекста?
скорее всего context-switch быстрее. хваленые 100К IOPs без глубоких очередей не достигнешь. глубокие очереди == большие задержки. ожидание ответа/стояние в очереди + обработка прерываний == навярняка медленее чем контекст свитч.
ЗЫ там где я работал, SSD было слишком дорогим удовольствием. стораджы нужны нехилых размеров, а 1TB SLC SSD стоит 2-4 килобакса. максимум где использовался это для лога (log, journal) транзакций на оракаклевых серваках.
Есть много вариантов это реализовать. По-сути базы данных это делали всегда, в каком-то смысле. Такой вариант как с базами данных можно реализовать за счет создания loopback device, который будет выступать в качестве block device для следующего уровня файловой системы с одной стороны, и как обычный файл - для кернела. Производительность будет зависеть от конкретной файловой системы обеспечивающей этот самый loopback device.
Ну вот сходи на сайт к Ораклю и почитай про Vdbench, зачем он существует и кто им пользуется. Ты ж этого не сделал, а вместо этого авторитетно пернул в лужу...
Я работал 8 лет на стратегического партнера Оракла (Эрикссон). Я это шарашку из нутри знаю. А ты мне тут байки по мотивам рекламных материалов расказываешь...
> и почитай про Vdbench
он умеет сбои электичества симулировать? или битую сеть? битую память?
а да. это был SuperDome сервак. там вроде есть отличия как ECC работает на разных типах серваков.
При чем тут реклама - я не в курсе. Речь до сих пор была о том, что NFS клиент и сервер можно реализовать без того, чтобы он работал с кернелом. Ровно точно так же, как, например, FTP. Перед тобой конкретная реализация. Плохая она или хорошая - не мне судить. Но она же существует.
Да можно. А толку, если для того что бы этим могло пользоватся пользовательское приложение либо (1) его надо переписывать что бы работало с другим интерфейсом или (2) прокладку в ядре делать (типа fuse).
"Плохая она или хорошая [...]"
Слово: "бесполезная".
Ты работаешь с object storage. Это другая пестня и для других целей. Сравнивать с файловыми системами просто не имеет смысла. Интерфейс как у файловой системе для object storage это просто побочный опциональный бонус, не более. Заменой файловой системы это не является.
Как некто кто работал долго с Veritas я тебе могу так же объяснить почему народ толкает object storage: потому что лицензия на Veritas CFS стоит просто охренительных денег. Мало кому нужны все фичи - народ просто хочет нечто надежнее чем NFS, и дешевле чем "правильная" CFS.
Где это, например, не понадобится: при работе с технологиями виртуализации типа Докера.
Но это же не обязательное условие. Точно так же можно например смонтировать файловую систему и через FTP, и при этом FTP можно использовать без того, чтобы вовлекать в процесс ядро.
С чего ты вообще взял обжект сторидж... Ну и конечно, ты ж иксперт и в курсе про полезность или бесполезность бенчамарк тестов, о которых узнал полчаса назад.
Никакой это нe обжект сторидж. Это файловая система для датацентров VMWare, где нужно больше возможностей по управлению ресурсами и более быстрые сетевые протоколы.