The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Код Bcachefs принят в основной состав ядра Linux 6.7"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Код Bcachefs принят в основной состав ядра Linux 6.7" +/
Сообщение от Аноним (-), 12-Ноя-23, 20:36 
> почему бы и нет, ок, принято. Зачем вообще нужна ОС если есть ФС - лол, кек.

И такое бывает, в фирмварях МК например. ФС есть, а ОС - нет. ФС ессно либо что-то простое типа фат либо специализированная/урезанная.

>> General purpose означает что ФС
> нету этого general purpose формального, никто его не описывал.

Это сложно описать. Но...

> Определитесь!!!

Я и определился: хочу реюз знаний и технологий. И чем в больше сценариев та или иная технология вписывается и масштабируется - тем больше поводов ее освоить. В этом смысле Linux стоил времени потраченного на него. Чем больше моих сценариев покроет тот или иной его компонент, тем я в нем более заинтересован.

>> Специализированные железки это антипод general purpose.
> то есть вы хотите сказать, что линукса на серверах меньше чем на ноутах?

Вполне возможно. У него несколько процентов довольно массового рынка. А уж на бытовухе типа TV, роутеров, и тому подобного - он в каждом доме. А если ведроидов всяких посчитать...

> Учитывая еще тенденцию что линукс на серверах "bare metal" давным
> давно уже не стоит.

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

У меня и у самого так виртуалок - есть. А прям на моих десктопах, ноутах и прочих ресурсах.

>> 1) Драйвер не знает о других устройствах и их состоянии, BigPic не
>> его прерогатива.
> ФС должна знать?

Как минимум - может. И как один из вариантов - на мой вкус весьма прилично работает. Лучше чем то что было до этого имхо. Полностью декорелированые абстракции ФС-блокдев теряют море сведений о проблемах друг друга и становятся неуклюжими и сложными в менеджменте. Так что я считаю дизайны типа btrfs шагом вперед. И не только я. Сабж по мотивам btrfs. С устранением выявившихся слабых мест. А заодно т.к. это автор bcache - с прикольно придуманой логикой кеширования, когда с избыточностью скрещено. Судя по числу юзеров с трупами перед которыми bcache был - интегрировать эту штуку в ФС и явно учитывать избыточность - выглядит хорошей идеей, будет менее неуклюжим чем такие этажерки.

> Если бы в ОС была одна единая ФС, то может ОС автоматом
> любое блочное устройство отображало бы в ФС, и не нужны были
> бы всякие форматирования и танцы с бубном,

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

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

Как говорится, все равны - но некоторые равнее. Скажем удачи в same extent ioctl на "произвольной" ФС. Или clone file. А знаете, так то круто сделать клон образа 3Тб диска за 1 секунду. Удобно при data recovery. Или флот виртуалок с дисками по 20 гигз поднять в момент.

ИМХО у нас очень разные масштабы задач и предпочтения. Я давно вырос из "хомяка" с "маздайкой", поработал в транснациональных корпах, и нашел ряд их подходов эффективными. И хотя я более не они, ряд моих сценариев имеет что-то общее с их подходами. И одна из фич - я менеджу мои компы на манер виртуалок. Снапшоты ФС это позволяют.

> открой файл, запиши, закрой. Как будет организовано хранение файлов это уже
> дело ФС. И ОС до лампочки.

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

У меня нет таймингов "переставлял систему полдня". И виртуалки я могу раскатывать шустро. И даже набирать с ноля образа систем за весьма обозримое время. ИМХО я давно превзошел все уровни технологий которыми вы ворочали.

>> ФС виднее что используется а что нет.
> ФС разве будет знать для чего в ОС используется файл /etc/passwd ?

Нет. Зато ФС знает что тот или иной файл снесли и блоки можно очистить в момент сноса файла.

> О файлах знает только конечная пользовательская программа.

Зато о аллокации оных, продвинутостях типа мульти-референса экстентов, когда и что (не)нужно и проч, и даже нельзя ли утянуть не прочитавшийся регион с вон того другого девайса  - ФС виднее. Блочный же уровень ничего про это не знает сам по себе. Это делает его неуклюжим и дурным в ряде аспектов без вон той интеграции.

> а чем копия файла отличается от копии блока данных и т.д.? уровнем абстракции?

Блочный уровень без явного знания что это и зачем - сильно менее эффективен в данных операциях. Можно делать снапшоты и на блочном уровне. Но получится тормозное УГ которое дельту отращивает с немеряной скоростью, времена операций и нагрузка на диски так себе, места жрет больше. CoW файлухи - делают все то же самое, только лучше. Там всегда есть все что надо для снапшота, снапшот сводится к весьма небольшой пометке что вон то теперь с более чем 1 референсом и сносить эти экстенты нельзя. Поэтому он мелкий, легкий, шустрый, в случае btrfs сразу в структуре ФС виден, а стереть снапшот (subvolume) можно даже миднайтом каким, снос "диры" которая subvolume с неких пор 100% эквивалентен "btrfs sub del". Так что можно менеджить снапшоты прямо привычным миднайтом или чем там, если хочется.

Более того writeable снапшоты позволяют это подорихтовать, скажем, если я знаю что старое состояние было ок, но там был некий баг, чтобы не наступать на него при каждом откате. Или даже так можно наделать из своей системы образов и сделать send. И вот... я уже болтаю с вами. Только это вообще-то виртуалка. И в ней - мой десктоп. Один из. У меня целая пачка VM берущих начало как мой хардварный десктоп. А потом они fork()нулись и их пути разошлись. Зачем так? Такой "инсталл оси" в виртуалку занимает 2 минуты и подымает мне привычное окружение. Ну что, пилот этажерки, рассказал капитану звездолета как тяги правильно дергать?

> санкции говорят об обратном, всегда надо хранить на складе горячий резерв :)

Я всем этим заниматься не собираюсь. Потому что не склад жестких дисков, это не бесплатно и создает неудобства. Поэтому я предпочитаю менеджмент ОС когда можно подцепить то что есть по мере надобности. Без делания мозга. И динамически реаллоцировать ресурсы на задачу.

>> Надо - собираем в молоток. Изменились требования, станет микроскоп. И так далее.
> Вот когда "надо", оказывается всегда, что поздно.

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Код Bcachefs принят в основной состав ядра Linux 6.7, opennews, 31-Окт-23, 07:41  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру