Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Для Linux предложена новая ФС NOVA, спроектированная для [BR]N..., opennews (?), 06-Авг-17, (0) [смотреть все] Похоже скоро SSD диски тоже в прошлое уйдут, Нннн (?), 12:00 , 06-Авг-17, (1) +9 // нет, deadfood (ok), 12:19 , 06-Авг-17, (2) –3 // Всё когда-то уйдёт в прошлое Даже будущее , A.Stahl (ok), 12:25 , 06-Авг-17, (3) +37 // скоро , Xasd (ok), 13:56 , 06-Авг-17, (14) В будущем , A.Stahl (ok), 14:40 , 06-Авг-17, (22) +8 Будущего не существует Смиритесь , Дегенератор (?), 14:58 , 06-Авг-17, (28) Да, будущего не существует сейчас Нет его и в прошлом Но в будущем будет будущ, A.Stahl (ok), 15:04 , 06-Авг-17, (29) +4 Почитайте The Langoliers, может тогда поймете про что речь, это лучше чем строит, Аноним (-), 00:09 , 07-Авг-17, (91) –12 Всё относительно , Аноним (104), 09:49 , 07-Авг-17, (104) С каких это пор художественный вымысел стал истиной , Moomintroll (ok), 10:24 , 07-Авг-17, (105) +1 Примерно со времен написания архипелаг гулаг , Аноним (-), 10:57 , 07-Авг-17, (107) +1 Тогда я могу ссылаясь на MLP Time Loops утверждать, что заранее предопределён ст, Lain_13 (ok), 11:40 , 07-Авг-17, (111) А дискретность времени подозрительно напоминает отдельные тики , Аноним (-), 13:10 , 07-Авг-17, (122) Откуда дровишки Публикации ффстудию , Аноним (-), 00:37 , 01-Окт-17, (214) Хммм я попал на соревнования поставщиков ширева Чемпиону - пожизненное, ибо, _ (??), 17:10 , 08-Авг-17, (191) –1 Философов бесконечностей, хотя бы скажи какой завтра, после 11 00 будет курс фун, pavlinux (ok), 00:14 , 18-Авг-17, (209) –1 Это получается я могу создать раздел типа tmpfs с этой файловой системой и класт, Аноним (-), 12:33 , 06-Авг-17, (4) –2 // А скорость-то откуда возьмётся , A.Stahl (ok), 12:35 , 06-Авг-17, (6) // Строго говоря может даже и взяться так-как в описание чётко указывалось, что в N, Lain_13 (ok), 11:52 , 07-Авг-17, (112) +1 NVMDIMMNVMNon-volatileDIMMDual In-line Memory ModuleНе забудь купить модуль энер, Старый одмин (?), 12:55 , 06-Авг-17, (9) –1 Несколько смущает последний абзац Что происходит, если количество ядер в систем, Аноним (-), 12:35 , 06-Авг-17, (5) +2 // Видать придется монтировать Судя из последнего обзатца, я (?), 14:46 , 06-Авг-17, (24) –2 Вроде стало понятнее после оригинального описания Всё per-CPU распределятся р, Аноним (-), 12:42 , 06-Авг-17, (8) +1 // Ничего подобного, в контексте NOVA инициализация это запуск в режиме -o init , , Аноним (-), 14:47 , 06-Авг-17, (25) +2 В документации сказано обратное following items are currently missing Moving , Аноним (-), 15:05 , 06-Авг-17, (30) +4 Доколе мы будем влачить существование в прокрустовом ложе файлов и файловых сист, Аноним (-), 13:16 , 06-Авг-17, (11) –6 // Каковы Ваши предложения, мой анонимный друг , Какаянахренразница (ok), 14:23 , 06-Авг-17, (20) +3 // он хочет ОС Фантом , Вася1970 (?), 18:47 , 06-Авг-17, (57) +2 // Фантом слишком фантом, а мне надо ИРЛ, так что и ibm i не очень подходит, Аноним (-), 20:30 , 06-Авг-17, (65) –1 Действительно Даже если не упоминать всякие модные нынче нейросети, то реализац, Аноним (-), 23:08 , 06-Авг-17, (83) –2 // Чепуха Всё это не зря осталось академической игрушкой - на практике очень быстр, Crazy Alex (ok), 23:49 , 06-Авг-17, (89) // Мало того коллега, доступ к ОЗУ тоже не однороден и приходиться плясать с бубном, Аноним (-), 00:13 , 07-Авг-17, (92) Да, но одно дело отладить это на критичных участках, другое - вообще ничего не з, Crazy Alex (ok), 03:05 , 07-Авг-17, (98) Это о иерархии памяти вообще , Аноним (-), 14:32 , 07-Авг-17, (127) Хотите хранить объекты Шишкин с начальником Рейзером изначально в Reiser4 плани, Аноним (-), 10:40 , 07-Авг-17, (106) +1 // Да тьфу на вас AWS S3 и наслаждайтесь Только вот они тоже прокрустово ложе, _ (??), 17:18 , 08-Авг-17, (192) Круто F2FS никак до полностью рабочего состояния довести не могут, GRUB2 тормоз, Kuromi (?), 14:54 , 06-Авг-17, (26) –1 // Кладут Судя по удобству того что они натворили, то не штампуют, а кладут , A.Stahl (ok), 16:14 , 06-Авг-17, (42) +5 Инновационная btrfs тормозит в большинстве тестов Новая виндовая refs, убийца n, Аноним (-), 16:40 , 06-Авг-17, (45) –3 // А, как ранее MS пиарщики и незалежнi-тестировщики обзорщиками пиарили что NTFS б, Аноним (-), 17:38 , 06-Авг-17, (51) –5 Выберите два , Michael Shigorin (ok), 18:34 , 06-Авг-17, (54) –1 // Можно тогда пример хорошей фс быстрой со сжатием , Аноним (-), 19:17 , 06-Авг-17, (59) // reiser4 Но там свои тараканы В частности, образы виртуалок на неё лучше не к, Led (ok), 19:49 , 06-Авг-17, (60) +1 Кстати, много где такое слышал Вроде вызвано тем, что при восстановлении файлов, Аноним (-), 01:22 , 07-Авг-17, (96) Нет, там всё намного прозаичнее и проявляется только когда включена компрессия , Led (ok), 01:37 , 07-Авг-17, (97) Ну напишите уже кто-нить ioctl, чтобы помечать файлы как несжимаемые Попросите , me (??), 00:14 , 12-Авг-17, (202) Костыдь - за пару часов А по-хорошему - xattrs с поддержкой c , Led (ok), 00:17 , 12-Авг-17, (203) А почему xattrs с поддержкой c тогда не костыль, а всё остальное - костыль , me (??), 00:51 , 12-Авг-17, (204) Потому что xattrs уже есть в vfs и реализовано в ext234 btrfs xfs может ещё где, Led (ok), 00:58 , 12-Авг-17, (205) ZFS, XoRe (ok), 19:06 , 08-Авг-17, (200) –1 Спрашивали же хорошую и быструю, а не просто объект поклонения pussy exe шников , Led (ok), 23:43 , 08-Авг-17, (201) –2 А я и не про BSD, XoRe (ok), 16:36 , 27-Авг-17, (212) –1 NTFS и ZFS , Аноним (-), 19:59 , 06-Авг-17, (61) –3 NVM это по идее отказ от концепции файла, отход от принципа unix и новая ОС, а н, Вася1970 (?), 18:43 , 06-Авг-17, (55) –2 // Чего, блин И чем ты собрался заменить файл как именнованную сущность на постоян, Crazy Alex (ok), 18:48 , 06-Авг-17, (58)   // вообще-то может и поменяет, все будет в сжатых бинарниках приложения , а даныe в, анононк (?), 20:49 , 06-Авг-17, (69) –2   // И что поменяется Какая-нибудь XFS или Ext4 охренеть какая человекопонятная, есл, Crazy Alex (ok), 21:12 , 06-Авг-17, (71)   вместо данных в базах данных фс не будет файлов в виде байткодов, а будут адре, анононк (?), 21:43 , 06-Авг-17, (75) –3   Такое - существует давно и называется просто своп-файл или же ROM-образ прошив, Аноним (-), 22:23 , 06-Авг-17, (79) +3   Гораздо удобнее и удачнее хранить это дело таблицей с блобами, например, выделив, Отражение луны (ok), 21:50 , 06-Авг-17, (76) –2   Мне кажется, что это чересчур сильное утверждение Существуют примеры софта, кото, Ordu (ok), 18:12 , 08-Авг-17, (197)   // Идеи красивые К тому всё и идет, но Реальный софт личит, бакапится, и главное ап, rex (??), 23:54 , 15-Авг-17, (207)   Концепция файла вечна, не трогайте святое, дабы не позориться А если очередно, Kodir (ok), 18:29 , 07-Авг-17, (138) –2 // Файлов не существует, смирись Тебе, человеку-шаблону, надо всё разъяснять Есть, pavlinux (ok), 00:41 , 18-Авг-17, (211) Тронули давноhttps lsub org ls export box htmlhttps lsub org ls export 2kblo, Аноним (-), 00:34 , 01-Окт-17, (213) интересно, а есть ли уже комп и OS для него где функция ПЗУ и ОЗУ объединена в N, Baz (?), 20:12 , 06-Авг-17, (62) // The machine HP , Elly (?), 22:06 , 06-Авг-17, (78) // Разве проект ещё жив Вроде сворачивали же , A.Stahl (ok), 05:19 , 07-Авг-17, (99) А старые приложения смогут и дальше работать , Аноним (-), 23:15 , 06-Авг-17, (85) –1 Похоже EMC DSSD её уже давно использует хотя может что-то и своё, но подход схо, 111 (??), 08:11 , 07-Авг-17, (102) жесткие диски гарантируют атомарность записи сектора либо полностью запишется л, Аноним (-), 11:03 , 07-Авг-17, (108) // Оно то может и может, раз энерго-независимое, а вот куча ЦПУ кэшей Ну я пис, Аноним (-), 12:25 , 07-Авг-17, (117) Не знаю, как насчёт этого то, что пока продаётся - честно говоря, даже на опы, Crazy Alex (ok), 20:22 , 07-Авг-17, (139) Либо подтвердит запись, а на самом деле все оставит в кэше Или тупо поменяет оч, Аноним84701 (ok), 16:56 , 08-Авг-17, (190) HDD при отключении питания пишут за счёт энергии, генерируемой постепенно остана, xv (??), 13:22 , 14-Авг-17, (206) +2 Очень интересно, тоже хотелось бы ответ знать , ishida (ok), 16:29 , 16-Авг-17, (208) Прекрасно, нам пиво поставляют ящиками, а мы их открываем и разливаем по рюмкам , pavlinux (ok), 00:21 , 18-Авг-17, (210) 1,4,5,11,26,45,55,62,85,102,108,210

Сообщения

[Сортировка по времени | RSS]

	58. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	+/–
	Сообщение от Crazy Alex (ok), 06-Авг-17, 18:48
	Чего, блин? И чем ты собрался заменить файл как именнованную сущность на постоянном носителе? Они, если что, не для софта, а для людей - так всю эту гору байт можно хоть как-то организовать. И то, что в идеале оперативная и долговременная память объединятся - это вообще никак не поменяет.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	–2 +/–
	Сообщение от анононк (?), 06-Авг-17, 20:49
	вообще-то может и поменяет, все будет в сжатых бинарниках(приложения), а даныe в базах которая при исполнение тоже, мать его бинарник, вместо фалов будут сжатые человеконепонятные байткоды.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	+/–
	Сообщение от Crazy Alex (ok), 06-Авг-17, 21:12
	И что поменяется? Какая-нибудь XFS или Ext4 охренеть какая человекопонятная, если тупо бинарный формат смотреть. Встроенное хранилище в каком-то виде - хоть контейнерные форматы, хоть sqlite - на каждом шагу. А главное - это всё вполне неплохо свои задачи выолняет. Поэтому никаких изменений не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	–3 +/–
	Сообщение от анононк (?), 06-Авг-17, 21:43
	вместо данных в "базах данных фс" не будет файлов в виде байткодов, а будут адресса(в ввиде бфйткода которые хранят ссылки на части базы данных в которой хранится инфа в ввиде бинарников) и метаданные(и адресса на метаданные) для распаковки(инфы из сжатых бинарников) понятных для человека данных. Самого понятия "файловая система" не будет, будет что-то типа "система хранения информации в режимах ввод/вывод/временно/заблокированно/"вышло за пределы адрессного пространства"/..."
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	+3 +/–
	Сообщение от Аноним (-), 06-Авг-17, 22:23
	> Самого понятия "файловая система" не будет, будет что-то типа "система хранения информации в режимах ввод/вывод/временно/заблокированно/"вышло за пределы адрессного пространства"/..." Такое - существует давно и называется просто: своп-файл (или же ROM-образ/прошивка, а более широко: и ISO Образ). Даже в один файл на всё - всёравно даже при отсутствии возможности создания подфайлов - вынужденно запихнут 100-5000-100000 подфайлов в какомнибудь незапаконном ZIP формате как это было в .PAK ф-лах, даже и без поддержки самих ф-лв ОСью - прямо в исходном коде. Людей не надурить ноухау перделками. > вместо данных в "базах данных фс" не будет файлов в виде байткодов, а будут адресса(в ввиде бфйткода которые хранят ссылки на части базы данных в которой хранится инфа в ввиде бинарников) и метаданные(и адресса на метаданные) для распаковки(инфы из сжатых бинарников) понятных для человека данных. Это и называется файловая система....
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	–2 +/–
	Сообщение от Отражение луны (ok), 06-Авг-17, 21:50
	Гораздо удобнее и удачнее хранить это дело таблицей с блобами, например, выделив контейнер с "файлами" в отдельный процесс. Тебе попросту не нужна бесполезная сущность в виде фс. Но говорить об этом еще рано, т.к. действительно - все это требует радикально другого подхода в программировании и построении ОС. Скорее всего будем тянуть легаси еще лет 20 после повсеместного распространения технологии.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	197. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	+/–
	Сообщение от Ordu (ok), 08-Авг-17, 18:12
	> И то, что в идеале оперативная и долговременная память объединятся - это вообще никак не поменяет. Мне кажется, что это чересчур сильное утверждение. Существуют примеры софта, который инкапсулирует фс и файлы, и общается с пользователем в иных терминах. Взять тот же calibre. Общение с calibre идёт в терминах отдельных книг, но не файлов. calibre где-то там хранит у себя книги, и делает это в виде файлов, но те файлики где-то лежат, и в каком виде они лежат, где именно -- это уже не те вопросы, которые волнуют пользователя. Если бы адресное пространство Calibre целиком бы мапилось на NVRAM, то он бы мог не создавать никаких файлов, а непосредственно хранить все книги в ОЗУ в представлении заточенном на RAM. Можно ещё для примера взять браузерный кеш. Там, с точки зрения человека, очень неудобно используется fs, куча файликов с непонятными именами, и маппинг url -> имя файла выполняется через sql. Тут опять же fs полностью инкапсулирована, и весь этот кеш можно было бы хранить в RAM формате в адресном пространстве, не заморачиваясь на обеспечение способности скидывать содержимое RAM на диск в виде sql и кучи файлов. Это лишь два примера, которые пришли мне в голову. И оба этих примера, в сегодняшнем исполнении, имеют как RAM представление хранилища, так и дисковое представление заточенное на хранение в файлах на блочном устройстве. В обоих этих примерах можно было бы выкинуть кучу кода связанного с реализацией обратимого отображения RAM представления в дисковое представление. То есть, файловая система как хранилище данных легко может уйти в прошлое. Проблемы с избавлением системы от файлов начнутся в тех случаях, когда файлы используются как своего рода IPC. Скажем, /usr/src/linux хранит кучу файлов, которые используются не только как хранилище информации, но и способ передачи этой информации от одного приложения другому. make, gcc, git, текстовый редактор -- они посредством файлов передают информацию друг-другу. И вот такое использование файлов будет сложно заменить чем-то ещё. Можно, но это потребует изобретения какого-то нового способа прокидывать информацию между приложениями, и может быть этот способ даже будет лучше чем фс, но зато он будет менее универсальным. А это значит что либо придётся изобретать не просто так способ, но универсальный способ, либо для каждого подобного случая изобретать новый велосипед. С другой стороны, есть же fuse... Да! Глянь. Фантазируя чисто гипотетически. Возьмём git, перепишем его под использование nvram, так чтобы для каждого git-репозитория мы бы запускали отдельный процесс, и всё содержимое этого репозитория хранилось бы в адресном пространстве этого процесса. Там всё равно всплывёт понятие файла, но оно не будет привязано к ограничениям блочных устройств и при этом оно будет заточено под задачи git. Теперь, git регистрирует fuse файловую систему как чистой воды IPC, и всякие там текстовые редакторы, make, gcc и прочие бизоны общаются с git через fuse-интерфейс. А если ещё каким-нибудь образом научить этот fuse интерфейс переключать контексты при вызовах open/read/write не через ядро, а непосредственно между процессами, чтобы каждый такой "сисколл" приводил бы к _двум_ переключениям контекста -- туда и обратно, -- а не к четырём: клиентский процесс -> ядро -> fuse-процесс -> ядро -> клиентский процесс... Если как-то извернуться таким образом, то это будет даже не медленнее чем при использовании ядерной фс, а скорее всего даже быстрее, потому что данные организованы не в фс, которая заточена на общий случай, а специальным образом заточенным именно на данный класс use-case'ов. Ядерная фс прекращает существовать. Вместо /etc мы запускаем etcd. Вместо /bin, /sbin/ /lib и прочих, мы запускаем ldd. Вместо /home/user мы запускаем DE и разнообразные софтины на разные случаи жизни. Правда напрашиваются проблемы с бекапами. Если плазма упадёт, то будут утеряно всё то, что пришло на замену /home/user.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	207. "Для Linux предложена новая ФС NOVA, спроектированная для NVM..."	+/–
	Сообщение от rex (??), 15-Авг-17, 23:54
	Идеи красивые. К тому всё и идет, но: Реальный софт личит, бакапится, и главное апгрейдится. Поэтому всё равно нужны 2 представления невременных данных: для рантайма и для переноса в следующий рантайма. Соответственно выкинуть кучу кода для преобразования между представлениям не выйдет. Выкинуть можно маленькую кучку, завязанную именно на фс. Прикладной софт уже в основном работает через базу/библотеку, т. к. хочет транзакции и индексы. Соответственно эта кучка расположена в глубине системных библотек. Авторы этих системных библотек смогут что-то выкинуть и как-то соптимизировать рантайм. Но с точки зрения остальных -- сильных изменений не видно.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема