[performance] Регистрозависимые ФС vs Регистронезависимые ФС

Ага, вот что-то, а именно это и имеет ключевое влияние на производительность ФС.

Это шутка или серьезно?

Конвертировать нужно только при резолвинге имени в каталоге, не? Какую часть от всех операций это занимает, подумай.

по определению

По какому еще определению? Ты наверное хотел сказщать «при прочих равных»? Только нет прочих равных, все ФС устроены очень по-разному.

при резолвинге имени в каталоге

А при резолвинге имени каталога/каталогов? Если ФС, как, н-р, в маке, безразлична к регистру, то она должна конвертить ВСЕ, а не только имена файлов.

Я тебя наверное удивлю, но каталоги тоже находятся в каталогах.

А зачем, кстати, конвертировать регистр?

Нет, это влияет в пределах погрешности.

Я возьму эту умную мысль на вооружение.

ФС должна при каждом конвертировании path -> inode выполнять tolower(path). Неужто это никак не замедляет процесс? Но, по-видимому, с IO ничего не сравнится.

ФС должна при каждом конвертировании path -> inode выполнять tolower(path). Неужто это никак не замедляет процесс?

Там же есть кэш path -> inode. Конвертирование нужно только при первом проходе.

Тупл. Еще нам нужен кэш PaTh -> path. Тогда ок.

кэш PaTh -> path

Я не понимаю. Тогда придется разжиться кэшом на все случаи жизни:

PaTH->path
pAth->path
PATH->path
Path -> path
...

Зачем на все случаи жизни-то? Ты уверен, что понимаешь значение слова кэш?

И еще, насчёт PaTh -> path -> inode я дурь сморозил. Обычный PaTh -> inode. Если обращаются с разными вариантами регистра, ну закэширует несколько разных вариантов, ничего страшного.

Каким образом я выиграю с точки зрения производительности, если буду использовать кэш в *данной* конкретной ситуации?

Что быстрее - сделать tolower() или найти соответствие переданной строки pAtH в кэше?

Как организовать такой кэш, чтобы он был быстрее, чем простой tolower()?

1. Ты выигрываешь не только за счёт отсутствия tolower, но и за счёт непрохождения всей цепочки каталогов до инода.

2. http://en.wikipedia.org/wiki/Hash_table

2. Ты говоришь абстрактными понятиями. Что такое хэш и кэш я знаю хорошо. Каким должен быть хэш, чтобы кэш был обправдан?

А зачем, кстати, конвертировать регистр?

Чтобы хомячки на форумах не кричали о том, что у них PiNg не работает.

Этот вопрос стоит адресовать не мне, а разработчикам dcache.

Только нет прочих равных, все ФС устроены очень по-разному.

Макос при форматировании hfs+ позволяет выбрать, будет фс регистрозависимая или нет. Не знаю, что и где конкретно меняется от этого выбора, но он есть.

Не знаю, что и где конкретно меняется от этого выбора, но он есть.

Говорят, на регистрозависимой ФС фотошоп перестаёт работать.

Ага, и мс офис не ставится. Зато на регистронезависимой нельзя собрать android sdk :)

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

Кстати в тех андроидах, в которых /sdcard и / находятся физически в одном модуле памяти без деления на разделы, используется FUSE-костыль, который имитирует регистронезависимость и 777-права, тогда как в реальности это просто директория где-то в родной ext3/4/etc.

DOS в общем к славному зоопарку регистро(не)зависимости привёл.

ага, малыш
особенно на мелких файлах
жги дальше

На твоём десктопе ОС каждую секунду открывает и закрывает сотни мелких файлов? И операция приведения к одному регистру (выполняющаяся над данными в памяти) по времени сравнима с операцией произвольного доступа к данным на диске?

Или как мы меряем производительность?

А тем временем Development медленно скатывался в конференцию Денисок.

Я правильно понимаю, что файловые системы, которые не зависят от регистра букв, работают по определению медленнее ФС, имена в которых от регистра зависят?

да. Особенно если буквы многобайтовые (UTF-8). Хотя проявляется это только в некоторых случаях.

Кто тебе мешает привести буквы к единому регистру при создании/переименовывании файла?

Как доказательство моей правоты я рассматриваю Apple iOS FS, которая от регистра зависит, поскольку это, видимо, значительно влияет на производительность.

ну раз такое убедительно доказательство то не о чем спорить :)

Когда компьютеры были большими, корпоративные разрабы не боялись почему-то делать ФС case-preserving, case-insensitive, хотя у них не было двагигадваядра на телефонах.

Когда компьютеры были большими, корпоративные разрабы не боялись
почему-то делать ФС case-preserving, case-insensitive

Ты имеешь ввиду Microsoft?

Тащемта я имел в виду IBM.