.

QUOTE (dura @ Dec 8 2006, 01:01)

то есть вы действительно считаете что ядро/файлуха к разрядности процессора не имеет отношения ?!! вы прицепились к словам по-наитию-интуитивно

Реализация файлухи имеет отношение к разрядности. К преимуществам архитектуры такая "простота" - не имеет, поскольку 32-разрядная не накладывает никаких существенных ограничений. Тем более что неясно - каким образом изменение разрядности регистров приведет к изменениям непосредственно в файлушке? Аккуратно переписывать все одно придется, как не противно. Причем - сохраняя совместимость.

 

ЗЫ. Я же считаю, что файловые системы, как странные разновидности баз данных - в будущем совсем отомрут.

QUOTE (String @ Dec 8 2006, 00:56)

ЗЫ. Я же считаю, что файловые системы, как странные разновидности баз данных - в будущем совсем отомрут.

А вместе с ними жесткие диски, компъютеры и их пользователи https://academ.club/html/emoticons/supdup.gif

QUOTE (den @ Dec 8 2006, 08:29)

QUOTE (String @ Dec 8 2006, 00:56) ЗЫ. Я же считаю, что файловые системы, как странные разновидности баз данных - в будущем совсем отомрут. А вместе с ними жесткие диски, компъютеры и их пользователи https://academ.club/html/emoticons/supdup.gif Сомневаетесь? https://academ.club/html/emoticons/cool.gif   Функционально нормальная база данных покрывает файловую систему полностью. И даже много больше и гораздо эффективней. Уже сейчас многие интернет-магазины держат библиотеки картинок именно в базе, а не файлах. Медленно работает при больших числах.   Да и нужно ли пользователю показывать любую именованную цепочку байтов на диске? Не нужно ли показывать пользователю лишь то, что ему действительно нужно - каталог документов (точнее, объектов), а уж как они физически хранятся на диске, кому какое дело? (И еще, не удержался, -описывать структуру файла кусочком имени, это как? Не смешно ли? И пр., и др.)   А если учесть, что в ОС есть масса других специализированных баз (реестр, домен, Active directory) - то лучше включить в ОС одну нормальную БД, и надстраивать необходимые пользователям службы уже над ней, сверху. Что собственно и означает конец файлушке.

QUOTE (String @ Dec 9 2006, 11:39)

А если учесть, что в ОС есть масса других специализированных баз (реестр, домен, Active directory) - то лучше включить в ОС одну нормальную БД, и надстраивать необходимые пользователям службы уже над ней, сверху. Что собственно и означает конец файлушке.

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

Кстати, вышеперечисленные встроеные в систему БД имхо не являются примерами хорошего системного решения. И не дай бог, чтобы эту технологию Microsoft придумала - а то будет у народа винчестер как виндовый реестр https://academ.club/html/emoticons/blink.gif

Эту технологию Microsoft хотела встроить в Висту(тогда ещё единорога)

Но кажется почему-то не встроила. https://academ.club/html/emoticons/wink.gif

Изменено 9 декабря, 200619 г. пользователем Гость

QUOTE (String @ Dec 9 2006, 11:39)

А если учесть, что в ОС есть масса других специализированных баз (реестр, домен, Active directory) - то лучше включить в ОС одну нормальную БД, и надстраивать необходимые пользователям службы уже над ней, сверху. Что собственно и означает конец файлушке.

называется vendor lock-in. в этой базе можно будет сделать только то, что предусмотрел (в вашем случае) Microsoft. Как только потребуеться что-то более-менее сложное --- придется ставить еще одну базу. Ну и чем это хорошо?

QUOTE (Tonal @ Dec 9 2006, 13:35)

Эту технологию Microsoft хотела встроить в Висту(тогда ещё единорога) Но кажется почему-то не встроила. https://academ.club/html/emoticons/wink.gif

И слава яйцам!

 

 

QUOTE (String @ Dec 9 2006, 11:39)

QUOTE (den @ Dec 8 2006, 08:29) QUOTE (String @ Dec 8 2006, 00:56) ЗЫ. Я же считаю, что файловые системы, как странные разновидности баз данных - в будущем совсем отомрут. А вместе с ними жесткие диски, компъютеры и их пользователи https://academ.club/html/emoticons/supdup.gif Сомневаетесь? https://academ.club/html/emoticons/cool.gif   Функционально нормальная база данных покрывает файловую систему полностью. И даже много больше и гораздо эффективней. Уже сейчас многие интернет-магазины держат библиотеки картинок именно в базе, а не файлах. Медленно работает при больших числах.   Да и нужно ли пользователю показывать любую именованную цепочку байтов на диске? Не нужно ли показывать пользователю лишь то, что ему действительно нужно - каталог документов (точнее, объектов), а уж как они физически хранятся на диске, кому какое дело? (И еще, не удержался, -описывать структуру файла кусочком имени, это как? Не смешно ли? И пр., и др.)   А если учесть, что в ОС есть масса других специализированных баз (реестр, домен, Active directory) - то лучше включить в ОС одну нормальную БД, и надстраивать необходимые пользователям службы уже над ней, сверху. Что собственно и означает конец файлушке. Да не, я не сомневаюсь, что БД функционально лучше. Проблема в том, что эта надстройка неизбежно принесет существенное падение производительности, а это означает, что БД не смогут *заменить* ФС, хотя вероятно и выкроят себе нишу. Нечто похожее произошло с микроядерными ОС: они так и не смогли заменить монолитные, хотя многие весьма умные люди это предсказывали.

QUOTE (Gesser, The Cat @ Dec 9 2006, 12:44)

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

Некоторые базы данных умеют размещаться на raw devices, т.е. самостоятельно управлять выделением блоков на диске. Так что в этом отношении препятствий нет.

QUOTE (den @ Dec 10 2006, 04:26)

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

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

QUOTE (String @ Dec 10 2006, 13:59)

QUOTE (den @ Dec 10 2006, 04:26) Да не, я не сомневаюсь, что БД функционально лучше. Проблема в том, что эта надстройка неизбежно принесет существенное падение производительности, а это означает, что БД не смогут *заменить* ФС, хотя вероятно и выкроят себе нишу. Никакого падения производительности не будет, наоборот, будет существенный ее рост. Поясните пожалуйста эту мысль. С чего оно быстрее станет?

QUOTE (String @ Dec 10 2006, 10:59)

QUOTE (den @ Dec 10 2006, 04:26) Да не, я не сомневаюсь, что БД функционально лучше. Проблема в том, что эта надстройка неизбежно принесет существенное падение производительности, а это означает, что БД не смогут *заменить* ФС, хотя вероятно и выкроят себе нишу. Никакого падения производительности не будет, наоборот, будет существенный ее рост. Там есть другая беда - существенный рост потребления памяти. Что это потребует пару дополнительных сотен метров - к бабке не ходи... мой вывод - в будущем (ближайшем) это вполне приемлемо.   Как вам не покажется странным, но сейчас наметилась обратная тенденция в хранении особо больших данных - уходить с СУБД на файловую систему https://academ.club/html/emoticons/smile.gif Так как использование СУБД во многих случаях себя не оправдывает.   Чтобы зарания погасить спор, вот очень показательная маркетингова статья - люди активно двигают альтернативные системы.

Изменено 11 декабря, 200619 г. пользователем Гость

QUOTE (busa @ Dec 9 2006, 10:48)

QUOTE (String @ Dec 9 2006, 11:39) А если учесть, что в ОС есть масса других специализированных баз (реестр, домен, Active directory) - то лучше включить в ОС одну нормальную БД, и надстраивать необходимые пользователям службы уже над ней, сверху. Что собственно и означает конец файлушке. называется vendor lock-in. в этой базе можно будет сделать только то, что предусмотрел (в вашем случае) Microsoft. Как только потребуеться что-то более-менее сложное --- придется ставить еще одну базу. Ну и чем это хорошо? Ну тут не все так страшно ;) в конце конце-концов и на обычной файловой системе все упирается в несколько системных вызовов: open(2),read(2), write(2), fcntl(2), close(2), link(2), mknod(2), stat(2), umask(2), unlink(2), если их промапить на SQL, то и не заметишь разницы.

QUOTE (Ezhi @ Dec 11 2006, 19:17)

Ну тут не все так страшно ;) в конце конце-концов и на обычной файловой системе все упирается в несколько системных вызовов: open(2),read(2), write(2), fcntl(2), close(2), link(2), mknod(2), stat(2), umask(2), unlink(2), если их промапить на SQL, то и не заметишь разницы.

Вы упустили один маахонький вызов, который как раз все меняет: mmap(2) ;)

 

PS. Немножко промахнулся с контекстом: меняет не в смысле vendor lock-in, а в смысле производительности.

Изменено 11 декабря, 200619 г. пользователем Гость

QUOTE (den @ Dec 11 2006, 03:49)

QUOTE (String @ Dec 10 2006, 13:59) Никакого падения производительности  не будет, наоборот, будет существенный ее рост. Поясните пожалуйста эту мысль. С чего оно быстрее станет? 1. Производительность никогда не была чем-то значимым в файловых системах. Надежность, низкая избыточность - да. Открыть около тысячи файлов в день (обычная история для файлушки) - ну не требуется тут особой производительности. https://academ.club/html/emoticons/cool.gif 2. Производительность БД - чуть ли не единственный критерий ее характеристики. Как мин - один из важнейших. Последние десятилетия шла жесткая конкуренция между коммерческими БД именно по этому критерию. В полном отличии от консервативных файловых систем, для которых надежность и предсказуемость была гораздо важней. Честно говоря, меня, как практика, этот вопрос просто в тупик поставил - чего сравнивать несравнимое? https://academ.club/html/emoticons/cool.gif 3. Существование у БД специальных средств, таких как индексирование и полнотекстовое индексирование позволяют резко ускорить поиск файла . В понятном отличии от рекурсивного поиска в директориях. 4. Есть большая масса файлов, например, конфигурационные текстовые файлы, логи и многие другие, - для которых не требуется чтение всего файла в программе, но необходима формальная выборка - скорость поднимется за счет уменьшения объема чтения. Это будет более характерно для систем юнискоидного семейства - там нет общесистемного подобия виндового реестра, очень полезного костыля для ряда задач. 5.В целом - увеличение производительности не есть какая-то специально преследуемая цель, более значимо принципиальное изменение систем навигации к файлу. Что более соотвествует логике людей, с трудом понимающих чужую логику. Единственный путь к файлу, например, уже сейчас не используется в айподах.