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

"Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от opennews (??), 31-Окт-23, 07:41
Линус Торвальдс утвердил запрос на включение файловой системы Bcachefs в основной состав ядра Linux и добавил реализацию Bcachefs в репозиторий, в котором развивается ветка ядра 6.7, релиз которой ожидается в начале января. Добавленный в ядро патч  включает около 95 тысяч строк кода. Проект уже более 10 лет развивает Кент Оверстрит (Kent Overstreet), который также разработал входящую в состав ядра  систему кэширования блочных устройств на SSD-накопителях BCache... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60021
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (1), 31-Окт-23, 07:41
дедупликации нет?
Ответить | Правка | Наверх | Cообщить модератору

	5. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (5), 31-Окт-23, 07:53
	Прозрачная скажется на производительности и даст порядка 10% экономии места, если не баловаться кучей виртуалочек с одинаковыми образами.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (1), 31-Окт-23, 09:18
	Кто спрашивал про прозрачную?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (5), 31-Окт-23, 10:03
	Тот, кто тебе мешает написать оффлайн-дедупликатор.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от OpenEcho (?), 31-Окт-23, 12:21
	> кто тебе мешает написать оффлайн-дедупликатор. Зачем отдельный офлайн дедупликатор если он уже включен в бэкап системах (kopia, restic...)
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (96), 31-Окт-23, 12:38
	> Зачем отдельный офлайн дедупликатор если он уже включен в бэкап системах (kopia, restic...) Ващет для файлух логично смотреть на bees, jdupes, duperemove, ... - там это есть именно в том виде каком оно в файлухах будет. У линя более-менее устаканился интерфейс "same extent" для софта, когда файлухе можно через IOCTL показать что мы считаем что вот этот и вот этот экстент - дубли. Изначально это в btrfs было, но это кажется и к XFS приделали уже, а вроде и в ZFS последней версии. А уж сабжу просто доктор прописал - вопрос только в том накодили ли это в том коде который в майнлайн приехал (там довольно много разных подветок на грани мержа развелось) и если да то в каком это все состоянии. Учитывая что экспериментальный код брякнулся даже в еще не -rc1, даже ответ на этот вопрос получить не совсем просто, надо сорц от и до читать а он здоровый.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (227), 01-Ноя-23, 05:34
	в xfs есть рефлинк да но дедупить её невозможно , потому что переменный размер экстента.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (235), 01-Ноя-23, 06:37
	> в xfs есть рефлинк да > но дедупить её невозможно , потому что переменный размер экстента. Ну там вообще дизайн для этого всего неудобен, то что рефлинк сделали - уже за чудо. А майнтайнер XFS так то молоток, стратежно с проекта слился, перед сабжем, видимо, прикинув перспективы :) Однако у btrfs так то экстенты тоже переменного размера. При этом дедупы позволяют выбирать размер блока который они оценивают на предмет дупа и совсем мельчить не рекомендуется т.к. сильно мелкие экстентики по скажем 4 кило - много оверхеда в метаданные дают. И в принципе можно дедупать даже файл сам на себя. Кому интересно как это на самом деле работает: man ioctl_ficlone man ioctl_ficlonerange man ioctl_fideduperange Вывешивается ессно в меру умений ФС. Кент имхо все будет уметь, если еще не.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от OpenEcho (?), 01-Ноя-23, 23:05
	> Ващет для файлух логично смотреть на bees, jdupes, duperemove, ... - там За исключением очень специфических задач, на кой оно надо на реальной рабочей машине где все постоянно что-то меняется? Экономия места? Ну так ведь чудес на свете не бывает, значит нужны будут ресурсы для депупа и если это рабочая тачка, то на кой это, если там постоянно все меняется. Другое дело бэкапы, которых чем больше тем лучше и где дедуп+компрессия укладывается в логику нужности
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	326. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 04:24
	>> Ващет для файлух логично смотреть на bees, jdupes, duperemove, ... - там > За исключением очень специфических задач, на кой оно надо на реальной рабочей > машине где все постоянно что-то меняется? На обычной машине меняется так то довольно немного. А место экономится, зачастую нехило. > Экономия места? > Ну так ведь чудес на свете не бывает, значит нужны будут ресурсы > для депупа и если это рабочая тачка, то на кой это, Во многих случаях получается потратить ресурсы 1 раз а эффект долговременный. Или часть дедупалок умеет в инкрементальные забеги, когда пересчитывается толко для того что изменилось с момента прошлого забега. В этом случае ресурсов может тратиться не так уж и много. > если там постоянно все меняется. Другое дело бэкапы, которых чем больше > тем лучше и где дедуп+компрессия укладывается в логику нужности Даже в обычной системе не так уж много чего активно меняется. Исключение разве что файлопомойки но вот это как раз и есть специфическая задача. А улучшить стоимость в пересчете на гиг какой же дятел то откажется.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 12:50
	Да тут в каждой священной войне BtrFS vs ZFS адепты эту дедупликацию используют, что бы сразить наповал противника. При этом плохо себе представляют, какую экономию она в реальности даёт. Потому-то в ZFS прозрачная как бы есть, но отключена по умолчанию.)
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	108. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 13:21
	> Да тут в каждой священной войне BtrFS vs ZFS адепты эту дедупликацию > используют, что бы сразить наповал противника. При этом плохо себе представляют, > какую экономию она в реальности даёт. Потому-то в ZFS прозрачная как > бы есть, но отключена по умолчанию.) А отключена она потому что ресурсов жрет неимоверно, и RAM и CPU. А для btrfs есть и рефлинки (которые zfs едва научился в последней версии только), и "офлайн" дедупы, жрущие сильно меньше ресурсов (особенно рам) потому что реалтайм их не жмет, и "полу-онлайн" типа bees, которые такой офлайн на стероидах, трекающий "изменения" и окучивающий их.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 13:59
	Точно не помню, там требуется что-то порядка 1 Гб оперативы под адаптивный кеш на 1 Тб хранилища. То есть вон тот знаток хранения кеша в метаданных ФС не учёл, что его готовые хеши читаются с накопителя не слишком быстрее остальных секторов, потому так не делается.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 14:00
	*хеша в метаданных
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (120), 31-Окт-23, 14:05
	> Точно не помню, там требуется что-то порядка 1 Гб оперативы под адаптивный > кеш на 1 Тб хранилища. То есть вон тот знаток хранения > кеша в метаданных ФС не учёл, что его готовые хеши читаются > с накопителя не слишком быстрее остальных секторов, потому так не делается. У офлайн дедупалок обычно либо хранение в рам либо - в БД или файле под это дело. Второе RAM не жрет в тех объемах, но более компромиссно по перфомансу, ессно. Вы же понимаете что серебряных пуль - не бывает? И выигрывая в чем-то одном проигрываем в чем-то ином. Ну вот совсем-онлайн дедуп означает нефиговый жор ресурсов, в реальном времени. Потому что реалтайм не ждет. Офлайн дедупалка реалтаймом не ограничена и может в общем то тупить себе в удовольствие, всем похрену. Будет меньше выигрыша, но запись не заклинит, в отличие от.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	317. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 01-Ноя-23, 23:55
	> А отключена она потому что ресурсов жрет неимоверно, и RAM и CPU Что-то не любят этот жор в деньгах измерять. По моим прикидкам, с inline (почему его не назвали online?) dedupe в ZFS легко потратить на оперативку больше, чем сэкономить на диске.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	350. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (5), 02-Ноя-23, 09:47
	Если поискать, то сами пользователи ZFS публикуют свои варианты, когда для них экономия ощутима. Задачи специфичные, да. У одного образов виртуалок немерено (он их клонирует и что-то незначительно меняет для тестирования своего софта). У другого на выделенном под хранилище сервере что-то подходящее под дедупликацию хранится, вся имеющаяся оператива отведена под адаптивный кеш, потому её требуется вдвое меньше, чем было бы у местных любителей покупать модули при каждом обновлении браузера.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от t (??), 01-Ноя-23, 15:36
	о, а расскажите, kopia используете, да?
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	312. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от OpenEcho (?), 01-Ноя-23, 22:27
	>  kopia используете, да? да A что рассказать ?
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от t (??), 02-Ноя-23, 07:21
	почему kopia а не borg? как себя показывает? не разваливался ли репо? у меня негативный опыт с kopia - весной пробовал, поставил товарищу под windows, через неделю перестал работать, репа стала не консистентной. это чисто windows проблемы ?
	Ответить | Правка | Наверх | Cообщить модератору

	388. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от OpenEcho (?), 02-Ноя-23, 19:25
	> почему kopia а не borg? борг - это питон, но при всем при этом работает только то никсами и все что умеет наружу - это только через ССШ. Копия же в отличие - нативный, кросплатформенный код с поддержкой практически всех клаудов и вообще без зависимостей, - это из основного. > как себя показывает? не разваливался ли репо? Пока что не разу не было. Самый большой арчивчик - 83терабайта > у меня негативный опыт с kopia - весной пробовал, поставил товарищу под > windows, через неделю перестал работать, репа стала не консистентной. это чисто > windows проблемы ? Скорее всего что-то не так устаноленно, не надо юзать kopiaUI, это просто электроновский врапер поверх командной линии, под виндой надо по хорошему добавлять в хуках VSS snapshots, значительно надежней, т.к. винда очень любит блокировать файлы и как результат - облом. Ну и не скипать мэинтансе, которя найдет ошибки в бэкапе
	Ответить | Правка | Наверх | Cообщить модератору

	396. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от t (??), 03-Ноя-23, 01:34
	> борг - это питон, но при всем при этом работает только то > никсами и все что умеет наружу - это только через ССШ. > Копия же в отличие - нативный, кросплатформенный код с поддержкой практически > всех клаудов и вообще без зависимостей, - это из основного. да, питон, да никсы, да ssh. в целом хватало, пока не пришлось еще и с виндой у друга повозиться. все клауды в kopia - это ж rclone (может не как зависимость, но прям он), при необходимости через оный можно и другое заливать куда-то. Но за мессадж спасибо, буду попробовать следующую репо с бекапом поднять используя kopia.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 12:29
	> Тот, кто тебе мешает написать оффлайн-дедупликатор. А ему это делать и не потребуется. Все что надо это чтобы файлуха вывешивала IOCTL "same extent", тулсам которые его вызывают так то похрен что там за файлуха реально будет. И вопрос вывешивает ли сие файлуха и если да то насколько стремно это работает.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	104. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (5), 31-Окт-23, 13:02
	Уберите этого Анонима, он уже половину за вон того лентяя написал.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 13:30
	> Уберите этого Анонима, он уже половину за вон того лентяя написал. Да это не я написал, это линуксные ядерщики с "same extent" IOCTL. Первым его btrfs'ники предложили но потом XFSникам тоже зашло а там и ZFSники даже как-то смогли все же сову на глобус, хоть и долго ломались и плевались. -B --dedupe               call  same-extents  ioctl  or  clonefile()  to  trigger a filesystem-level data deduplication on disk (known as copy-on-write, CoW, cloning, or reflink); only a few filesystems support this               (BTRFS; XFS when mkfs.xfs was used with -m crc=1,reflink=1; Apple APFS) Это кус мана на jdupes. В последней версии ZFS вроде это тоже завезли наконец и оно в принципе и его сможет окучивать, как я понимаю. И сабжа окучает, если кентушка вывесит ioctl. А как он внутри это разрулит уже дело его и его ФС. Дедупалка сабмитит кандидатов на дедуп, файлуха дедупает, там не так уж много допущений. На уровне этого интерфейса можно даже делать вещи типа дедупа файла самого на себя, если у файла 2 одинаковых куска - можно референснуть 2 раза даже в 1 файле. В общем случае cow'ам похрену, что так 2 раза ссыли на блоки, что сяк.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (227), 01-Ноя-23, 05:29
	за Кент Оверстрит (Kent Overstreet)?
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	210. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноньимъ (ok), 01-Ноя-23, 02:53
	> Прозрачная скажется на производительности и даст порядка 10% экономии места При этом сожрёт всю RAM без остатка.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	469. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (469), 04-Ноя-23, 23:05
	> При этом сожрёт всю RAM без остатка. Поэтому нужно всё писать на ассемблере. Тем более это не проблема с современными средствами разработки (с).
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 08:58
	> дедупликации нет? Анон, ты издеваешься? Этой штуке в кернеле БЕЗ ГОДУ НЕДЕЛЯ. Оно ЭКСПЕРИМЕНТАЛЬНОЕ - и садясь в кресло этого звездолета проверь что вторым пилотом вообще не манекен сидит (spoiler: таки манекен, тебя предупредили!). И скажи спасибо если хотя-бы основные подсистемы все же привинтили. Это ЭКСПЕРИМЕНТАЛЬНЫЙ образец на данный момент! А тебе все и сразу подавай. Если оно надо на вот именно линухе и близко к реалтайму и стабильно, без out of tree хрени - ну, возьми btrfs и гоняй там bees если уж ресурсы на это убивать хочется. А на вот этом я бы пока ничего кроме ТЕСТОВЫХ наборов данных хранить не стал.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	21. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (1), 31-Окт-23, 09:16
	Нет, не издеваюсь, казалось бы оффлайновая должна быть, если возможна архитектурно.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 09:29
	Чисто теоретически на таком дизайне это сделать - вообще не проблема. Чисто практически - насколько уже сделали и работает ли это - а вот будет -rc1, приходи да посмотри. И если вдруг еще нет, или жуткие глюки, а фичу хочется - можно попробовать ну там баг в багзилу повесить, как напоминалку, потому что cow без хотя-бы офлайн дедупа это и правда забавно. Самое очевидное что там не было когда я смотрел недавно это backrefs, сталбыть замена девайсов и прочий shrink файлухи будет заметно хуже btrfs'а. Но это tradeoff: можно отстройку реверс-индекса делать плавно и в рантайме всегда, а можно конденсированно в момент операции. Оба варианта имеют свои плюсы и минусы. Без backrefs быстрее в крейсерском режиме но когда захочется shrink или изъятие девайса наступит момент пожалеть о такой экономии.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (120), 31-Окт-23, 14:07
	В fs/bcachefs/fs-io.c loff_t bch2_remap_file_range() даже вроде поход на зачатки реализации нужных ioctl'ов. Но насколько сие работает - ессно будет понятно когда -RC1 выкатят.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от OpenEcho (?), 31-Окт-23, 12:24
	>  казалось бы оффлайновая должна быть, если возможна архитектурно. Кэширование - это о скорости, а не о экономии. Делать дедупликацию в ущерб скорости в этом случае - это шаг назад
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	147. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 31-Окт-23, 16:04
	файловая система ничего не должна кешировать, она организует способ хранения в зависимости от устройства хранения.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от OpenEcho (?), 31-Окт-23, 18:20
	> файловая система ничего не должна кешировать, она организует способ хранения в зависимости > от устройства хранения. По моему новость была именно о кэшировании ;)
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 31-Окт-23, 22:04
	> По моему новость была именно о кэшировании ;) """" Особенностью Bcachefs является поддержка многослойного подключения накопителей, при котором хранилище компонуется из нескольких слоёв - к нижнему слою подключаются наиболее быстрые накопители (SSD), которые используются для кэширования часто используемых данных, а верхний слой образуют более ёмкие и дешёвые диски, обеспечивающие хранение менее востребованных данных. Между слоями может применяться кэширование в режиме отложенной записи (writeback). Накопители можно динамически добавлять и отсоединять от раздела без остановки использования файловой системы (данные мигрируют автоматически). """" вот этой хренью фс заниматься не должна!!!
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 23:35
	> вот этой хренью фс заниматься не должна!!! Как показал пример bcache - осмысленно заинтегрировать с учетом свойств девайсов может быть достаточно интересной опцией. Файлухе виднее всего что с файлами творится. А блочный уровень понятия не имеет что это за блоки и потребуются ли они реально еще раз вообще, может это кус метаданных который отброшен навсегда (весьма типично для cow). К тому же cow дизайны на кеширование блочного уровня неважно маппятся. Но вы можете показать как оно у вас лучше работает. Let's the battle begin! И мы посмотрим кто кого сделает. Это и определит что и как "должно" быть. Файт!
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 02:07
	> Но вы можете показать как оно у вас лучше работает. Let's the > battle begin! И мы посмотрим кто кого сделает. Это и определит > что и как "должно" быть. Файт! отлично, начнем с определения, что есть блочное устройство хранения, ФС и какие функции они выполняют?
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 04:38
	>> Но вы можете показать как оно у вас лучше работает. Let's the >> battle begin! И мы посмотрим кто кого сделает. Это и определит >> что и как "должно" быть. Файт! > отлично, начнем с определения, что есть блочное устройство хранения, ФС и какие > функции они выполняют? Блочное устройство это устройство хранения которое хранит данные, оперируя при типовых операциях блоками данных как минимальным юнитом IO. При том сейчас наметилось некое разделение, вылившееся в Zoned. Оно было и раньше, как MTD, потому что блоки бывают разные и блоки флеша - на самом деле совсем не то же что сектора HDD. Но MTD слишком хардкорно, Zoned это еще одна попытка нащупать баланс между полным абстрагированием в фирмвари истинной природы накопителя и спихиванием сложностей на ядра, ФС и блочный уровень. ФС в целом - хранит файлы, прежде всего. Файл это именованая запись с набором данных, вы в курсе. Но вот как показала практика, есть довольно большая разница между минимальным определением автомобиля и тем что реально хочется. Да, без круиз контроля и кондиционера водитель не умрет. Однако их отсутствие точно не будет фичой. И популярности не добавит.
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 16:24
	> Блочное устройство это устройство хранения которое хранит данные, оперируя при типовых > операциях блоками данных как минимальным юнитом IO. ОЗУ - блочное устройство? > Но вот как показала практика, есть довольно большая разница между минимальным определением > автомобиля и тем что реально хочется. Да, без круиз контроля и > кондиционера водитель не умрет. Однако их отсутствие точно не будет фичой. > И популярности не добавит. реально хочу, что бы автомобиль летал, вопрос тот же - должен он летать?
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 04:46
	> ОЗУ - блочное устройство? В общем случае за него не считается - ибо произвольно адресуемо вплоть до побайтового доступа. В блочном устройстве нельзя пойти и изменить только 105-й байт от начала памяти, минимальный юнит это сектор/блок. И идем кантовать минимум 512 байтов кусок, даже если хотели 1 байт изменить. А то и 4К в более современных хардах. Ну вот не умеет оно записывать 1 байт. Потому и блочное. В Flash еще хитрее, там есть "pages" и "eraseblocks" а запись разнесена 2 разные операции, стирание и программирование. И если pages еще могут на сектор смахивать то eraseblock измеряется в мегабайтах. Так что это еще и КРУПНОблочное устройство, да еще с нетривиальными заморочками, и наружу - довольно приблизительная абстракция. А пойти и гарантированно записать 105-й байт от начала девайса? Не, так в флеше в общем случае нельзя. Иногда, и с большими оговорками - может быть, но при этом все равно с eraseblocks знакомство состоится. Так что наружу они предстают чем-то с блоками, отличие этой абстракции от реальных кишок дико варьируется, от почти 1 в 1 до огромного FTL. При желании из RAM можно эмулировать блочный девайс, но это лишь эмуляция. Умея писать в произвольный регион, соврать что нифига, только блоками - да не вопрос. Наоборот ессно не то чтобы нельзя но сильно менее эффективно - поддержать абстракцию произвольного доступа можно только RMW на весь блок. Прочитать сектор, запатчить там 105-й байт, записать обратно. Своротив все 512 байтов ради одного. Потому и блочное. > реально хочу, что бы автомобиль летал, вопрос тот же - должен он летать? С учетом числа тех кто пытается такое сделать, и sci-fi где оно так - возможно что да. Глупо утыкаться в 2 измерения и стоять в пробках когда измерений три. А я от вас отличаюсь тем что на самом деле хочу - небольшой звездолет с гипердвигателем и машиной времени. Чтобы навигировать по 4 измерениям как босс. Ну вот и с файлухами так же.
	Ответить | Правка | Наверх | Cообщить модератору

	364. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Ноя-23, 14:33
	> В общем случае за него не считается - ибо произвольно адресуемо вплоть > до побайтового доступа. ага, а tmpfs это что за ФС? Произвольно адрессуется? это что такое? Линейная там адрессация, а вот произвольный там - доступ. И в то же время я же не имею возможности прямого изменения бита данных, вот вам и блочное устройство с размером блока в 8 бит. > Ну вот не умеет оно записывать 1 байт. Потому и блочное. дело не в записи, а в адрессуемости. > Так что наружу они предстают чем-то с блоками, отличие этой абстракции от реальных кишок дико варьируется, от почти 1 в 1 до огромного FTL. А ФС то в итоге будет работать разве не с единым интерфейсом блочного устройства, а все вся остальная магия на совести драйвера этого устройства? > При желании из RAM можно эмулировать блочный девайс, но это лишь эмуляция. в смысле эмуляция? рамдиск это эмуляция или полноценное блочное устройство?    > Своротив все 512 байтов ради одного. Потому и блочное. своротив 8 битов, ради одного - потому и блочное. > Ну вот и с файлухами так же. в этом то вся и беда. Рожденный ползать ..... (ц) М. Горький
	Ответить | Правка | Наверх | Cообщить модератору

	424. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 15:22
	> ага, а tmpfs это что за ФС? Произвольно адрессуется? это что такое? Это - файловая система в оперативке. Вот только к блочным устройствам это не относится уже. > Линейная там адрессация, а вот произвольный там - доступ. И в > то же время я же не имею возможности прямого изменения бита > данных, вот вам и блочное устройство с размером блока в 8 бит. Вот позвольте! Никто нигде не утверждал что ВСЕМ файлухам НЕОБХОДИМО именно блочные устройства, в обязаловку. Есть всякие специализированные экспонаты, НЕ ориентированные на вот именно блочные устройства. Или ориентированные на какую-то специфику. Например flash filesystems. Какой-нибудь UBIFS вы только на флеше и подымете. Флеши в ТОМ их виде, кстати, не "block device" в терминах линя, а таки "MTD" (memory-technology device). Чтобя явно их отличать от обычных блочных девайсов по типу HDD. В линухе TMPFS вообще никаким блочным устройствам формально вроде не соответствует и являет собой просто аллокации кернелом в оперативе как я понимаю. Без backing блочного устройства, а потому жрущая RAM по объему реально-занятого и не испытывающая проблем отдать место. С блочным устройством - а там сложнее понять используется ли блок и если он отобран под рамдиск, назад его забрать уже очень отдельный трабл будет. Но есть и такое, скажем ZRAM, он еще жмет страницы к тому же. Сватается в основном для свопа но вот там именно явный block device сэмулирован - и на него можно любую ФС для блочных устройств уже разложить. А у tmpfs вообще понятия блочного девайса и форматирования (в энную ФС) - нету. Такая ерунда. Мораль сей басни? ФС != блочный девайс. Кто-то сомневался? >> Ну вот не умеет оно записывать 1 байт. Потому и блочное. > дело не в записи, а в адрессуемости. Под блочными девайсами подразумевают характерный класс девайсов с характерными свойствами. Оператива сама по себе не есть блочный девайс, и tmpfs как раз хороший пример - она вообще не обладает формальным блочным девайсом и маунтится в лине "вникуда". Т.е. вы ее заказываете но этому никакой блочный девайс не соответствует. В частности lsblk ничего не покажет для tmpfs. > А ФС то в итоге будет работать разве не с единым интерфейсом > блочного устройства, а все вся остальная магия на совести драйвера этого > устройства? Tmpfs в линухе не подперт никаким явным блочным девайсом. Такая ерунда. Наберите lsblk на компе с tmpfs и убедитесь. А откуда следует что ФС == блочный девайс? Ниоткуда? То-то и оно. В лине есть несколько ФС которые не подперты блочными устройствами или хотят иной тип устройств типа MTD например. >> При желании из RAM можно эмулировать блочный девайс, но это лишь эмуляция. > в смысле эмуляция? рамдиск это эмуляция или полноценное блочное устройство? Можно вывесить вот именно блочное устройство - даже соврав что надо работать посекторно. В этом случае софт не отличит сие от иного блочного девайса. А можно этого не делать и работать как tmpfs. Но на tmpfs как раз и нельзя нарезать произвольную файлуху для блочных девайсов - у него backing block device просто нет. Не на что нарезать ФС. Оно самодостаточная абстракция не подпертая блочным устройством. >> Своротив все 512 байтов ради одного. Потому и блочное. > своротив 8 битов, ради одного - потому и блочное. В устаканившихся у вон тех терминах блок обычно подразумевает сектор 512 или 4096 байтов. И как блочный девайс обычно вывешено вот такое вот. >> Ну вот и с файлухами так же. > в этом то вся и беда. Рожденный ползать ..... (ц) М. Горький Ну вот я и хочу себе звездолет с гипердвигателем и машиной времени. Когда можно не только летать, но и столкнувшись с перспективой впечататься в твердь - быренько отмотать время взад, сменить курс, сделать вид что факапа не было - а вы даже и не узнаете что я собирался расплющиться. Для вас, наружу, этого никогда и не существовало.
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

	437. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Ноя-23, 18:08
	> Это - файловая система в оперативке. Вот только к блочным устройствам это > не относится уже. https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html https://docs.kernel.org/admin-guide/blockdev/ramdisk.html /dev/shm /dev/ram /dev/zram это все что? > Мораль сей басни? ФС != блочный девайс. Кто-то сомневался? а никто этого и не утверждал, ФС уровнем абстракции выше уровня устройства. > Под блочными девайсами подразумевают характерный класс девайсов с характерными свойствами. > Оператива сама по себе не есть блочный девайс, и tmpfs как > раз хороший пример - она вообще не обладает формальным блочным девайсом > и маунтится в лине "вникуда". Т.е. вы ее заказываете но этому > никакой блочный девайс не соответствует. В частности lsblk ничего не покажет > для tmpfs. /dev/shm что это? > А откуда следует что > ФС == блочный девайс? Ниоткуда? А кто такой вывод сделал? я такого не делал. > Можно вывесить вот именно блочное устройство - даже соврав что надо работать > посекторно. В этом случае софт не отличит сие от иного блочного > девайса. зачем tmpfs нужны вот эти параметры монтирования? """ tmpfs has three mount options for sizing: size nr_blocks nr_inodes """ https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html > Но на tmpfs как раз и нельзя нарезать произвольную файлуху для блочных девайсов - > у него backing block device просто нет. Не на что нарезать > ФС. Оно самодостаточная абстракция не подпертая блочным устройством. всмысле нарезать ФС? > В устаканившихся у вон тех терминах блок обычно подразумевает сектор 512 или > 4096 байтов. И как блочный девайс обычно вывешено вот такое вот. ну это не серьезное утверждение. > Ну вот я и хочу себе звездолет с гипердвигателем и машиной времени. Я тоже хочу, но вам не предлагаю :)
	Ответить | Правка | К родителю #424 | Наверх | Cообщить модератору

	450. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 10:20
	> https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html Ну и что там про блочные устройства? И mkfs у него нет. Монтирование самодостаточно для создания, никакой девайс при этом не указывается. > /dev/shm > /dev/ram > /dev/zram > это все что? Это разные устройства так или связанные с RAM. По довольно разным поводам. В этом контексте, рамдиски и zram - ведут себя как эмуляция блочного устроства, zram еще и сжатый. А shm вообще про совместно используемые регионы памяти между процессами. Как это все к топику? >> Мораль сей басни? ФС != блочный девайс. Кто-то сомневался? > а никто этого и не утверждал, ФС уровнем абстракции выше уровня устройства. Ну и отлично. ФС может быть вообще подперта чем угодно. > /dev/shm что это? Это shared память между процессами насколько я помню. К tmpfs не относится вообще. > А кто такой вывод сделал? я такого не делал. Отлично, а о чем тогда спич? > зачем tmpfs нужны вот эти параметры монтирования? ... > nr_inodes Параметры абстракции. В какой-то явный блочный девайс это в случае tmpfs не отливается. Тут еще стоит добавить что с RAM зачастую удобно работать юнитами размерами со страницу. Из соображений выставления прав. Это однако не минимальный юнит IO. Более того - из-за страниц можно даже эмулировать RAM свопфайлами и разделами. Но это не уже на самом деле не рандомный доступ - гранулярность как правило страница 4К и это уже таки не RAM. Потому что рандомного доступа как раз уже и нет. > всмысле нарезать ФС? В прямом. В /dev/ramX или /dev/zramX можно класть любую ФС для блочных устройств в пределах технических лимитов. Скажем, создав там ФС mkfs'ом. Коли уж эмулирует блочный уровень. Tmpfs этого не делает и там нет таких понятий, как и явного блочного девайса. В этом смысле - сие довольно разные технологии. > ну это не серьезное утверждение. Ну как бы устаканились вот такие абстракции. Они местами пересекаются. Местами несколько условны. Местами эмулируют друг друга. Но в конечном итоге нечто либо вывешено как блочный девайс, либо нет. И критерий блочного девайса - минимальный юнит IO. Более формально - если оно есть для lsblk, то несомненно блочный девайс. Если нету - значит это что-то другое, даже если и похоже на вид. >> Ну вот я и хочу себе звездолет с гипердвигателем и машиной времени. > Я тоже хочу, но вам не предлагаю :) А я вот пришел и показал ALL что экспериментальная модель - вот - выкачена из ангара и взята в оборот. Тестовые пилоты желающие покамикадзить - велкам.
	Ответить | Правка | К родителю #437 | Наверх | Cообщить модератору

	468. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 04-Ноя-23, 19:32
	> Ну и что там про блочные устройства? И mkfs у него нет. > Монтирование самодостаточно для создания, никакой девайс при этом не указывается. То что нет у нет mkfs не отменяет факта, что ФС работает с блоками, сами говорите самодостаточность. Читаем внимательно вот это предложение: Contrary to brd ramdisks, tmpfs has its own filesystem, it does not rely on the block layer at all. Вот ее самодостаточность, в которой говориться, что она реализует интерфейс (уровень) ФС и не пологается на блочный уровень, УРОВЕНЬ. tmpfs сама для себя и ФС и блочное устройство, ибо использует блоки "kernel internal caches". То есть на блочное устройство tmpfs нельзя накатить другую ФС которая будет работать с ним (блочным устройством tmpfs) на уровне блочного устройства. > Это разные устройства так или связанные с RAM. По довольно разным поводам. > В этом контексте, рамдиски и zram - ведут себя как эмуляция > блочного устроства, zram еще и сжатый. А shm вообще про совместно > используемые регионы памяти между процессами. Как это все к топику? An alternative to tmpfs and ramfs is to use brd to create RAM disks (/dev/ram*), which allows you to simulate a block device disk in physical RAM. To write data you would just then need to create an regular filesystem on top this ramdisk. И к топику имеет ровно то отношение, что ОЗУ - блочное устройство! > Ну и отлично. ФС может быть вообще подперта чем угодно. И даже самоподперта. > Это shared память между процессами насколько я помню. К tmpfs не относится > вообще. https://www.kernel.org/doc/gorman/html/understand/understand... > Отлично, а о чем тогда спич? спич начинался с того, что ОЗУ - такое же блочное устройство, как и хдд. > Потому что рандомного доступа как раз уже и нет. в смысле нет рандомного доступа? > В прямом. В /dev/ramX или /dev/zramX можно класть любую ФС для блочных > устройств в пределах технических лимитов. Скажем, создав там ФС mkfs'ом. Коли > уж эмулирует блочный уровень. Tmpfs этого не делает и там нет > таких понятий, как и явного блочного девайса. В этом смысле - > сие довольно разные технологии. ну вы же сами указали на самодостаточность tmpfs, она представляет пользователю уровень ФС, а не блочный, но в тоже время сама работает с ОЗУ (kernel internal caches) как с блочным устройством, ибо уровень ФС требует этого. Если посмотреть на синтаксис fstab, то там в качестве source device и fs type указывается tmpfs - из-за самодостаточности. > Более формально - если оно есть для lsblk, > то несомненно блочный девайс. Если нету - значит это что-то другое, > даже если и похоже на вид. обсуждать это все щас бесмыссленно, потому-что никто толком не продумывал (теоретический труд) что должно из себя представлять ФС и вообще ОС в целом. И появления таких недо (само) достаточных ФС как tmpfs, ramfs, procfs, debugfs, securityfs, devtmpfs, configfs, hugetlbfs O_o и всякой дичи с окончанием ФС говорит лишь о том, что от идеи "все есть файл" почему бы не родиться идеи "всё есть ФС" и "все есть блочное устройство"? > А я вот пришел и показал ALL что экспериментальная модель - вот > - выкачена из ангара и взята в оборот. Тестовые пилоты желающие > покамикадзить - велкам. а дальше что? получение оборонзаказа? патенты? и т.д.
	Ответить | Правка | К родителю #450 | Наверх | Cообщить модератору

	481. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 06-Ноя-23, 02:50
	> То что нет у нет mkfs не отменяет факта, что ФС работает > с блоками, сами говорите самодостаточность. Как ей удобно - так и работает. К минимальному юниту IO для RAM это отношения не имеет. > it does not rely on the block layer at all. Я в курсе. И чего? > То есть на блочное устройство tmpfs нельзя накатить другую ФС которая > будет работать с ним (блочным устройством tmpfs) на уровне блочного устройства. Под блочными устройствами в контексте ОС обычно понимают характерный интерфейс, работающий в терминах блоков. А у MTD тоже могут быть блоки, но - это другой интерфейс, обычные ФС не будут с ним работать и в этом аспекте MTD устройства отделяют от блочных. > И к топику имеет ровно то отношение, что ОЗУ - блочное устройство! Не так. "RAM может, но не обязан, использоваться для эмуляции блочных устройств". Можно в обратную сторону: возможна эмуляция RAM из блочных устройств (paging). Но хреновая и медленная. В т.ч. и потому что IO с юнитами по 4096 байтов != "random access". >[оверквотинг удален] > почему бы не родиться идеи "всё есть ФС" и "все есть блочное устройство"? Потому что не все - блочное устройство. В *nix даже есть "антипод", character device. RAM сам по себе - вообще не "device", это непосредственно доступная память (см в конце). > а дальше что? получение оборонзаказа? патенты? и т.д. А дальше - когда Торвальдс даст зеленый свисток в виде -rc1 я плюхнусь в кресло и пойду на взлет, посмотреть как оно мне вообще, что оно может мне дать, какие есть проблемы, и вообще. Если что - иллюстрация на тему что есть рандомный доступ: $ cat 1.c #include <stdint.h> int main() {   uint8_t * something = (uint8_t *) 0x100;   *something = 234; } Да, это на обычном компе упадет, потому что адрес 0x100 не обязан быть доступной оперативой. Но с более валидным адресом - положит байт по указанному адресу. При этом нет никаких системных вызовов и "девайсов". А вот обратиться так к HDD и т.п. - удачи.
	Ответить | Правка | К родителю #468 | Наверх | Cообщить модератору

	482. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 06-Ноя-23, 16:28
	> Не так. "RAM может, но не обязан, использоваться для эмуляции блочных устройств". RAM и есть, а обязан или не обязан - не имеет значения. > В т.ч. и потому что IO с юнитами > по 4096 байтов != "random access". лол, кек - понятие "произвольный доступ" используется в терминах БЛОКА, у каждого блока данных свой адрес, к которому можно произвольно обратиться, и не важно каков размер этого блока данных, 1 или 4096 байтов. первый абзац https://en.wikipedia.org/wiki/Hard_disk_drive > RAM сам по себе - вообще не "device", это > непосредственно доступная память (см в конце). ну за это спасибо Фон Нейману, добавляем новый диск - новое устройство хранения, а добавляем новую планку памяти - доп. размер. Хотя между этими устройствами хранения одна лишь разница, одна энергозависимая другая - нет. > А вот обратиться так к HDD и т.п. - удачи. https://en.wikipedia.org/wiki/Logical_block_addressing
	Ответить | Правка | К родителю #481 | Наверх | Cообщить модератору

	485. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 07:58
	>> Не так. "RAM может, но не обязан, использоваться для эмуляции блочных устройств". > RAM и есть, а обязан или не обязан - не имеет значения. Это именно эмуляция, дополнительным софтом и абстракциями. Я на x86-64 запускаю виртуалки с системой команд ARM или RISCV. Это не делает x86-64 ARM-ом. Нативный интерфейс x86-64 проца это x86-64 поток команд. Даже если я и могу вот тут запустить ARMовский бинарник, это весьма забавная абстракция, не более. С RAM аналогично, то что я могу вывесить там эмуляцию блочного девайса не делает ее блочным девайсом. > лол, кек - понятие "произвольный доступ" используется в терминах БЛОКА, "Блок" и "произвольный доступ" - взаимоисключающие параграфы. Вы или можете адресовать конкретный байт или нет. > у каждого блока данных свой адрес, к которому можно произвольно обратиться, и не > важно каков размер этого блока данных, 1 или 4096 байтов. Вообще-то важно. Вон там машинный код напрямую может пойти и положить число 234 в адрес 0x100 и это немедленно и без дополнительных условий обеспечивается, если там RAM. А в случае с блоком - так нельзя. Как максимум можно подкостылить и сделать вид что получилось, но вот это уже - эмуляция. > https://en.wikipedia.org/wiki/Hard_disk_drive Я рад что вы умеете читать вику, теперь запишите число 234 по смещению 0x100 от начала, не портя другие байты. А, так изначально нельзя? Потому и блочное устройство - на уровне его нативного интерфейса. А то что swap им RAM изображает - круто, но считать ЭТО за именно "random access memory" я все же не буду. Потому что хотя чередой RMW + IO и можно изобразить ЭТО, сие будет крайне медленно и неэффективно и не является нативным интерфейсом девайса. > ну за это спасибо Фон Нейману, добавляем новый диск - новое устройство > хранения, а добавляем новую планку памяти - доп. размер. Планка напрямую адресуема из программы - а HDD на уровне кода программы - изначально вообще не существует. Это уже надо запросы к операционке делать (сисколы). А переменную программы там не разложишь. Такая "небольшая" разница на уровне программного интерфейса. > Хотя между этими устройствами хранения одна лишь разница, одна > энергозависимая другая - нет. А также какими юнитами они адресуются. Конкретный байт или адресуем напрямую или нет. К слову старые ARM програмеры искренне ненавидели за загоны насчет выравнивания. Это как раз клещилось с этой абстракцией, и доставляло море неудобств програмерам. >> А вот обратиться так к HDD и т.п. - удачи. > https://en.wikipedia.org/wiki/Logical_block_addressing В этих терминах не описывается "хочу чтобы байт по смещению 0x100 стал равен 234". Чтобы это обеспечить придется сделать нехилую эмуляцию, RMW, сисколы и проч. На этом основании я и отказываюсь считать это RAM - изначально "random access" там как раз и нету. NB существуют и всякие достаточно забавные промежуточные случаи. Скажем SPI флешка сама по себе не есть "random access memory" - оно в общем случае "девайс на интерфейсе" из которого напрямую вообще выполнять ничего нельзя, надо команды слать. А запись там совсем не рандомная. Но небольшим хардварным довеском доступы в регион памяти начинают транслироваться в SPI-команды прозрачно, хоть и медленно. Вплоть до того что проц при RESET читает допустим память с адреса [0x0] - а железка транслирует это в SPI-команды чтения флехи. Результат достаточно трудноклассифицируем. С одной стороны это нечто типа "ROM" для проца, с другой - оговорок столько что это точно не "RAM" и даже "ROM" только с очень большими оговорками и весьма медленно из-за той трансляции. А нафиг это надо? Так мелким штукам может быть проще грузиться, для проца это прямое выполнение, юзается дешевая малолапая SPI флеха, все обеспечивается простыми железками. Но это "внеклассовая" экзотика. Она не цепляется ни как RAM ни как блочный девайс в том же линухе. Как MTD - еще может быть. Но на это и не получится обычную "блочную" файлуху изобразить, да и "ROM" оно только на начальном этапе, потом код загрузчика буферит это в настоящий RAM потому что так неизмеримо быстрее.
	Ответить | Правка | К родителю #482 | Наверх | Cообщить модератору

	497. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 09-Ноя-23, 00:55
	> Это именно эмуляция, дополнительным софтом и абстракциями. эмуляция это то, чего нет, а блочное устройство из РАМ сделать можно споскойно, и это не эмуляция. > "Блок" и "произвольный доступ" - взаимоисключающие параграфы. Вы или можете адресовать > конкретный байт или нет. какой нафиг бай, а бит я могу адресовать? а почему не могу? потомучто минимальный блок данных который можно адресовать в РАМ это 8 бит! тоже самое и с хдд, адрессуются блоки данных, а не байты, а прикол знаете в чем? а бай вовсе не 8 бит, бывает и 7 и 9 лол кек. > Вообще-то важно. Вон там машинный код напрямую может пойти и положить число > 234 в адрес 0x100 и это немедленно и без дополнительных условий > обеспечивается, если там RAM. А в случае с блоком - так > нельзя. Как максимум можно подкостылить и сделать вид что получилось, но > вот это уже - эмуляция. адрессуются блоки данных, я не виноват что у хдд блок данных имеет размер 512 байт, а рам 1 байт. > Я рад что вы умеете читать вику, теперь запишите число 234 по > смещению 0x100 от начала, не портя другие байты. А, так изначально > нельзя? Потому и блочное устройство - на уровне его нативного интерфейса. смещению относительно какого базавого адреса? вы понимаете что есть базовый адрес и смещение? > Планка напрямую адресуема из программы - а HDD на уровне кода программы > - изначально вообще не существует. Это уже надо запросы к операционке > делать (сисколы). А переменную программы там не разложишь. Такая "небольшая" разница > на уровне программного интерфейса. а что если я не делаю аллокация, моя программа что нибудь знает о памяти? нет не знает. Моей программе вообще доступна вся память если на то пошло. > В этих терминах не описывается "хочу чтобы байт по смещению 0x100 стал > равен 234". Чтобы это обеспечить придется сделать нехилую эмуляцию, RMW, сисколы > и проч. На этом основании я и отказываюсь считать это RAM > - изначально "random access" там как раз и нету. все зависит на каком уровне абстракции работает ваша программа, вот для этого и придумали файловые системы, чтобы не думали о всяких смещениях и адрессах. Достаточно иметь интерфейс, открой такой-то файл, запиши в него столько-то байт по такому смещению (учтите смещению относительно начала файла, а не всяких блоков на устройстве хранения), закрой хендл файл и всё. Работа с интерфейсом блоков уже ложиться на саму ФС, как хочет так и организует хранение файлов. А все остальное это уже работа драйвера устройства. > NB существуют и всякие достаточно забавные промежуточные случаи. Скажем SPI флешка сама > по себе не есть "random access memory" - оно в общем > случае "девайс на интерфейсе" из которого напрямую вообще выполнять ничего нельзя, > надо команды слать. А запись там совсем не рандомная. для уровня который предоставляет ФС до лампочки, пользователю нужно, открыть записать и закрыть, все. ДЛя ФС прочла блок, записала блок и всё. Драйвер как там представляет блочный интерфейс уже не важно.
	Ответить | Правка | К родителю #485 | Наверх | Cообщить модератору

	502. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Ноя-23, 22:31
	> эмуляция это то, чего нет, У RAM нет изначально никаких "блоков", по определению RAM. Так же как x86 на самом деле не умеет выполнять ARMовские программы. Что общего? Это абстракции создаваемые дополнительным софтом. > а блочное устройство из РАМ сделать можно споскойно, и это не эмуляция. Изначально блоков нет. Но можно создать абстракцию добавочным софтом. > какой нафиг бай, а бит я могу адресовать? а почему не могу? В некоторых штуках, типа Cortex M, можно и лобовую атомарную адресацию конкретных битов 1 операцией. Они забавно сделали: замаппили регионы адресов в отдельные биты. И вот уже запись u32 в конкретный адрес - пишет 1 конкретный бит в регионе alias'а. Можно и чтение, значение бита вернет. Почему u32? Нативный размер слова и шины проца, видимо так проще всего было, а адресов много и экономить не требовалось. Можно, вот, и 1 бит атомарно, если это встроенная RAM или регистры периферии. > потомучто минимальный блок данных который можно адресовать в РАМ это 8 бит! Процы могут с этим фактом жить, напрямую адресуя его, в отличие от "блочных устройств". И команды для работы с битами и даже битовыми полями бывают. Впрочем вон пример проца который и 1 бит в своей RAM за 1 операцию шины адресует. > тоже самое и с хдд, адрессуются блоки данных, а не байты, а прикол знаете в чем? > а бай вовсе не 8 бит, бывает и 7 и 9 лол кек. Бывает много всякой странной фигни но я не вижу смысла ее обсуждать в топике про более менее обычные фс. В этом контексте под блочным устройством понимают вполне характерные абстракции. > адрессуются блоки данных, я не виноват что у хдд блок данных имеет > размер 512 байт, а рам 1 байт. Блоки данных с HDD изначально вообще не существуют в адресном процтранстве проца. И поддержанием связанных с этим абстракций так то занимается довольно большой пласт софта. С которым "файлушники" в линухе неизбежно познакомятся. > смещению относительно какого базавого адреса? вы понимаете что есть базовый адрес и смещение? Можно 0 для определенности. Хороший базовый адрес, у всех одинаковый более-менее. Даже на жестком диске понятие вида "150423-й байт от начала" как таковая - валидно. А то что выполнять "mod 512 math" прерогатива дополнительного софта - бывают в жизни огорчения. Если уж возвращать вам фавор, mmap() делает весьма убедительную абстракцию линейного адресного пространства из вон того. Однако это не делает HDD RAM как таковым. На уровне его нативного IO он не может в рандомный доступ к 150423-му байту. И придется просить сектор с ним, а там если хотите можете RMW сами сделать. Но это как раз уже и был не рандомный доступ а блочный. > а что если я не делаю аллокация, моя программа что нибудь знает > о памяти? нет не знает. Эй, эксперт, а вы программировать точно умеете и понимаете программную модель типовых компьютерных систем? В неймановской абстракции адреса существуют "сами по себе" и то что там RAM будет например изначально замаплен - ничему не противоречит. Аллокация это абстракция многозадачных ОС (которые сами так то абстракция). Скажем в C можно программировать и совсем без *alloc(). Используя стек, или статическое распределение памяти. Более того - в embedded вполне нормально если *alloc() в фирмвари вообще нет. При этом память не может "закончиться". Такой абстракции просто нет. И если оно запустилось - то уж работает. Исключение разве что переполнение стека. Более того - у многих современных камней есть блоки SRAM доступные сразу после power up без дополнительных условий, оговорок и конфигурации этого. Вот прям с power up первыми командами берете и адресуете это. В терминах машинного кода на этом этапе аллокаций вообще нет как класса, эта абстракция будет создана где-то сильно потом. > Моей программе вообще доступна вся память если на то пошло. Ей доступно "все адресное пространство". Что в нем замаплено в общем то отдельный вопрос. Но ничему не противоречит и что туда та или иная RAM замаплена, сразу, хоть при power up системы, при этом RAM доступен, а абстракции типа "аллокаций" если и будут то где-то сильно потом. И вообще-то они опциональны, даже если с ними и удобнее/лучше в ряде случаев. > все зависит на каком уровне абстракции работает ваша программа, вот для этого > и придумали файловые системы, Как ни странно posix поддерживает абстракцию как будто это обычная 1-задачная система и заметить отличия можно только если это отдельно и явно захотеть и оно зачем-то надо было. Это упрощает програминг: если кто не хочет париться многозадачностью, он и не парится. И код так портабельнее. > чтобы не думали о всяких смещениях и адрессах. Работая с файлами таки все равно придется в ряде случаев трекать из смещения. А какие нибудь БД так и половину абстракций ФС пересоздают, а файлом оно в основном "для удобства менеджмента админом". Этому вообще может быть удобнее на RAW разделе - но так админам неудобно, как например стораж расширить? В btrfs то "device add", получаем +n места, файл без проблем отрастет и туда. А с разделом такое упс. Не тот уровень абстракций. > Достаточно иметь интерфейс, открой такой-то файл, запиши в него столько-то > байт по такому смещению (учтите смещению относительно начала файла, Фокус в том что файловые системы так то тоже - абстракции. Как впрочем и файлы. Их поддерживает специфичный софт - файловые системы. В простейшем случае можно и без этих абстракций. У меня есть несколько фирмварей напрямую таскающих сектора с SD/MMC. Но в операционке общего назначения это было бы не очень удобно. В узкоспециализированной фирмвари где оно для специфичных целей - можно и вот отдельные сектора. И таки RMW секторов и не особо удобно и не то чтобы сильно эффективно vs реально рандомный доступ. И память под буферизацию сектора жрет, для мелочи - аргумент. SD/MMC в этом смысле типичный представитель "блочных устройств". С весьма нерандомным доступом. > и организует хранение файлов. А все остальное это уже работа драйвера устройства. Драйвера устройств так то тоже - всего лишь абстракции. При том в разных ОС еще и разные. > для уровня который предоставляет ФС до лампочки, пользователю нужно, открыть записать и > закрыть, все. Обычные ФС могут быть нереализуемы на неподходящей абстракции. И тогда этого не будет. Или будет вам наглухо readonly эмуляция - и хватит с вас. А попробуйте в роутере squashfs перезаписать, узнаете в чем прикол! Абстракция ФС - есть, но... 1) у нее нет понятия записи и 2) это не "блочное устройство" внезапно а MTD вообще какой окажется. И 3) более обычные ФС на таком жить конечно же не смогут. > ДЛя ФС прочла блок, записала блок и всё. Драйвер > как там представляет блочный интерфейс уже не важно. А таки вот блочные устройства и память с произвольным доступом отличаются на самом базовом уровне, еще до того как все вон те абстракции станут актуальны. И в общепринятом понимании критерий это минимальный юнит IO в основном.
	Ответить | Правка | К родителю #497 | Наверх | Cообщить модератору

	505. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 11-Ноя-23, 01:56
	> У RAM нет изначально никаких "блоков", по определению RAM. Соглашусь все же, ибо это определение дал сам Тьюринг, своей "бесконечной лентой". Не мне, его определения ставить под сомнение. > Они забавно сделали: замаппили регионы адресов в отдельные биты. чет не в курил, ссылку плиз. > Блоки данных с HDD изначально вообще не существуют в адресном процтранстве проца. в смысле "в адресном пространстве проца"? а южный мост для чего? > Однако это не делает HDD RAM как таковым. На уровне его > нативного IO он не может в рандомный доступ к 150423-му байту. и сколько байт из свопа должны возвратиться в рам? > В неймановской абстракции адреса существуют "сами по себе" и > то что там RAM будет например изначально замаплен - ничему не > противоречит. Ну да, и "бесконечной ленты" нет выходит :) > В терминах машинного кода на этом этапе аллокаций вообще нет как класса, > эта абстракция будет создана где-то сильно потом. "выделить" - кем-то - кому-то, и собственно что-то . А в вашем случае (power up) кроме "меня" никого нет, всё доступно "мне". "Сам себе" я не выделяю если и так "мне" это всё доступно. > Но ничему не противоречит и что туда та или > иная RAM замаплена, сразу, хоть при power up системы, при этом > RAM доступен, а абстракции типа "аллокаций" если и будут то где-то > сильно потом. И вообще-то они опциональны, даже если с ними и > удобнее/лучше в ряде случаев. ну и регистры так же доступны, и ЦПУ (с регистрами и АЛУ) до лампочки есть у него ММУ блок или нет. Зависит от архитектуры. > А какие нибудь БД так и половину абстракций ФС пересоздают а вот зачем? > Обычные ФС могут быть нереализуемы ага сделать sync в tmpfs (return 0)
	Ответить | Правка | К родителю #502 | Наверх | Cообщить модератору

	507. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 11-Ноя-23, 15:29
	> Соглашусь все же, ибо это определение дал сам Тьюринг Алилуя. Я даже в чем-то согласен насчет битов, НО это наполовину к CPU вопрос. Минимальный юнит который многие CPU адресуют - байт. Быть святее папы римского? >> Они забавно сделали: замаппили регионы адресов в отдельные биты. > чет не в курил, ссылку плиз. Например, https://www.st.com/resource/en/programming_manual/pm0056-stm... - Memory Model, 2.2.5 Bit-Banding. Такой маппинг, bit[N] <-> u32[N]. Адресов больше чем памяти, они и отмаппили. Можно за 1 атомарную операцию конкретный бит потрогать. Это ARM для МК так, заодно спасет от гонок когда IRQ вклинился в середине RMW и имел свои идеи что сделать с переменной/регистром. Какая вероятность словить IRQ в середине RMW понятно, удачи в дебаге. >> Блоки данных с HDD изначально вообще не существуют в адресном процтранстве проца. > в смысле "в адресном пространстве проца"? а южный мост для чего? Южный мост - частный случай. На том SoC с линем (да, я смогу сабж там погонять) и даже этом десктопе DRAM controller в проце. У SoC часто есть SRAM доступный "сразу", например, чтобы boot loader подымающий DRAM (это целое действо) туда читать. И система команд процов строится вокруг "адресации". У МК RAM и ROM сразу есть после power up. Они все - процы и у них есть адреса. Адрес сам по себе - число. >> нативного IO он не может в рандомный доступ к 150423-му байту. > и сколько байт из свопа должны возвратиться в рам? Завсит от системы. Page fault работает в терминах страниц. Которые чаще всего 4096 байтов. Не очень рандомно - воротить 4096 байтов чтобы запатчить 1 из них. > Ну да, и "бесконечной ленты" нет выходит :) Реальные машины сложнее чем та абстракция. Сам по себе адрес лишь число энной разрядности. Соответствует ли конкретному адресу что-то логическое (или физическое) или ничего - вопрос номер два. В си (асме, unsafe хрусте и еще ряде штук) можно итерировать все адресное пространство указателями. Правда, в многозадачке за левый доступ в unallocated адреса могут и SIGSEGV или его аналог дать. И даже в физической машине с полным доступом результат - весьма варьируется. Некому диапазону адресов может не соответствовать ничего. А железо может такое эскалировать до исключения. Или забить. Случаи разные бывают. У 64 бит систем 2^64 адресов никогда полностью не аллоцированы: не бывает столько памяти у систем. > случае (power up) кроме "меня" никого нет, всё доступно "мне". "Сам > себе" я не выделяю если и так "мне" это всё доступно. "Все" - достаточно абстрактно. Даже при раннем старте - а у вас есть 2^64 памяти? (в случае 64 бит системы). На 32-бит системе типа МК тоже не обязано быть все 4G раскиданых от и до. Но чисто технически машинный код и яп низкого-среднего уровней могут попытаться сходить в вполне конкретный адрес, итерировать и проч. Можно словить за это от MMU. железа и проч, которые так то могут и эскалировать совсем левый доступ хзкужа в исключение. В bare metal оно сразу вам и прилетит. В многозадачках... его получит ядро. Но потом оно отгейтует абстракцию как "сигнал" типа SIGSEGV или что там, общая идея остается. > ну и регистры так же доступны, и ЦПУ (с регистрами и АЛУ) > до лампочки есть у него ММУ блок или нет. Зависит от архитектуры. У многих CPU регистры, внезапно, не имеют соответствующих им адресов в памяти и не адресуемы "как память". Но есть и экзоты где банк регистров имеет конкретные адреса и можно с блоком регистров как с "RAM" работать. Позволяет эффектные вещи типа переключения контекста заменой 1 указателя "reg frame". Может быть а может и не быть хорошей идеей, давая старт новому классу атак когда пытаются переписать состояние проца левым доступом к памяти или сбить указатель frame. >> А какие нибудь БД так и половину абстракций ФС пересоздают > а вот зачем? Технически ФС сама что-то типа простой БД, но она general purpose. БД может иметь какие-то более специализированные хотелки как это все должно быть из соображений эффективности. В этом месте ФС ей будет скорее мешаться чем помогать, делая примерно то - но, увы, не так. Режим NOCOW в btrfs (и прочих COW кто умеет этот флаг) в частности просит отвалить в туман с медвежьими услугами если софт считает что лучше чем ФС знает как оно ему было надо. Это настолько близко к "raw разделу" насколько можно через абстракцию именно файла и ФС вывесить. При этом уровень "экстентов" и его парсинг останется, но он же дает админу и софту реаллоцировать размеры файла как надо, с raw разделом это невозможно. >> Обычные ФС могут быть нереализуемы > ага сделать sync в tmpfs (return 0) Для него эта операция не имеет логического смысла. Он будет потерян при крахе или ребуте.
	Ответить | Правка | К родителю #505 | Наверх | Cообщить модератору

	508. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 11-Ноя-23, 20:01
	> Например, https://www.st.com/resource/en/programming_manual/pm0056-stm... > - Memory Model, 2.2.5 Bit-Banding. > Такой маппинг, bit[N] <-> u32[N]. Адресов больше чем памяти, они и отмаппили. > Можно за 1 атомарную операцию конкретный бит потрогать. Это ARM для а совокупность битов? > Южный мост - частный случай. На том SoC с линем (да, я > смогу сабж там погонять) и даже этом десктопе DRAM controller в > проце. У SoC часто есть SRAM доступный "сразу", например, чтобы boot > loader подымающий DRAM (это целое действо) туда читать. И система команд > процов строится вокруг "адресации". У МК RAM и ROM сразу есть > после power up. Они все - процы и у них есть > адреса. Адрес сам по себе - число. в смысле вокруг адресов? а инструкции процессор откуда должен считывать? откуда он знает, что вот первая инструкция, вот вторая и т.д.? > А железо может такое эскалировать до > исключения. Или забить. Случаи разные бывают. У 64 бит систем 2^64 > адресов никогда полностью не аллоцированы: не бывает столько памяти у систем. ММУ это контроллирует. > "Все" - достаточно абстрактно. Даже при раннем старте - а у вас > есть 2^64 памяти? (в случае 64 бит системы). На 32-бит системе > типа МК тоже не обязано быть все 4G раскиданых от и > до. есть или нету, выявиться на этапе инициализации памяти. >> ну и регистры так же доступны, и ЦПУ (с регистрами и АЛУ) >> до лампочки есть у него ММУ блок или нет. Зависит от архитектуры. > У многих CPU регистры, внезапно, не имеют соответствующих им адресов в памяти > и не адресуемы "как память". Зависит от архитектуры ЦПУ и системы комманд (ISA). > Для него эта операция не имеет логического смысла. Он будет потерян при > крахе или ребуте. так это интерфейс который должна реализовать любая ФС, иначе нет смысла вообще в рам реализовывать ФС, ибо это недо-ФС получается по определению. Будет ли иметь смысл допустим реализовывать всякое кеширование в ram-based ФС?
	Ответить | Правка | К родителю #507 | Наверх | Cообщить модератору

	509. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 11-Ноя-23, 23:34
	> а совокупность битов? А для этого байты есть. Произвольные за цикл нельзя? Вы и разные байты в разных закоулках RAM за цикл не могли. Симметрия. >> процов строится вокруг "адресации". ... > в смысле вокруг адресов? Режимы адресации - часть набора команд. Это как раз про вычисление адресов команд и данных. Тоже числа. Описывающие где брать следудющую команду. Или данные для нее. > а инструкции процессор откуда должен считывать? Как правило тоже из адресов, на которые указывает число в специфичном регистре известном как PC (Program Counter), IP (Instruction Pointer) или как его там кто называет. Технически, используя асм, указатели в си, и т.п. как правило можно сделать доступ на произвольный адрес и как I-code и как D-bus. Проц это попробует. Получится ли - второй вопрос. > откуда он знает, что вот первая инструкция, вот вторая и т.д.? Поведение проца при power up регламентировано в доке, где он первую команду берет. Дальнейшее на усмотрение запустившегося софта и его соглашений. Есть еще варианты. Хардварный дебагинтерфейс типа JTAG или сервисный проц может засетапить состояние проца как считает нужным и отпустить его работать. Скажем PSP на новых AMD так x86 запускает, уже инициализировав DRAM своей фирмварью. >> адресов никогда полностью не аллоцированы: не бывает столько памяти у систем. > ММУ это контроллирует. В общем случае - железо и его конфигурация. У cortex M нет MMU но скажем попытка чтения или записи адреса 0 - воздается. Не любят в ARM null pointer. > есть или нету, выявиться на этапе инициализации памяти. На данный момент систем с 2^64 байтов в 1 системе не существует, на это можно расчитывать. ... > так это интерфейс который должна реализовать любая ФС, Он может быть и весьма номинальным, как тот пример. > ли иметь смысл допустим реализовывать всякое кеширование в ram-based ФС? Кеширование RAM в RAM? Я знаю только 1 осмысленный сценарий, zram. Там paging и проч юзается чтобы страницы еще и сжать. Когда страница потребуется - до того как ее отдать ее сперва распакуют. Но это не совсем кеширование, это креативное использование paging для "сжатия оперативки".
	Ответить | Правка | К родителю #508 | Наверх | Cообщить модератору

	510. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 12-Ноя-23, 17:00
	> Технически, используя асм, указатели в си, и т.п. как правило можно сделать > доступ на произвольный адрес и как I-code и как D-bus. Проц > это попробует. Получится ли - второй вопрос. зависит еще в какой регион памяти попадет там же "The processor has a fixed memory map that provides up to 4 GB of addressable memory. " > Кеширование RAM в RAM? Я знаю только 1 осмысленный сценарий, zram. Там > paging и проч юзается чтобы страницы еще и сжать. Когда страница > потребуется - до того как ее отдать ее сперва распакуют. Но > это не совсем кеширование, это креативное использование paging для "сжатия оперативки". formerly called compcache ("compressed cache") :) zram can then be used for swap
	Ответить | Правка | К родителю #509 | Наверх | Cообщить модератору

	512. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 12-Ноя-23, 21:00
	> зависит еще в какой регион памяти попадет там же "The processor has > a fixed memory map that provides up to 4 GB of addressable memory. " Более универсально сказать у памяти могут быть "права доступа" или регион может не принадлежать ничему вообще и доступ в него не обязан завершиться успехом или иметь какой-то смысл. Но инициировать это действо чаще всего возможно, и как выполнение кода, и как доступ к данным для команд проца (в неймане нет отличий - потому и нейман). > zram can then be used for swap Это сжатое блочное устройство в оперативке. Своп это одно из частных применений но с ним можно делать все что можно делать с "блочным устройством" (например разделы создать, ФС разложить, ...). Интересно в основном прозрачным сжатием. Доволльно быстрым если это LZ4 или LZO+RLE. В силу блочности есть нехилые ограничения: если 2 страницы (как вариатн 3) удалось в 1 сжать, окей, выигрыш. А если сжалось лишь немного - оно таки с округлением до страниц и выигрыша не будет. Но оперативка хорошо жмется и по факту - можно вот выгрузить откровенно холодные страницы в сжатый вид, но если они все же потребуются, взять их из RAM и распаковать не идет ни в какое сравнение с механическим диском, и в отличие от SSD не протирается записями. Так что довольно полезная штука, я этим все свопы и позаменял. И системы отзывчивее, и неиспользуемые страницы, вот, пакуются, больше RAM тем кому она нужна за счет этого.
	Ответить | Правка | К родителю #510 | Наверх | Cообщить модератору

	233. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 06:20
	Еще бы понять, кто кому должен ограничиваться рамками юниксовой идеологии "всё есть файл", и зачем оттуда читать по одному байту, когда перфоленты вышли из моды. Отображение в память таки давно перетянули из VMS, и ради удобного mmap() даже размер регистров адреса увеличили до 64-х разрядов. Ниже писали про дедупликацию памяти, и рядом с дедупликацией ФС получается удивительная вещь - дублирование функциональности. Я бы лучше подумал, как куски кода отправить в корзину, потому что "любая проблема в информатике может быть решена с помощью дополнительного уровня косвенности", кроме бесконечного количества таких уровней. Вот только некогда - все силы уходят на борьбу с терминологической путаницей.)
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	244. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (244), 01-Ноя-23, 08:14
	> Ниже писали про дедупликацию памяти, и рядом с дедупликацией ФС получается > удивительная вещь - дублирование функциональности. Я бы лучше подумал, как куски > кода отправить в корзину, потому что "любая проблема в информатике может > быть решена с помощью дополнительного уровня косвенности", кроме бесконечного количества > таких уровней. Вот только некогда - все силы уходят на борьбу > с терминологической путаницей.) Как вы понимаете, если кто-то придумывает как сделать дедуп абстракциям - это делается. Но для этого надо осознать HOW TO. Характерный пример? Closures (да, так можно и на си!) vs bcache -> lib где это использует уже bcache и bcachefs. А со временем в ТАКОМ виде это и еще кто поюзает. Когда и если оно им станет надо.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 11:50
	Сейчас проблема не только в "надо". Архитектура ядра созревала на другом железе, в актуальных для того времени условиях. Что бы в неё вписать что-то новое, приходится искать обходные пути. Автору Bcachefs это удалось, пусть оно отчасти выглядит как костыли и не по канонам, но со временем опыт будет учтён и приведёт к изменениям, надо полагать. Шишкин, кстати, точно так же в имеющейся архитектуре тесто, просто у него своё представление, как оно должно быть
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (277), 01-Ноя-23, 14:57
	> Сейчас проблема не только в "надо". Архитектура ядра созревала на другом железе, > в актуальных для того времени условиях. Да. И когда IO стал быстрый, это стало икаться. И там своя крузада с folios, io_uring и чем там еще для снижения оверхеда операций. Одна из причин по которым файлухи вне ядра это трабла - внутренние апи довольно круто рефакторят для снижения оверхеда. > Что бы в неё вписать что-то новое, приходится искать обходные пути. > Автору Bcachefs это удалось, пусть оно отчасти выглядит как костыли и не по канонам, На btrfs было больше наездов, им сложнее было. Кенту попроще. Он уже второй в таком духе, так что меньше тупых претензий, народ уже понимает что сильно кастомный дизайн. Но со временем в идеале наверное должен появиться некий фреймворк для упрощения создания CoW. Если поймут как реюзабельные компоненты выделить. > но со временем опыт будет учтён и приведёт к изменениям, надо полагать. Шишкин, > кстати, точно так же в имеющейся архитектуре тесто, просто у него > своё представление, как оно должно быть Мне кажется что ему не понравилось бы если бы он увидел реальные проблемы реальных юзерей, сторажей и проч. Это часто бывает совсем не так как академы себе возомнили.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 17:52
	Шишкин в курсе тех проблем. Ему нет смысла вторить людям, с кем он как бы в конфронтации на данном этапе, он смотрит подальше. Если принять, что все его "наезды" на Linux адресованы на самом деле в Россию, то они заиграют новыми красками. Президент указывает развивать науку и вот это вот всё. Тут самое время кое-кому заявить "Эдуард, раз Вы такой умный, вот дюжина перспективных студентов, готовых заглядывать в рот и ловить каждое слово". Вместо этого господин с фамилией на туже букву чем занимается? Он кстати куда-то пропал отсюда, увидев цитату Линуса "show me the code".
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:05
	> Шишкин в курсе тех проблем. Я никогда не видел никаких реальных пруфов этого. А даже если и, из этого никогда не вытекало ничего полезного для меня. Не, юзать недопиленые out of tree нечто на своих данных мне не айс. А что там внутрях галеры типа хреновой дороги - мне не видно и честно говоря малоинтересно. Во всяком случае, то что на публику выгружалось хреновой дорогой воображение не поражало. Так что с моей точки зрения - теории какими бы они там красивыми ни были не привели ни к каким видимым мне практически значимым результатам. Представьте себе что электричество оказалось лишь игрушкой для пятка фриков на планете? Мы бы тогда даже не смогли тут переписываться - все это никогда просто не возникло бы. До сих пор корябали бы письма ручкой. С доставкой почтальоном и RTT от 3 дней до месяца, RFC1149 был бы суровой реальностью. > Ему нет смысла вторить людям, с кем он как бы в конфронтации на данном этапе, Я не знаю какой смысл и что ему есть. Слить/зафейлить/забить имхо на победу в конфронтации не похоже. Скорее на прострел пяток, концептуально, по македонски. > он смотрит подальше. Наверное, туда же куда участники "русский инженер" с их опросом. Во всяком случае, это наиболее реалистичная из всех перспектив. > Если принять, что все его "наезды" на Linux адресованы на самом > деле в Россию, то они заиграют новыми красками. Ох, тут и россияне уже где-то отметились как категория? > "Эдуард, раз Вы такой умный, вот дюжина перспективных студентов, готовых заглядывать > в рот и ловить каждое слово". Вместо этого господин с фамилией > на туже букву чем занимается? Он кстати куда-то пропал отсюда, увидев > цитату Линуса "show me the code". Ну, говоря за себя - я искренне сомневаюсь что нормальные файлухи появляются в природе по причине "президент приказал". Да и у студней, судя по "русскому инженеру" будет в лучшем случае фига в кармане. А то и жест Торвальдса нвидии, при том тоже за дело.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 02-Ноя-23, 09:34
	> Ну, говоря за себя - я искренне сомневаюсь что нормальные файлухи появляются > в природе по причине "президент приказал". Зато пистон за неисполнение вполне может начать вставляться. Сидят чукча с геологом. Вдруг видят — прямо на них несется белый медведь. Чукча кидается надевать лыжи. — Чукча, зачем тебе лыжи? Ты все равно не сможешь бежать быстрее медведя. — Чукче не надо бежать быстрее медведя. Чукча будет бежать быстрее геолога.
	Ответить | Правка | К родителю #328 | Наверх | Cообщить модератору

	353. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (353), 02-Ноя-23, 12:46
	> Зато пистон за неисполнение вполне может начать вставляться. Не приведет ни к чему хорошему, полезному и интересному, разве что ускорит утечку мозгов, если еще есть чему утекать. А поху и шишкину вы даже швабру можете пообещать, можно подумать на этой планете есть чудо которое превращает отшибленых овощей в нормальную софтварную команду. Возможно даже чатгпт напишет лучше чем столь мотивированные сотрудники. В отчетах, конечно, все будет зашибись. Вот как раз поэтому.
	Ответить | Правка | К родителю #349 | Наверх | Cообщить модератору

	367. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 02-Ноя-23, 14:51
	Так Шишкин утёк и давно, а вот другие что интересного сделали? Не считая легендарного Дениса Попова, наглядно показавшего суть деятельности его коллег. Овощам место на овощебазе так то.
	Ответить | Правка | К родителю #353 | Наверх | Cообщить модератору

	284. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 16:12
	> Автору Bcachefs это удалось, пусть оно отчасти выглядит как костыли и не по канонам, но со временем опыт будет учтён и приведёт к изменениям, надо полагать. удалось что? скрестить ежа и ужа? tmpfs давным давно уже создан!!!
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	292. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 17:22
	>> Автору Bcachefs это удалось, пусть оно отчасти выглядит как костыли и не по канонам, но со временем опыт будет учтён и приведёт к изменениям, надо полагать. > удалось что? скрестить ежа и ужа? Он ещё и генетик? Не знал. Слышал про анестезиолога. > tmpfs давным давно уже создан!!! Эээ... это намёк, что некоторые пихают подкачку в zram? Вот им и читайте лекции про правильную иерархию.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 19:47
	> Он ещё и генетик? Не знал. Слышал про анестезиолога. """ Philosophy, vision We prioritize robustness and reliability over features: we make every effort to ensure you won't lose data. It's building on top of a codebase with a pedigree - bcache already has a reasonably good track record for reliability Starting from there, bcachefs development has prioritized incremental development, and keeping things stable, and aggressively fixing design issues as they are found; the bcachefs codebase is considerably more robust and mature than upstream bcache. The long term goal of bcachefs is to produce a truly general purpose filesystem: scalable and reliable for the high end simple and easy to use an extensible and modular platform for new feature development, based on a core that is a general purpose database, including potentially distributed storage """" покажу где надо поржать, вот тут "The long term goal of bcachefs is to produce a truly general purpose filesystem" > Эээ... это намёк, что некоторые пихают подкачку в zram? Вот им и > читайте лекции про правильную иерархию. я могу больше не покупать рейд контроллер с ббу?
	Ответить | Правка | Наверх | Cообщить модератору

	329. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:08
	> я могу больше не покупать рейд контроллер с ббу? Лучше покажи как ты это все в свой ноут засунешь. А, ну как обычно - сапожник без сапог? Ну тогда нахрен таких сапожников, имхо, пусть лучше Кент позажигает - не такой голож@пый а потому куда убедительнее. Если его технологии работают хотя-бы для него это уже дает определенные надежды.
	Ответить | Правка | К родителю #303 | Наверх | Cообщить модератору

	366. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Ноя-23, 14:41
	> Лучше покажи как ты это все в свой ноут засунешь. "a truly general purpose" она запись на перфокарты поддерживает? > как обычно - сапожник без сапог? ну как всегда "like zfs or btrfs", ну конечно > имхо, пусть лучше Кент позажигает - не такой голож@пый а потому > куда убедительнее. "scalable and reliable for the high end" - у вас там на ноуте места для второго диска хдд осталось еще? > Если его технологии работают хотя-бы для него это уже > дает определенные надежды. based on a core that is a general purpose database, including potentially distributed storage ага распределенное хранилище на ноуте :)
	Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

	452. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 10:43
	> "a truly general purpose" она запись на перфокарты поддерживает? Без понятия: у меня таких девайсов нет. >> как обычно - сапожник без сапог? > ну как всегда "like zfs or btrfs", ну конечно Для меня btrfs неплохо работает в моих сценариях. А zfs слишком энтерпрайзный и внеядерный для меня, пусть им похи пользуются, имхо. Меня интересуют менее энтерпрайзные случаи, типа моего ноута, одноплатников, да даже на роутере-мыльнице цепляется. А энтерпрайзные хранилки в чистом виде - не ко мне, меня именно "general purpose" аспект интересует. > "scalable and reliable for the high end" - у вас там на > ноуте места для второго диска хдд осталось еще? В случае btrfs я сделал схему DUP, от рандомного бэда - норм. Да, емкость стоража при этом ополовинится. Зато надежность растет. Даже там где второй девайс поставить нельзя :P. От полного отказа не спасет, конечно, но от мелких случайных пакостей вполне. В целом выживаемость ФС с избыточностью куда лучше. > ага распределенное хранилище на ноуте :) Хорошие технологии должны быть масштабируемы. Чему бы его core на минималочках на ноут не пойти я хз.
	Ответить | Правка | К родителю #366 | Наверх | Cообщить модератору

	464. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 04-Ноя-23, 17:52
	> А энтерпрайзные хранилки в чистом виде - не ко мне, > меня именно "general purpose" аспект интересует. ну давайте по пунктам определим так называемый "general purpose", что это за понятие такое? дедупликация, сжатие, шифрование и т.д. даже в энтерпрайзе не "general purpose". > В целом выживаемость ФС с избыточностью куда лучше. То есть ФС по вашему должна уметь выживать? Согласен лишь с тем, что избыточность это один из механизмов выживания, но давайте посмотрим на историю ФС, какая из них заведомо проектировалась с избыточностью хранения данных? Это вообще функция ФС? Кто это определял? Почему избыточность не функция драйвера устройства, ибо ему яснее как работает собственно устройство, и как там можно правильно организовать избыточное хранение? За место этого всего мы придумываем новые слои абстракции просовываясь между уровнями ФС и самих устройств хранения. > Хорошие технологии должны быть масштабируемы. Чему бы его core на минималочках на > ноут не пойти я хз. хорошие микроскопы должны уметь забивать гвозди ;)
	Ответить | Правка | К родителю #452 | Наверх | Cообщить модератору

	489. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 14:07
	> ну давайте по пунктам определим так называемый "general purpose", что это за > понятие такое? По пунктам сложно, но идеальная ФС должна обеспечивать абстракцию работы с файлами с минимальным оверхедом по пространству стоража и времени операций. И делать это одинаково хорошо независимо от характера задач. Не требуя обслуживания и внимания, кроме возможно переконфигурации под иные задачи. Но это слишком хорошо чтобы быть правдой. General purpose означает что ФС не спасует на всех или хотя-бы многих задачах с которыми сталкиваются ФС и может работать с широким спектром допущений. > дедупликация, сжатие, шифрование и т.д. даже в энтерпрайзе не "general purpose". Чем больше у ФС возможностей, тем в большее число задач она сможет вписаться. Если из-за этого не возникнет иных препятствий. Как пример: btrfs vs ZFS. Я могу btrfs на одноплатниках с 256 мегов RAM и 1 SD или eMMC использовать. Нормально работает а схема DUP повышает надежность. Или ноут с 1 диском. И так далее. ZFS в тех конфигах не в тему, поэтому ИМХО ближе к специализированным ФС с уклоном в "энтерпрайзные хранилки". Райды с батарейкой туда же. Специализированные железки это антипод general purpose. >> В целом выживаемость ФС с избыточностью куда лучше. > То есть ФС по вашему должна уметь выживать? Согласен лишь с тем, В идеале ФС не должна требовать внимания, кроме переконфигурации под иную задачу. Это часть того пожелания на самом деле. Туда же всякие fsck/ckdisk и что там еще. > что избыточность это один из механизмов выживания, но давайте посмотрим на > историю ФС, какая из них заведомо проектировалась с избыточностью хранения данных? Это история проб и ошибок. И далеко не все страницы написаны. > Это вообще функция ФС? Кто это определял? Почему избыточность не функция > драйвера устройства, ибо ему яснее как работает собственно устройство, Как аргументы "за" мне видится: 1) Драйвер не знает о других устройствах и их состоянии, BigPic не его прерогатива. 2) Возможность использования разнородных устройств - фича, можно использовать все ассеты которые есть, "по ситуации". Вплоть до того что btrfs можно временно расширить подоткнув нечто в usb, а потом и вынув это из пула. Удобно для каких-то разовых маневров. 3) Драйвер на уровне блочного интерфейса не знает нужен ли этот блок здесь и сейчас. TRIM лишь частичный костыль, не решает все проблемы. ФС виднее что используется а что нет. 4) По той же причине снапшоты на блочном уровне мучительны и неэффективны. 5) ФС с несколькими девайсами, или 2 копиями на 1 девайсе может использовать продвинутые техники рекавери, запросив другую копию и поняв по чексумам какая верная, починив в фоне. Это точно не прерогатива драйвера конкретного устройства и так получается гибче и меньше допущений что за железо, драйверы и какое у них умение. > и как там можно правильно организовать избыточное хранение? За место этого всего мы > придумываем новые слои абстракции просовываясь между уровнями ФС и самих устройств > хранения. Есть еще соображения: 1) Использование уже имевшихся ассетов и возможность их реаллокации и реконфигурации. 2) Гибкость менеджмента. И его сложность. 3) Общая стоимость всего этого. Железо не бесплатное, специализированное - очень дорогое. Требование хранить на складе эн винчей - денег людям стоит. И так далее. Чем меньше этого всего, тем лучше, имхо. >> Хорошие технологии должны быть масштабируемы. Чему бы его core на минималочках на >> ноут не пойти я хз. > хорошие микроскопы должны уметь забивать гвозди ;) Знаете чем мы отличаемся? Вы видите микроскопы и молотки. Я же освоил более продвинутые концепции и вижу пространство, время, энергию и эн атомов материи. Они могут стать чем угодно в пределах этих constraint. Надо - собираем в молоток. Изменились требования, станет микроскоп. И так далее. И это лишь наполовину sci-fi, это скорее предсказание. Цель к которой многие стараются прийти. В управлении цифровыми системами это стало уже можно сейчас.
	Ответить | Правка | К родителю #464 | Наверх | Cообщить модератору

	499. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 09-Ноя-23, 01:26
	> По пунктам сложно, сложно, но в то же время "Чем больше у ФС возможностей, тем в большее число задач она сможет вписаться." почему бы и нет, ок, принято. Зачем вообще нужна ОС если есть ФС - лол, кек. > General purpose означает что ФС нету этого general purpose формального, никто его не описывал. Ибо это всё еще со времен Танненбаума вливается в спор, микро ядро или монолит. Определитесь!!! > Специализированные железки это антипод general purpose. то есть вы хотите сказать, что линукса на серверах меньше чем на ноутах? Учитывая еще тенденцию что линукс на серверах "bare metal" давным давно уже не стоит. > Как аргументы "за" мне видится: > 1) Драйвер не знает о других устройствах и их состоянии, BigPic не > его прерогатива. ФС должна знать? > 2) Возможность использования разнородных устройств - фича, можно использовать все ассеты > которые есть, "по ситуации". Вплоть до того что btrfs можно временно > расширить подоткнув нечто в usb, а потом и вынув это из > пула. Удобно для каких-то разовых маневров. Если бы в ОС была одна единая ФС, то может ОС автоматом любое блочное устройство отображало бы в ФС, и не нужны были бы всякие форматирования и танцы с бубном, но этого нет, ос видит блочное устройстчо, а какую ФС ты хош ту и накатывай, но в итоге твои программы имеют один интерфейс ФС взаимодействия - открой файл, запиши, закрой. Как будет организовано хранение файлов это уже дело ФС. И ОС до лампочки. > 3) Драйвер на уровне блочного интерфейса не знает нужен ли этот блок > здесь и сейчас. TRIM лишь частичный костыль, не решает все проблемы. > ФС виднее что используется а что нет. ФС разве будет знать для чего в ОС используется файл /etc/passwd ? О файлах знает только конечная пользовательская программа. > 4) По той же причине снапшоты на блочном уровне мучительны и неэффективны. В смысле мучительны и не эффективны? я не понимаю. > 5) ФС с несколькими девайсами, или 2 копиями на 1 девайсе может > использовать продвинутые техники рекавери, запросив другую копию и поняв по чексумам > какая верная, починив в фоне. Это точно не прерогатива драйвера конкретного > устройства и так получается гибче и меньше допущений что за железо, > драйверы и какое у них умение. а чем копия файла отличается от копии блока данных и т.д.? уровнем абстракции? > Железо не бесплатное, специализированное - очень дорогое. Требование хранить на складе > эн винчей - денег людям стоит. И так далее. Чем меньше > этого всего, тем лучше, имхо. санкции говорят об обратном, всегда надо хранить на складе горячий резерв :) > Надо - собираем в молоток. Изменились требования, станет микроскоп. И так далее. Вот когда "надо", оказывается всегда, что поздно.
	Ответить | Правка | К родителю #489 | Наверх | Cообщить модератору

	511. "Код 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 минуты и подымает мне привычное окружение. Ну что, пилот этажерки, рассказал капитану звездолета как тяги правильно дергать? > санкции говорят об обратном, всегда надо хранить на складе горячий резерв :) Я всем этим заниматься не собираюсь. Потому что не склад жестких дисков, это не бесплатно и создает неудобства. Поэтому я предпочитаю менеджмент ОС когда можно подцепить то что есть по мере надобности. Без делания мозга. И динамически реаллоцировать ресурсы на задачу. >> Надо - собираем в молоток. Изменились требования, станет микроскоп. И так далее. > Вот когда "надо", оказывается всегда, что поздно. Это у вас - поздно. А я динамическое реконфигурирование и реаллокацию ресурсов на задачу полюбил не просто так. А как раз чтобы поздно - не было. И я искренне сомневаюсь что вы дадите мне мастеркласс на эту тему, кмк мы принадлежим к сильно разным эпохам технологий.
	Ответить | Правка | К родителю #499 | Наверх | Cообщить модератору

	515. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 13-Ноя-23, 17:25
	> А я динамическое реконфигурирование и реаллокацию ресурсов на задачу полюбил не просто так. А как раз чтобы поздно - не было. тут главный вопрос - где взять эти ресурсы? :) > И я искренне сомневаюсь что вы дадите мне > мастеркласс на эту тему, кмк мы принадлежим к сильно разным эпохам > технологий. ага, видел я вашу эпоху - метаданные в кластере касандры, а данные на ext2 :)
	Ответить | Правка | К родителю #511 | Наверх | Cообщить модератору

	517. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 13-Ноя-23, 19:15
	> тут главный вопрос - где взять эти ресурсы? :) А вот это уже решаемо при достаточной степени креативности. Скажем если есть диск с дофига места но там нужные данные, можно на неаллоцированом месте диск-в-файле сделать, дать ЭТО как девайс бтрфс на время, это не оптимально, зато никакого дестроя и агрессивное маневрирование тем что было с минимальными допущениями. А возможность добавить-снести позволяет сделать что надо. Даже если это было на 1 раз и проч. Видите, при перспективе впечататься в планету я могу включить гипердрайв на наносекунды, проскочить на другую сторону - и рематериализоваться там. А если вы так не могли - suxx to be you. > ага, видел я вашу эпоху - метаданные в кластере касандры, а данные на ext2 :) Это видимо не наша эпоха и/или альтернативная версия реальности была. В нашей -rc1 для 6.7 вышел и пора посмотреть что может дизайн Кента.
	Ответить | Правка | К родителю #515 | Наверх | Cообщить модератору

	519. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 13-Ноя-23, 22:04
	> Видите, при перспективе впечататься в планету я могу включить гипердрайв на наносекунды, > проскочить на другую сторону - и рематериализоваться там. А если вы > так не могли - suxx to be you. могу вас поздравить, можете уже на аттосекунду гипердрайвить :) > Это видимо не наша эпоха и/или альтернативная версия реальности была. В нашей > -rc1 для 6.7 вышел и пора посмотреть что может дизайн Кента. мульти-вселенная :))))))
	Ответить | Правка | К родителю #517 | Наверх | Cообщить модератору

	282. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 16:10
	> Ниже писали про дедупликацию памяти, и рядом с дедупликацией ФС получается > удивительная вещь - дублирование функциональности. еще сжатие, шифрование, ага еще и кеширование О_о, да да будем еще кешировать энергозависимую память > потому что "любая проблема в информатике может > быть решена с помощью дополнительного уровня косвенности", кроме бесконечного количества > таких уровней. ага сложим все яйца в одну корзину, навернем ее, а потом будем искать решения как вылавить скорлупу > Вот только некогда - все силы уходят на борьбу с терминологической путаницей.) потому-что в CS (компухтер сайнс) нет строгого формализма, нет четких определений, нет системы, нет исследований архитектурных, фундаментальных. Есть только "накидалово", и одни и те же грабли из поколений в поколения.
	Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

	290. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 17:17
	>> Ниже писали про дедупликацию памяти, и рядом с дедупликацией ФС получается >> удивительная вещь - дублирование функциональности. > еще сжатие, шифрование В смысле, криптографическое преобразование? При чём здесь оно? Если для оптимизации поиска от данных считается "хеш", то нет даже смысла предъявлять к нему требование необратимости - поскольку ссылка на данные всё равно хранится рядом. >  ага еще и кеширование О_о, да да будем еще кешировать энергозависимую память Почему будем? Кеши давно интегрированы в ЦП. > потому-что в CS (компухтер сайнс) нет строгого формализма, нет четких определений, нет > системы, нет исследований архитектурных, фундаментальных. Есть только "накидалово", > и одни и те же грабли из поколений в поколения. Гипотеза Сепира — Уорфа объясняет кашу сию.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 19:41
	> В смысле, криптографическое преобразование? При чём здесь оно? нет, как одно из требований безопасности, как в случае с кешированиеь - это требование к "скорости" операций i/o. > Почему будем? Кеши давно интегрированы в ЦП. ага сендвич такой L1, L2, L3, DRAM, NVMe, SSD, HDD, Tape, и всякая "лента с дырками" > Гипотеза Сепира — Уорфа объясняет кашу сию. Термин "гипотеза" не объясняет, а предполагает. А каша из-за того, что современное понятие "во-IT" давно уже не CS.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:13
	Понимаете, достопочтенный сэр, все ваши философствования очень недорого стоят, если в результате система на ноуте скончается от единственного бэда за пяток лет - а у вас не было никаких планов и решений на такие оказии. А то что я "должен" таскать контроллер райда с батарейкой... знаете, я у вас ничерта не занимал, поэтому ничерта я не должен вам с такими загонами. А вот тем кто момогает мне что-то сделать с насущными, земными проблемами, наверное, надо бы, таки, помочь. Для блага собственного окорока хотя-бы, чтобы не сидеть с вон той голой джеппой :)
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 02-Ноя-23, 13:47
	> Понимаете, достопочтенный сэр, все ваши философствования очень недорого стоят, если в результате > система на ноуте скончается от единственного бэда за пяток лет - > а у вас не было никаких планов и решений на такие > оказии. разве появления "бэда" это проблема моей системы? и раз срок вашего оборудования 5 лет, то зачем ждать появления "бэда", если можно менять каждые 4 года. > Для блага собственного окорока хотя-бы, чтобы не сидеть с вон той голой джеппой :) продолжаем думать нижним полушарием мозга.
	Ответить | Правка | Наверх | Cообщить модератору

	428. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 16:21
	> разве появления "бэда" это проблема моей системы? и раз срок вашего оборудования > 5 лет, то зачем ждать появления "бэда", если можно менять каждые 4 года. Можете хоть раз в месяц! Но - за ваш счет и в ваше время, у себя. А бэды таки вероятностный процесс, и может вылести и через месяц. И через год. И через три. Для меня вопрос - "насколько часто". Если чаще 1-2 бэдов в год, окей, может быть железка сыпется. Если сильно чаще, повод чинить/менять, ессно. А такой разовый взбрык - сервисменами за проблему вообще не считается, весьма типичное явление. >> Для блага собственного окорока хотя-бы, чтобы не сидеть с вон той голой джеппой :) > продолжаем думать нижним полушарием мозга. А я предпочитаю более продвинутые подходы. Это включает и чтобы технологии работали на меня, а не были "где-то там". Сапожники без сапог ничего кроме презрения не вызывают, увы и ах.
	Ответить | Правка | К родителю #356 | Наверх | Cообщить модератору

	438. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 03-Ноя-23, 18:14
	> А я предпочитаю более продвинутые подходы. заиметь сначала сапоги, а потом стать сапожником?
	Ответить | Правка | К родителю #428 | Наверх | Cообщить модератору

	453. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 11:26
	>> А я предпочитаю более продвинутые подходы. > заиметь сначала сапоги, а потом стать сапожником? Вполне рабочая тема как по мне. Если пытаться изобретать сапоги с ноля, игноря существующие варианты напрочь, врядли что хорошее получится. В этом смысле чем больше дизайнов видел архитект, и чем больше данных о их проблемах было, тем лучше будет очередная итерация, имхо.
	Ответить | Правка | К родителю #438 | Наверх | Cообщить модератору

	463. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 04-Ноя-23, 17:37
	> В этом смысле чем больше дизайнов видел архитект, и чем больше данных о их > проблемах было, тем лучше будет очередная итерация, имхо. Разве сыт будет человек, наблюдая за тем как ест другой?
	Ответить | Правка | К родителю #453 | Наверх | Cообщить модератору

	487. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 09:15
	>> В этом смысле чем больше дизайнов видел архитект, и чем больше данных о их >> проблемах было, тем лучше будет очередная итерация, имхо. > Разве сыт будет человек, наблюдая за тем как ест другой? Если пример проинвертировать... Если вы не знаете как выглядит еда и понятия не имеете как ее готовить и что может получиться в результате, ваши шансы сделать что-то съедобное и тем более вкусное и питательное - резко понижаются. Почему-то.
	Ответить | Правка | К родителю #463 | Наверх | Cообщить модератору

	498. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 09-Ноя-23, 01:00
	> Если пример проинвертировать... > Если вы не знаете как выглядит еда и понятия не имеете как > ее готовить и что может получиться в результате, ваши шансы сделать > что-то съедобное и тем более вкусное и питательное - резко понижаются. > Почему-то. если вы лишены чувства голода, о какой сЪедобности может идти речь? Мне без разницы как, что выглядит, если это утоляет мой голод. Будучи голодным на необитаемом острове вы сожрете все то, от чего в обыденной жизни ворочили бы нос. Так вот.
	Ответить | Правка | К родителю #487 | Наверх | Cообщить модератору

	503. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Ноя-23, 23:11
	> если вы лишены чувства голода, о какой сЪедобности может идти речь? Если вы совсем лишены чувства голода то я вижу 2 опции. 1) Вам вообще не требуется эта абстракция и тогда нет смысла это обсуждать. Может вы фотосинтезируете, или вообще нечто гибридное, типа какого-нибудь искусственного тела или сферы дайсона, там это может не иметь никакого смысла или подразумевать нечто совсем иное. 2) Иначе вы, вероятно, довольно скоро умрете по причине "отсутствие критичного сигнала" который так то мониторил "проблемное условие". > Мне без разницы как, что выглядит, если это утоляет мой голод. Если у вас нет чувства голода - то и утолять его не требуется. А так - добро пожаловать в китай, и прочие специфичные страны, они покажут что они могут жрать. Будет интересно посмотреть насколько вы готовы сожрать то же что и они подтвердив свои слова делом. > Будучи голодным на необитаемом острове вы сожрете все то, от чего в > обыденной жизни ворочили бы нос. Так вот. А при отсутствии оперативы - вы ее и механической крутилкой с горя эмулировать будете. Не означает что это офигенно работает. Ну и в обычной ситуации - вот вы каких нибудь тараканов сами и жрите, если хотите. А что, некоторые и такое могут сожрать. А если идею доразвить и забросить вас на марс - вы таки можете и в ящик сыграть, за отсутствием съедобных "абстракций" в достаточном количестве. Ну вот не взлетела там биохимия в должном объеме и нужной абстракции просто нет.
	Ответить | Правка | К родителю #498 | Наверх | Cообщить модератору

	32. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Вася (??), 31-Окт-23, 09:46
	а чего не так, он хороший вопрос задал - такие вещи обычно закладываются архитектурно. да, оно экспериментальное - но при этом ей уже 3 года и ее берут в состав ядра. Вероятно, это значит, что некоторую стабильность она все же имеет.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	39. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 10:05
	> а чего не так, он хороший вопрос задал - такие вещи обычно > закладываются архитектурно. Оно и заложено архитектурно. Какая из букв в "CoW" тебе не понятна?
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (45), 31-Окт-23, 10:16
	Тут скорее именно вам стоит разобраться в предметной области: CoW и дедупликация - это ортогональные понятия. Наличие CoW не означает обязательное наличие дудпликации. Как и наличие дудпликации не означает обязательного наличия CoW. Например, как вы даже при наличии CoW собираете определять дублирующийся блок, если у вас в метаданных не предусмотрено хранение хэша блока? А ведь и просто хранить хэш мало, ещё нужно уметь эффективно в процессе записи искать совпадения по всей таблице этих хэшей. Как вам тут CoW поможет?
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (5), 31-Окт-23, 10:19
	> Например, как вы даже при наличии CoW собираете определять дублирующийся блок, если > у вас в метаданных не предусмотрено хранение хэша блока? Посчитать. С остальным не вижу смысла за тебя разбираться.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (45), 31-Окт-23, 10:31
	> Посчитать. При записи каждого нового блока будем вычитывать данные из всей ФС, чтобы посчитать хеши для всех уже записанных блоков? Оригинальное решение, конечно
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от User (??), 31-Окт-23, 11:13
	"Идите нафиг, мыши! Я стратег, а не тактик!" (Ц)
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 13:07
	Ты, конечно, удивишься, но архитектура ПО и алгоритмы верхнего уровня - это стратегия, а не тактика. А умение скопировать со Стековерфлоу реализацию CRC32 в программированию вообще не относится.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от User (??), 31-Окт-23, 20:15
	Делоите хорошо - а плохо не делоите! Я тоже могу в архитектуру!
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 23:36
	> Делоите хорошо - а плохо не делоите! Я тоже могу в архитектуру! Ну так где твои дизайны и твоя команда, архитект? :)
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от User (??), 01-Ноя-23, 07:29
	>> Делоите хорошо - а плохо не делоите! Я тоже могу в архитектуру! > Ну так где твои дизайны и твоя команда, архитект? :) Где мои деньги? Насобираешь на патреоне тысячи хотя бы три - приходи, поговорим.
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 08:19
	>>> Делоите хорошо - а плохо не делоите! Я тоже могу в архитектуру! >> Ну так где твои дизайны и твоя команда, архитект? :) > Где мои деньги? Насобираешь на патреоне тысячи хотя бы три - приходи, поговорим. Если я насобираю на патреоне тыщи три - зачем мне вы? Есть подозрение что из всех кто сюда притусил я возможно один из самых продвинутых в структурах современных файлух. И без понятных мне пруфов что вы взяли хотя-бы такой уровень, вы от меня не получите ни цента.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от User (??), 01-Ноя-23, 19:51
	Ну вот и все у вас так - денег нет, но чего-то требуете. Не можете не патреоне - ну вот на онлифанс сходите, что ли...
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	331. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (331), 02-Ноя-23, 05:16
	> Ну вот и все у вас так - денег нет, но чего-то требуете. > Не можете не патреоне - ну вот на онлифанс сходите, что ли... Я вообще не подписывался вашим манагером или клерком работать. Так что вы и ходите, если вам это надо. Кент вот почему-то от меня не требует куда-то ходить, и при прочих равных это его конкурентное преимущество над вами. Так что мои ресурсы получит он, как более перспективный кандидат.
	Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

	228. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 05:51
	Пока ты даже не смог прочесть #105 и увидеть там алгоритм, которому ваши бзики с O(n!) не требуются.
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	242. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от User (??), 01-Ноя-23, 07:43
	> Пока ты даже не смог прочесть #105 и увидеть там алгоритм, которому > ваши бзики с O(n!) не требуются. Уоу! Ща напишу Кенту чтоб реализовал - описание хорошее, подробное - в три строчки уложилось, наверное быстро справится, да?
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 08:37
	>> Пока ты даже не смог прочесть #105 и увидеть там алгоритм, которому >> ваши бзики с O(n!) не требуются. > Уоу! Ща напишу Кенту чтоб реализовал - описание хорошее, подробное - в > три строчки уложилось, наверное быстро справится, да? Как показать всему миру что вы ламо? Попытаться поумничать не будучи вхожим в тему. Кенту вообще-то надо не так уж и много: уметь в 3 IOCTL'а в его ФС: ioctl_ficlone, ioctl_ficlonerange, и ioctl_fideduperange. Это покрывает весь ассортимент дедупа и рефлинков которые можно в линухе. Остальное - дедупалки сами умеют, by design, и им класть что там за чексумы у ФС, они сами дубликаты ищут, как им удобнее, не уповая на чексумы ФС. В вон те ioctl'ы чексумы файлух не входят, дедупалка ничего про это не знает. Она сама находит дупы как ей удобно и сабмитит кандидатов файлухе. Такой вот интерфейс. В нем фигурируют файлы и смещения. Дальше это уже проблемы файлухи что она сделает с этим знанием. По идее должна проверить что и правда - совпадает, и если и правда так, поставить на одного из новый референс и деаллоцировать другого. Для CoW это в общем то штатные операции и оно 95% этого всяко умеет, для реализации CoW/снапшотов и проч. При том как минимум частичные кишки вот этого вот - я даже в коде bcachefs вижу. Линух делает какую-то достаточно дурацукю индирекцию, поэтому я пока не полностью одуплил что из этого и в каком виде реально можно уже дергать в вот этой версии bcachefs, но кент явно в курсе всех этих вещей и как минимум основу накатал.
	Ответить | Правка | Наверх | Cообщить модератору

	305. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от User (??), 01-Ноя-23, 19:53
	Угу. Но ответ на стартовый вопрос - "нету", так?
	Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

	490. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 14:28
	> Угу. Но ответ на стартовый вопрос - "нету", так? Похоже что ответ все же "да". В коде угадывается характерный ioctl с интерфейсом "как у btrfs" и он там явно не для красоты. Насколько эта команда в этом бортовом компьютере этого крейсера реально работает станет понятнее когда -rc1 выкатят. Кент все же не зря 10 лет пахал. По коду видно.
	Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

	267. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 11:52
	Напиши, конечно. В рассылку и кидай сюда ссылку. Будем знать героев, кто принял юзерленд за ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (320), 02-Ноя-23, 00:39
	> Напиши, конечно. В рассылку и кидай сюда ссылку. Будем знать героев, кто > принял юзерленд за ядро. Я уже кажись локализовал кусок отвечающий за дедуп, на вид сделан примерно как у бтрфсников, т.е. умеет только "неточный" дедуп когда файлуха может урезать осетра и дедупнуть меньше чем запрошено. Насколько это еще и работает - после -rc1 станет понятнее.
	Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

	100. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 12:53
	Открою тебе секрет - контрольную сумму, если она уже есть в метаданных, следует считать и при чтении, что бы отловить деградацию данных или ошибки в ФС.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	102. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (5), 31-Окт-23, 12:59
	> При записи каждого нового блока будем вычитывать данные из всей ФС, чтобы > посчитать хеши для всех уже записанных блоков? Оригинальное решение, конечно Не угадал. Я напишу три буквы: CBC. Ты примешься сначала гуглить расшифровку этой аббревиатуры, потом читать, что это такое и в каких случаях требуется. Если случится чудо, то до тебя дойдёт, что лучше бы ты дальше рассказывал, что криптовалюта спасёт мир от злых банкиров, а не писал вот это вот всё.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	107. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (244), 31-Окт-23, 13:17
	>> Посчитать. > При записи каждого нового блока будем вычитывать данные из всей ФС, Так тут вроде про _оффлайн_ дедуп. А вы про откровенный такой онлайн. Такое требование только для онлайн дедупа есть. > чтобы посчитать хеши для всех уже записанных блоков? Оригинальное решение, конечно Программы дедупалки почти так и работают. С той разницей что они могут вести базу хешей и пытаться ресканить только изменения, если по умному. Онлайн дедуп видите ли подперт реальным временем и это заставляет хранить все мыслимые хеши в оперативе, хешировать на ходу, постоянно лукапать то что нахешировалось в немеряном списке кандидатов, и это получается накладно и по RAM и по CPU так то.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	111. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 13:30
	>>> Посчитать. >> При записи каждого нового блока будем вычитывать данные из всей ФС, > Так тут вроде про _оффлайн_ дедуп. А вы про откровенный такой онлайн. > Такое требование только для онлайн дедупа есть. И то, если делать непосредственно при записи. Что не обязательно и не факт, что быстрее.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (105), 31-Окт-23, 13:04
	> Тут скорее именно вам стоит разобраться в предметной области: CoW и дедупликация > - это ортогональные понятия. Наличие CoW не означает обязательное наличие дудпликации. Вообще, CoW технически как правило означает "достаточно гибкий аллокатор" для возможности вот это самое, и метаданные способные в "write anywhere layout" (или какое-то приближение). И к этому приделать возможность сослаться на 1 экстент эн раз - решаемо. Какой-то эрзац даже к ZFS прикрутили, хоть и через десяток лет. CoW делает ключевую вещь: когда копии расходятся, он пишет измененную часть в сторонку. Вот без этой части - у вас точно не получится. А с остальным более-менее можно жить с теми или иными сложностями. Для поддержания иллюзии независимости копий файла главное это вон то. А что там надо костыльнуть чтобы >1 раза на регион сослаться - от "ничего" до "терпимо". > Как и наличие дудпликации не означает обязательного наличия CoW. Наличие CoW обычно таки означает достаточно гибкую аллокацию - и умение разбивать разошедшиеся версии. А сама по себе возможность сослаться 2 раза (и даже эн раз) на 1 аллоцированый регион мало чему противоречит. > Например, как вы даже при наличии CoW собираете определять дублирующийся блок, если > у вас в метаданных не предусмотрено хранение хэша блока? Ну вот так: 1) Прога-дедубликатор сама считает хеши. 2) Найдя кандидаты она сабмитит их IOCTL "same extent" 3) Файлуха может дополнительно прочекать что блоки идентичны и если все прокатило, вторая копия заменяется ссылью на первую и после этого можно де-аллокацию дубликату сделать. Это то как реально работают bees, jdupes, duperemove, ... и в этой схеме нигде нет никакого требования для хранения хешей блоков. Такая ерунда. Более того - это вроде на минималках даже на ZFS как-то прикрутили (рефлинки примерно так же работают) хотя там даже и экстентов толком нет. > А ведь и просто хранить хэш мало, ещё нужно уметь эффективно в процессе > записи искать совпадения по всей таблице этих хэшей. Как вам тут CoW поможет? CoW ключевой компонент для поддержания иллюзии независимости копий в рантайме. Остальное так или иначе можно обыграть с умеренным костылированием.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	109. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 13:28
	> Ну вот так: > 1) Прога-дедубликатор сама считает хеши. > 2) Найдя кандидаты она сабмитит их IOCTL "same extent" > 3) Файлуха может дополнительно прочекать что блоки идентичны и если все прокатило, > вторая копия заменяется ссылью на первую и после этого можно де-аллокацию > дубликату сделать. И кстати этот алгоритм годится даже для прозрачной дедупликации, если запускать его в фоне. Как оно делается для страниц ОЗУ.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 13:36
	> И кстати этот алгоритм годится даже для прозрачной дедупликации, если запускать его > в фоне. Как оно делается для страниц ОЗУ. Ну так в лине и есть KSM - это такой инверсный вариант RCU, когда идентичные страницы можно сколлапсировать. А RCU так то - диалект CoW по смыслу, без него опять же нихрена не получилось бы т.к. при расхождении копий надо уметь их разбивать на независимые куски.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 31-Окт-23, 13:49
	Точнее, таблица страниц позволяет реализовать и CoW, и KSM. Если где-то реализовано CoW, значит есть аналог той таблицы. Следовательно, архитектура позволяет дедупликацию.
	Ответить | Правка | Наверх | Cообщить модератору

	287. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Sw00p aka Jerom (?), 01-Ноя-23, 16:31
	> эффективно в процессе записи вам еще не возразили, зачем это делать в процессе записи? Для начала надо понимать четко, что есть дедупликация, какова ее функция, где необходима и т.д., а не задаваться вопросом есть ди в той или иной ФС функция дедупликации, а если ее там нет то фиии плохая фс (ФСпалм)
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	71. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Вася (??), 31-Окт-23, 11:29
	>> а чего не так, он хороший вопрос задал - такие вещи обычно >> закладываются архитектурно. > Оно и заложено архитектурно. Какая из букв в "CoW" тебе не понятна? D
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	99. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноньимъ (ok), 31-Окт-23, 12:52
	Вроде нет, и надеюсь не будет.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	125. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (125), 31-Окт-23, 14:43
	здорово, что твоё мнение можно не учитывать
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от _oleg_ (ok), 31-Окт-23, 13:43
	А нахрена? Предпоследний абзац содержит перечисление всех особенностей ФС. При всём этом наборе её код 100% и так достаточно наворочен. Нахрена туда ещё пихать сомнительную дедупликацию, которую можно сделать другими средствами?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	168. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ИмяХ (?), 31-Окт-23, 18:00
	Там наоборот, дубликация за счёт кэширования.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	201. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 23:42
	> Там наоборот, дубликация за счёт кэширования. Там хитрее! Кеширование и избыточность достаточно изящно интегрированы в единое целое, так что аллокатор учитывает и пожелания к скорости и - вот - требования избыточности. Поэтому дубликации столько сколько запрошено на основании схемы хранения. А кеш "мигрирует". В том смысле что место на более медлленном девайсе если оно не надо для вон того уровня избыточности может быть деаллоцировано и отдано чему-то еще. В блочном дизайне вы так ессно не сможете. Потому что понятия не имеете кому принадлежат блоки, используются ли они и потребуются ли они когда либо еще. Эти знания теряются на границе блочного уровня.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (206), 01-Ноя-23, 02:04
	На самом деле тоже интересно, потому что его можно использовать как блочный девайс по аналогии с zvol, то это шикарно ляжет на виртулизацию
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	249. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 09:03
	> На самом деле тоже интересно, потому что его можно использовать как блочный > девайс по аналогии с zvol, то это шикарно ляжет на виртулизацию Это должно идти туда же куда и DB на RAW разделах примерно. И пойдет. За то же самое, ага. Потому что по линии менеджмента это треш и угар. А самый кайф это сделать ФС которая не будет сливаться на типовых ворклоадах сама по себе, без вот этого угробище-костыля "наша ФС гамно, поэтому можете свою поверх нас запустить".
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (250), 01-Ноя-23, 09:03
	В опенсорсном Virtual Data Optimizer (VDO) от RHEL
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

4. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–15 +/–
Сообщение от Аноним (4), 31-Окт-23, 07:52
Кopпopacты не нужны, даешь только православный код от независимого сообщества свободных разработчиков! Давно пора сообществу объединиться и дружно выпилить весь некошерный код из ядра. В качестве ФС оставить только Reiser... А ZSTD вообще Facebook написал, там же куча ЗОНДОВ!
Ответить | Правка | Наверх | Cообщить модератору

	6. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+5 +/–
	Сообщение от Аноним (6), 31-Окт-23, 08:06
	Дело не в кошерности/некошереости кода, дело в том, что кроме корпов этот код никому не нужен, но именно из-за него получается жирнукс.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (7), 31-Окт-23, 08:25
	Ну да, ну да, смотрю кормы прям линукс и написали, а не финский студент
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от пох. (?), 31-Окт-23, 09:43
	Ты не поверишь... (а то что писал да так и не дописал финский студент - вот ровно студенческий курсовой проект. Пользоваться нельзя, только на поиграться и выбросить. Дипломный уже был комбинацией труда разных людей, которые получали либо гранты, либо зарплаты в проклятых корпорациях. И при этом все еще толком ничего не мог.)
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (4), 31-Окт-23, 09:58
	Некоторые еще верят, что Столлман GCC написал.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 11:22
	> Некоторые еще верят, что Столлман GCC написал. emacs же ж?!
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–3 +/–
	Сообщение от Аноним (4), 31-Окт-23, 11:40
	Emacs плохой пример, ведь он даже VSCode не конкурент. Уж по распространенности так точно.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (80), 31-Окт-23, 12:05
	Там, где не хотят телеметрий, сам VSCode никому не конкурент.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от OpenEcho (?), 31-Окт-23, 12:27
	> Там, где не хотят телеметрий, сам VSCode никому не конкурент. VScodium - плачет за углом
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 12:00
	Таки, да, первоначальную версию именно он. https://ru.wikipedia.org/wiki/GNU_Compiler_Collection "Начало GCC было положено Ричардом Столлманом, который реализовал первый вариант GCC в 1985 году на нестандартном и непереносимом диалекте языка Паскаль;"
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	195. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 23:20
	> Некоторые еще верят, что Столлман GCC написал. Не было бы Столлмана - вы бы до сих пор лизали пятки "благодетелей" под их истошные издевательства, что тулчейн только на такой платформе, а не этакой, 5 кило кода бесплатно а потом плати, "свободы" по версии корпов - это так. Не было бы Кента - у нас не появился бы +1 продвинутый дизайн, соответственно. А всякие похи-нахи рассказывали бы нам как крут нтсф в виндочке, бжад. Вот пусть эти господа своей виндочкой - и нтфс - и пользуются, имхо. Особенно когда такие "звездолеты" уже есть.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	230. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 05:54
	> Не было бы Кента - у нас не появился бы +1 продвинутый дизайн, соответственно. А всякие похи-нахи рассказывали бы нам как крут нтсф в виндочке, бжад. NTFS продолжат пользоваться миллионы, а сабж вообще не факт, что когда-либо найдёт применение где-либо кроме десктопов школьников. Поэтому у вас так и горит, что вы лузеры, труд которых никто не ценит (даже вы сами, потому и хреначите за подачки). Полезный труд хорошо оплачивается корпорациями, но столманутых там не любят.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 08:51
	>> Не было бы Кента - у нас не появился бы +1 продвинутый дизайн, соответственно. А всякие >> похи-нахи рассказывали бы нам как крут нтсф в виндочке, бжад. > NTFS продолжат пользоваться миллионы, Миллионы и в дырку в полу гадить в позе орла продолжат. Я должен равняться на их уровень? Щщаззз! > а сабж вообще не факт, что когда-либо найдёт применение где-либо кроме десктопов > школьников. Поэтому у вас так и горит, На лично мой вкус сабж это 1 из самых продвинутых дизайнов которые я видел, а кент - образец упоорства, который через тернии рвется к звездам, его ничето не может удержать. Он пример, показывающий как на самом деле менять мир под себя. Это было круто. У меня не горит, я всего лишь откровенно презираю таких как вы, с вашими аргументами. > что вы лузеры, труд которых никто не ценит (даже вы сами, > потому и хреначите за подачки). Полезный труд хорошо оплачивается корпорациями, но > столманутых там не любят. Спасибо за мотивационный спич, +1 причина попахать и надрать ваши бесполезные наглые задницы. Ждем очередного плача ZFSно-BSDшных несмеян с виндочкой на тему как их все отправили выгуливать собак. Где им самое место.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 09:45
	Мир изменили те, кто нтфс написали, раз весь мир ею пользуется. И совершенно не важно, хорошая это ФС или нет. А это типичный куколд, который 10 лет писал ФС на подачки, чтобы потом корпорации всего мира могли её использовать абсолютно бесплатно (если захотят, конечно). Чем это принципиально лучше того, чем занимался Шишкин? Если бы он это делал, чтобы его взяли на работу куда-нибудь, то я бы еще понял, так нет ведь.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (4), 01-Ноя-23, 10:06
	Или вы и впрямь думаете, что корпорациям не все равно под какой лицензией код использовать - GPL или BSD. Да им насрать, им главное не платить всяким там кентам, чтобы подобные дурачки, руководствоваясь всякими там "благими идеями", сами пахали на их благо. А другие дурачки из т.н. сообщества им на это донатили.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:38
	> там "благими идеями", сами пахали на их благо. А другие дурачки > из т.н. сообщества им на это донатили. Как показал пример - для остальных условия получаются еще лохастее. Так что всякие похи обсуждают выгорание на работе, айти не торт, выгул собак, сидя на виндочке, с уровнем технологий "хомячок молится на божков из редмонда". Не вызывает уважения от слова совсем. И юниксвэй это эпикфейл если история заканчиватеся так.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 11:36
	Ничего не лохастей, овердофига примеров, когда люди делали себе целое состояние на ИТ. Этот Кент мог бы иметь машины и виллы, но вместо этого решил быть обслугой на побегушках за подачки. Сейчас вы ему багрепортов накидаете и он победит их послушно фиксить, потому что пердолик, которого хлебом не корми (в буквальном смысле лол).
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 20:23
	> Ничего не лохастей, овердофига примеров, когда люди делали себе целое состояние на ИТ. да, взять например - одного американского мультимиллионера финского происхождения. Но, заметьте, состояние он себе сделал именно тем что перестал писать код сам, и начал активно мешать это делать другим, если не оплачено, конечно, платиновым спонсором. > Этот Кент мог бы иметь машины и виллы, недоказано, к сожалению. Впрочем, учитывая год проведенный стоя на коленях - возможно он силен в "soft skills" и мог бы, мог бы подняться в гугле. Но предпочел вместо этого осчастливить мир... а, нет... мир даже не заметит его поделки. Она вообще актуальна только в каких-то странных сетапах где кто-то пыжится выжать из мурки еще капельку на своем локалхосте. Ни для обычных пользователей, ни для промышленного применения все это не требуется. А пока ее допишут - возможно и layered fs станут никому вовсе не нужны. Будет сплошной all-фарш...прастити, флэш. В облачкааааах...
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 13:22
	> да, взять например - одного американского мультимиллионера финского происхождения. Совсем лохи не умеют в PM. Нормальный прожектманагер это весьма сообразительный и хваткий тип. Которого лохануть вообше нереально. > Но, заметьте, состояние он себе сделал именно тем что перестал писать код > сам, и начал активно мешать это делать другим, если не оплачено, > конечно, платиновым спонсором. Да не скажи. Вот, построил Кента до комфортного себе уровня - и ВНЕЗАПНО для всех принял файлуху, решив что хрен с ним, чувак 10 лет пахал, с тем что получилось уже можно жить, а чувак усвоил азы сосуществования. Даже если никакие спонсоры и не вписались. Дизайн интересный, много народа хочет это. Пруф? А посмотри в форониксе что в топе popular ВОТ ЩА. Кстати я кажется обставил их прислав Чиркову линк на комит быстрее Ларабеля. А мешает он по своим соображениям. В сколь-нибудь большом проекте, если не принять весьма специфичных мер, он может помереть от своего веса. И еще много чего. Я агрегирую парочке проектиков комиты, и поверь, если не посылать и не заставлять переделать, проект загадят в гамно и быстро. Из лучших побуждений. Типовой кодерас не может в BigPic, он свой закуток видит, там все ЗБС. То что это ведет к проблемам на более глобальном масштабе - им недоступно. Кент получил довольно жесткие - но познавательные и интересные - лекции на тему. Которые можно найти в треде с Pull Request'ами bcachefs. Но такую привилегию надо еще заслужить. Или азы управления большим проектом от грандов. Цените, такое и на тренингах за бабки то не дадут а тут нашару. > недоказано, к сожалению. > Впрочем, учитывая год проведенный стоя на коленях - возможно он силен в > "soft skills" и мог бы, мог бы подняться в гугле. Гугл нынче обычная галера, продвинутые и не бедные оттуда уже слились. Это для них определенная проблема, куча питоняш и индусов не могут в technical excellence и они таки начинают сливаться. Они это понимают, но уже подугробили корп культуру у себя, и пытаются что-то с этим делать, но не особо успешно. > Но предпочел вместо этого осчастливить мир... а, нет... мир даже не заметит > его поделки. Уже заметил. Это в топе популярных новостей фороникса. Да и я линк Чиркову пульнул по-моему даже сделав Фороникс, потому что у kernel org были какие-то траблы, я хотел 6.6 release от них, это так сразу не вышло, а когда вышло, бонусом - нехилый отвис челюсти и ссыль Чиркову, потому что такого никто не ожидал. > Она вообще актуальна только в каких-то странных сетапах где > кто-то пыжится выжать из мурки еще капельку на своем локалхосте. Ни > для обычных пользователей, ни для промышленного применения все это не требуется. И тем не менее файлушники в целом рассматривают этот дизайн как пример next gen'а с довольно интересными свойствами. И нормально относятся к нему. И да, это свежая кровь, чувак "на уровне". В отличие от мамонтов он умеет в нормальные структурированые апи и проч. И поможет им с рефактором окаменелостей, он там по своему нужен. Наполовину как тестовый манекен, наполовину как носитель культуры. > А пока ее допишут - возможно и layered fs станут никому вовсе > не нужны. Будет сплошной all-фарш...прастити, флэш. В облачкааааах... А облачка будут данные хранить ... где? И еще не понятно кто и как девелопать все это будет? Прикинь, так же и создание роботов не означает что люди перестанут требоваться. Им придется просто стать продвинутее и заниматься чем-то менее дурацким чем какое там кручение гаек.
	Ответить | Правка | К родителю #307 | Наверх | Cообщить модератору

	357. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 13:59
	> Гугл нынче обычная галера за десять (гораздо меньше) лет там при должном упорстве и умении подлизнуть кому надо, а кого не надо нечаянно прищемить дверью - поднимаются до галерщика. А это уже очень неплохие деньги и очень мало забот. Заботы удел веслателей. > Уже заметил. Это в топе популярных новостей фороникса. это неимоверный успех. (Нет.) > И тем не менее файлушники в целом рассматривают этот дизайн как пример next gen'а с довольно > интересными свойствами. ну да, интересный такой сферический конь в вакууме. Только к чему приложить - непонятненько. >> не нужны. Будет сплошной all-фарш...прастити, флэш. В облачкааааах... > А облачка будут данные хранить ... где? а облачка внезапно не состоят из твоих локалхостов. Это не так работает. И даже если там найдется место файловым системам в принципе и layered fs'ам отдельно, что пока не выглядит особо реалистично (да у M$ есть но судя по популярности - совершенно уже невостребованное) - они будут между хостами, а не на одном отдельном. И скиллы требуются совершенно другие. На отдельном хосте в облаке - может не быть никакой fs внезапно вообще. Не нужна она там. И уж тем более не нужна вот такая меганавороченная. Чем проще, тем лучше. Можешь на досуге посмотреть как устроен нынешний ceph.
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

	399. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 02:21
	> за десять (гораздо меньше) лет там при должном упорстве и умении подлизнуть > кому надо, а кого не надо нечаянно прищемить дверью - поднимаются > до галерщика. А это уже очень неплохие деньги и очень мало > забот. Заботы удел веслателей. А таки мерзенькая работенка. Раньше лучше было, проср@ли полимеры. И странно что всякие похи и аноним(4) своим советам не следуют. А, вас туда не берут?! Правильно делают. >> Уже заметил. Это в топе популярных новостей фороникса. > это неимоверный успех. (Нет.) На фоне вон тех это уже о..ть! Тебе с анонимом (4) не обломится даже это. Только и будете что ныть на форумах да переквалифицироваться в мытье собак, нелохи. > ну да, интересный такой сферический конь в вакууме. > Только к чему приложить - непонятненько. Судя по выходу новости фороникса в топ это паршивая фантазия у тебя, а та толпа имела другие идеи на этот счет. > а облачка внезапно не состоят из твоих локалхостов. Это не так работает. Тем не менее, зачастую набить ширпотребных дешевых серверов с максимально дешевой конструкцией - не хучшая идея на свете. А продвинутости можно на других уровнях организовать, в софте. Архидорогие решения покупают скорее профаны в области, у них выбора нет. А, ну еще можно, вот, нтфс юзать. Но это еще хуже. > И даже если там найдется место файловым системам в принципе и layered > fs'ам отдельно, что пока не выглядит особо реалистично Я думаю что в случае сабжа найдется, глядя на bcache и как тяжко оно когда без интеграции с ФС и ее избыточностью: когда SSD под кеш протирается, в "этажерке" часто случается большой undefined с потерей данных. Кентовская штука сможет парировать это лучше, за счет интеграции кеша и избыточности смогет в осмысленный Damage Control в такой ситуации. Остальным это не дано, а судя по числу юзерей разных ФС с этой траблой, этот дизайн появился не просто так. > (да у M$ есть но судя по популярности - совершенно уже невостребованное) - Я наелся MS досыта - за добавкой не приду. Мне они не интересны. Эта корпа всегда делает свои проблемы проблемами даунстрима, а их маркетинг не парится если растоптали даунстримам бизнес. Думаешь чего спрос на альтернативы появился? > они будут между хостами, а не на одном отдельном. И скиллы требуются > совершенно другие. Как показал пример того же гугля, делать из относительно ширпортеба + оверлей поверх WIN по куче причин. От реюза скилов, стоимости и т.п. до отсутствия ограничений. А эти обречены быть узконишевыми галерщиками. For the time being. > На отдельном хосте в облаке - может не быть никакой fs внезапно > вообще. Не нужна она там. В принципе возможны самые разные варианты, включая и такой. Но это имеет и свои минусы, поэтому мало кто хочет делать именно так. > И уж тем более не нужна вот такая меганавороченная. Чем проще, тем лучше. Как тебе сказать то? Это ж не единственный юзкейс на планете. Btrfs взял свое тем что менее энтерпрайзный чем ZFS. Поэтому ZFS в многие мои хотелки не лезет, а btrfs - вполне. Кенту есть что доразвить в этом направлении. А финт с кешом - еще одно направление где он прочухал незанятую нишу. Она есть, bcache пользуются, но без интеграции в ФС оно крайне погано реагирует на протирание кеша зачастую. > Можешь на досуге посмотреть как устроен нынешний ceph. Мне малоинтересен всякий кластерфак. Мое будущее не там. Если мне приспичит мегаструктуры это будет дешевый ширпотреб + кастом оверлей. Но я предпочитаю иные задачи и парадигмы, когда это все просто не надо.
	Ответить | Правка | К родителю #357 | Наверх | Cообщить модератору

	332. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:35
	> Ничего не лохастей, И это на практике проявляется - в чем именно? > овердофига примеров, когда люди делали себе целое состояние на ИТ. Ну во первых не овердофига. Во вторых - вот именно нищих, именно продвинутых линуксоидов я не очень то и знаю. Слишком нужные тушки чтобы бедствовать, бояться увольнений и размышлять о выгуле собак, насколько я вижу. > Этот Кент мог бы иметь машины и виллы, но вместо этого решил быть обслугой на > побегушках за подачки. Сейчас вы ему багрепортов накидаете и он победит их > послушно фиксить, потому что пердолик, которого хлебом не корми (в буквальном > смысле лол). Да, накидаем. И он починит. Это сделает его дизайн лучше, а его самого - в целом более нужным для человечества экземпляром. И поверьте, после некоторого порога он будет нам настолько нужен что помереть ему с голода мы таки - не дадим. А сейчас надо встретить его на вершине и помочь с некоторыми вещами. В рамках взаимовыгодного сотрудничества, которое уж точно не про лоховство. И это... ну вон там Шишкин допустим. И как, много у него машин и вилл? Да и у вас поди не сильно больше. Потому что ни вы ни пох не умеете делать нихрена реально нужного человечеству. А вот Кент, пожалуй, в это число войдет.
	Ответить | Правка | Наверх | Cообщить модератору

	341. Скрыто модератором	+/–
	Сообщение от Аноним (4), 02-Ноя-23, 07:15
	> Шишкин допустим. И как, много у него машин и вилл? Так линуксоиды же лузеры, в основном, которые молются на Столлмана и тп. Писали бы проприетарь, как все остальные, глядишь бы и дорасли до уровня CEO в какой-нибудь корпорации. А если изначально ставить себя в позу "голодного художника", то на высокий и, главное, стабильный доход можно не рассчитывать. > Да и у вас поди не сильно больше. Потому что ни вы ни пох не умеете делать нихрена реально нужного человечеству. За 10 баксов в час мог бы устроиться в рыгаловку и получал бы не меньше, чем с патреона. И нафига тогда нужны ему его знания? Я к чему, пердолик о себе не думает, все пытается какому то обществу угодить (точнее 1%), а вы нам его в пример ставите.
	Ответить | Правка | К родителю #332 | Наверх | Cообщить модератору

	358. Скрыто модератором	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 13:59
	> Так линуксоиды же лузеры, в основном, которые молются на Столлмана и тп. Судя по спичу Торвальдся он что угодно кроме лоха и своего не упустит. И поверьте его пример как раз весьма заразителен. В том числе и на тему того что корпов надо ставить в стойло. > Писали бы проприетарь, как все остальные, глядишь бы и дорасли до > уровня CEO в какой-нибудь корпорации. Или не дорасли. Джунов много а CEO товар штучный, да и лизать ботинки и заниматься политикой и чем там в менеджменте корпы нравится не всем. А занимаясь тем что ненавидишь сложно добиться многого на чисто человеческом уровне. Более того - мир изменился. Самые продвинутые и крутые корпы стали намного более открытыми чем то о чем тут вещает проприетарное дино. Которому из более-менее современных девов "на уровне" руки то не подаст. А фиксация на яхтах и виллах намекает что, видимо, хозяин не так уж и круто шестерке и платит, с нами чатится явно не CEO современной корпы из фортуны 500. Те вообще на подобной тематике не переклинены, в отличие от всяких нонеймов... > А если изначально ставить себя в позу "голодного художника", то на высокий и, > главное, стабильный доход можно не рассчитывать. Самое стабильное состояние на этом глобусе наступает, таки, на кладбище... > За 10 баксов в час мог бы устроиться в рыгаловку и получал > бы не меньше, чем с патреона. И нафига тогда нужны ему его знания? Мне что-то подсказывает что он уже отрекламил себя выше крыши. Как бонус ему помог и Ларабель и даже я. А для вас я разве что на (вашей) могилке станцую. Да, я тот кто прислал линку на комит Чиркову. Это был мой способ сказать спасибо Кенту. > Я к чему, пердолик о себе не думает, все пытается какому то обществу угодить > (точнее 1%), а вы нам его в пример ставите. После того что он сделал желающих о нем подумать заметно прибавится. Видите, мы друг другу подыгрываем, я вот его штуку тут отпиарил по факту :). Да и опеннет оперативная публикация украсила, думаю что это добавило поводов читателям приходить именно на опеннет. И вообще, кому яхты и виллы, хрень от сваровски и проч. А кому вот продвинутую файлуху хочется. Торвальдс и не скрывает что ему "борзыми щенками" в виде комитов тоже ОК. И не только ему. Крутая файлуха это хорошая награда сама по себе. Мне такое просто интереснее кристаллов от сваровски, хоть как. p.s. а еще я был в парочке корпов из фортуны 500. Ну да, платят норм. Просто они мне надоели до смерти. Унылки.
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	360. Скрыто модератором	+/–
	Сообщение от пох. (?), 02-Ноя-23, 14:05
	> Так линуксоиды же лузеры, в основном, которые молются на Столлмана и тп. > Писали бы проприетарь, как все остальные, глядишь бы и дорасли до > уровня CEO в какой-нибудь корпорации. это называется CTO а не CEO. Ну и сбегает со всеми деньгами обычно как раз второй. А первого инвесторы заставляют доделывать. Но это либо не уровень Шишкина, либо не уровень очень-плохой-дороги. Что в целом и лучше, поскольку и отвечать ни за что кроме своего направления не придется, и в разборках больших дядь участвовать не понадобится. Ну будет вилла трехэтажная а не шести, и машин всего три, а не восемь.
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	397. Скрыто модератором	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 01:35
	>> уровня CEO в какой-нибудь корпорации. > это называется CTO а не CEO. Если это будут рога и копыта то может и CEO оказаться. Хотя на удивление пох в курсе разницы, в отличие от анонима (4) и таки это больше про CTO как раз :) > Ну и сбегает со всеми деньгами обычно как раз второй. А первого > инвесторы заставляют доделывать. Одна из фич хорошего менеджера - понимать когда посудина явно идет на дно и зарезервировать себе место в шлюпке, ДО того как уже наступит время кормить крабов. Потому что тогда уже поздняк. > Но это либо не уровень Шишкина, либо не уровень очень-плохой-дороги. Что в > целом и лучше, поскольку и отвечать ни за что кроме своего > направления не придется, и в разборках больших дядь участвовать не понадобится. CTO из Шишикина? Ты смерти плохой дороги захотел? Этот кадр точно не умеет в сбалансированое видение проектов и процессов - что техническое, что overall, так что его что CEO, что CTO, фейл выглядит одинаково. > Ну будет вилла трехэтажная а не шести, и машин всего три, > а не восемь. Скорее будет толпа злых китайцев, чем-то не довольных. И кредиторы которые пришли отжимать виллу, ибо кредит нечем выплачивать.
	Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

	343. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 02-Ноя-23, 07:27
	> В рамках взаимовыгодного сотрудничества, которое уж точно не про лоховство. Именно что про лоховство, его выгоды никакой от того, что вы ему багрепорты шлете или улучшения. Выгодно это бизнесами, которые будут эту ФС применять в продакшене. Как обычно в попенсорсе, пока лохи впахивают, сливки снимают корпы.
	Ответить | Правка | К родителю #332 | Наверх | Cообщить модератору

	359. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 14:02
	>> В рамках взаимовыгодного сотрудничества, которое уж точно не про лоховство. > Именно что про лоховство, его выгоды никакой от того, что вы ему > багрепорты шлете или улучшения. Выгодно это бизнесами, которые будут эту ФС > применять в продакшене. Как обычно в попенсорсе, пока лохи впахивают, сливки > снимают корпы. А кто сказал что я совсем уж ничего с опенсорца не имею? Просто в случае ФС это лишь 1 из дохреналиона компонентов. Да можно и без Кента. Но выглядит интересно и может оказаться в ряде случаев лучше чем иные варианты. А нтфсом и виндой пусть пользуются Аноним(4) и прочие эксперты уровня пох, и так им и надо. А для меня это слишком мерзотная перспектива. Даже, вот, жирные энтерпрайзные зарплаты не компенсировали мне отвращение от их корп культуры и таких технологий.
	Ответить | Правка | К родителю #343 | Наверх | Cообщить модератору

	363. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 02-Ноя-23, 14:32
	Не нравится их культура, если еще куча способов заработать, кто ж виноват, что пердолики больше ничего не умеют (и не хотят уметь).
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	398. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 01:39
	> Не нравится их культура, если еще куча способов заработать, кто ж виноват, > что пердолики больше ничего не умеют (и не хотят уметь). Вот я и изучаю альтернативный способы, с более приятными окружениями и параметрами - а за "пердолика" можно и получить при случае возврат "техдолга".
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	262. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:36
	> Мир изменили те, кто нтфс написали, раз весь мир ею пользуется. Это громкое заявление было актуально 30-35 лет назад. Тогда да, это был нехилый апгрейд. А сейчас это лохматое тормознутое легаси. Которое не зак@пали в основном по недоразумению - ну вот уволились из майкрософта нормальные системщики, видимо, и теперь ни дров, ни файлух продвинутых, приходится барыжить одним и тем же кернелом и ОС 20 лет. Я это другими словами называю, это на-е-бизнес уже. > И совершенно не важно, хорошая это ФС или нет. Лично меня интересует актуальное состояние дел, в контексте моих зазач и хотелок. Остальное в общем то лирика, не стоящая байтов на нее. В этом я весьма прагматичен и заявы про куколдов сильно мимо. > А это типичный куколд, который 10 лет писал ФС на подачки, чтобы > потом корпорации всего мира могли её использовать абсолютно бесплатно (если захотят, Остальные даже и так не смогли, так что о чем мы тут? И технологически дизайн попродвинутее чем то что было до него и стало быть - прогресс. А пользотваться NTFS я попробовав штуки типа btrfs уже не собираюсь. Сложно это - из звездолета в ржавый Форд 90 года. > конечно). Чем это принципиально лучше того, чем занимался Шишкин? Если бы > он это делал, чтобы его взяли на работу куда-нибудь, то я > бы еще понял, так нет ведь. Для меня это довольно радикально лучше: сабж реально допинать толпой до ума теперь. Шишкин же никогда этот рубикон взять не мог и потому его проект полный слив, который мне никогда полезен не будет. А тут я таки тоже сделаю свою часть.
	Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

	319. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от _ (??), 02-Ноя-23, 00:25
	>А пользотваться NTFS я попробовав штуки типа btrfs уже не собираюсь. Но вель это значит что на вопрос "Сколько стоят ваши данные?" ты ответил - 0. Ничего не стоят. А так то да - держи в курсе :)
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:42
	> Но вель это значит что на вопрос "Сколько стоят ваши данные?" ты > ответил - 0. Ничего не стоят. А так то да - держи в курсе :) Хорошая подтасовочка и передерг. Но так глядя на то сколько я всего с убитых NTFSов вынул - у меня есть определенные сомнения на тему ценности мнений этих господарей с их нтфсом. Которому вообще наср@ть на целостность данных, там даже чексум нет.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (8), 31-Окт-23, 08:27
	Возможно, у вас просто маловато акций IBM и Google? :)
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	68. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 11:24
	> Возможно, у вас просто маловато акций IBM и Google? :) не берите, вас разводят! (ну реально отстойный товар, хрен всучишь) Из всего FAANG только амазон еще имеет какой-то смысл. Да и то сомнительный.
	Ответить | Правка | Наверх | Cообщить модератору

	389. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (389), 02-Ноя-23, 19:27
	Смешнее твоих рассуждений об ИТ только твои рекомендации касательно фондового рынка.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от WE (?), 31-Окт-23, 09:00
	Так и весь linux только корпорастам и нужен. Без бизнеса это просто ядро для гиков в НИИ.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	27. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 09:39
	> Так и весь linux только корпорастам и нужен. Без бизнеса это просто ядро для гиков в НИИ. А вот гик Кент таки назло всем ветрам запилил свою файлуху и пропихал в майнлайн. Без корпораций, ога. Ща они конечно как стервятники налетят. После того как уже все самое сложное сделали другие, с фигой в кармане. Такие вот благодетели, очень характерные. И горе тому кто забудет о том что эти "благодетели" из себя реально представляют.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 31-Окт-23, 09:45
	или на зарплату фейсбучека. > Без корпораций, ога. ну да, ему мама с папой, миллиардеры, оставили наследство чтоб он мог пять лет не работать и пилить а потом еще и пихать. А, нет, не ему. Какому-то сцукенбергу. Но тот пилить ничего не стал, кроме денег. И просто наловил дешевых рабов.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (320), 31-Окт-23, 15:32
	> или на зарплату фейсбучека. Ты показал что НИХРЕНА не смыслишь в разработке линуха. Ответственно это заявляю. Если бы за него вписался фэйсбук - приняли бы пяток версий ядра назад, авансом, ибо 1 из претензий была в виде "а еще майнтайнеры/девы у этой ФС есть?!". >> Без корпораций, ога. > ну да, ему мама с папой, миллиардеры, оставили наследство чтоб он мог > пять лет не работать и пилить а потом еще и пихать. Тебе вечно что-то мешает. А может просто нефиг быть бездарным лузером и овощем, стоит любить что делаешь и делать что любишь, и проявлять нефиговое упорство? И тогда однажды мир прогнется под упрямого хрена который всем назло фигачит и класть хотел на таких как ты (и правильно делает как видим). И - вот - в итоге достиг определенных успехов. Он отличная от ноля величина без мегакорпа за спиной. Чем и крут. А тебе это не грозит, мистер дырка от бублика. Осваивай уже свою виндочку и выгул собак, твоя песенка спета. Нечего в айти ловить с твоим настроем, ты и рядом не конкурент вон тем фигурам. > А, нет, не ему. Какому-то сцукенбергу. Но тот пилить ничего не стал, > кроме денег. И просто наловил дешевых рабов. Что-то мне кажется, что после вот этого финта ушами Кент уж точно нищим не останется теперь. Есть такое подозрение. Почему-то.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (389), 31-Окт-23, 16:55
	> уж точно нищим не останется Больше одной зарплаты за эту строчку в резюме не получит, а значит его нищета гарантирована.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:07
	не, ну уроки резйерэфес не совсем в том как (неправильно) писать btree. Возможно, чувак пойдет этим путем - и зарплату будем мы с тобой получать, а он - доход. Но сдается мне, до Ганса ему как до китая раком.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (389), 31-Окт-23, 18:38
	Доход с чего? С инвестиций в код очередной файловой системы? Конкретно этот персонаж живёт с донатов на Патреоне, что-то около 3500USD в месяц. В стране третьего мира это может и хорошие деньги, особенно если налоги платить не надо, но автор сабжа живёт в Сан-Франциско, где этого хватит на еду, одежду и налог на недвижимость. Либо на съём конуры, если питаться в Армии Спасения. Учитывая, что код сам себя не напишет, а в сутках только 24 часа, чем бы он там ни занимался в свободное от Bcachefs время, сомневаюсь, что у этого занятия какая-то особенно высокая доходность. Действительно, до Ганса ему далеко. Ганс себе на полный пансион до конца жизни заработал, а этого гарантий никаких. Сегодня он успешный автор прогрессивной файловой системы, а завтра его адресом может стать один из общественных пляжей.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 23:31
	> не, ну уроки резйерэфес не совсем в том как (неправильно) писать btree. > Возможно, чувак пойдет этим путем - и зарплату будем мы с тобой > получать, а он - доход. Во всяком случае вот так просыпаешься ты утрецом - а жизнь изменилась. И теперь это уже не маргинальный фрик а весомая часть майнлайна. В этой точке мир изменился навсегда, и завтра уже не будет таким как вчера. И Кент теперь станет всем почему-то сильно нужнее, вероятно. Он прошел фильтр, взошел на олимп и теперь в топе кодеров планеты. А желающие оспорить лавры могут попробовать так же. Шишкин и ко вот не смогли. И да, кто не понял кернел вырос с времен хаотичных студенческих времен - и теперь до того как туда дадут что-то комитнуть есть более 9000 соображений по части "майнтенанса большого проекта". Это коллективное самосохранение, не более. Если в проект такого размера валить с лопаты - он сколлапсит от своего веса. Опытные майнтайнеры и Торвальдс это понимают. Поэтому выдвигают комитерам характерный набор требований чтобы избежать этой участи. Да, это неудобно. Но в большом проекте без этого иначе скончается уже весь проект. Это попило крови Кенту. Но к его чести он смог вон там немного пойти на компромиссы, немного урезать осетра, утрясти те или иные траблы и в конечном итоге, сфокусировавшись на результате все же перейти рубикон. Довольно много голосов на планете ликует, еще +1 осилил путь на Олимп. > Но сдается мне, до Ганса ему как до китая раком. В смысле, грохнуть жену и сесть пожизненно? Ну не, я думаю он и на чужих ошибках усвоил что это довольно так себе метод файлухи разрабатывать. В тюрьме не очень хорошо кодить получается.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	200. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 23:38
	> Во всяком случае вот так просыпаешься ты утрецом - а жизнь изменилась. и как, ты хотя бы помнишь кто автор ext2? (про ext4 глупо спрашивать, продукт целиком вторичный, хотя пару имен можно было бы назвать) А ведь весомая часть майнлайна. Причем эту поделку - гарантированно переживет, поскольку большинству это совершенно не нужно. У меня вот ровно ноль юзкейзов под такой невероятный гибрид ужа с ежом. Ни дома не нужен, ни в работе. >> Но сдается мне, до Ганса ему как до китая раком. > В смысле, грохнуть жену и сесть пожизненно? в смысле наловить рабов, и сделать _бизнес_ - всего-то добавив в fsck плашку с угрозами и не сделав ключ help. Внезапно, не только ему хватало на доширак, но еще и хватало этим самым рабам на мивину (он в основном - дешовых ловил). гепеле такое гепеле. Это Шишкину нельзя, а друзьям божка-с-пальцем - можна! (ну вроде там еще были какие-то якобы разработки для специфических бизнес-заказчиков, но это неточно, никто их не видал. Скорее всего просто все ограничивалось более высоким уровнем сервиса, вплоть до прикомандированного навечно раба.)
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 01:04
	>> Во всяком случае вот так просыпаешься ты утрецом - а жизнь изменилась. > и как, ты хотя бы помнишь кто автор ext2? Нет, но... 1) это было до того как меня заинтересовал топик и я стал трекать разработку линуха. В те поры я еще был голимым виндузером и был далек от этого. 2) в EXT2 нет технологий которые я бы считал "эпичными". Это заурядный клон существовавших дизайнов, без интересных передовых идей и свойств. Я могу запомнить copycat но для этого ему надо выпендриться выше среднего. Это не про EXT2! > (про ext4 глупо спрашивать, продукт целиком вторичный, хотя пару имен можно было > бы назвать) Легко назову Теодора Тс'о. Ключевая фигура EXT4. Этот был нацелен на то чтобы унылую архаичную каку разогнать, сделав похожей на современный state of art и достиг успехов. Но наследие оригинального дизайна очень мешало ему. Лучше бы он с ноля фигачил, имхо. Когда в 2023 циферок не хватает, иноды кончаются, это лол. > А ведь весомая часть майнлайна. Не думаю что много людей использует сейчас EXT2. Да и EXT4 так то воображение не поражает. Поражает его извините "csum error ... corrected" при налете на бэд раз в эн лет, когда вместо переустановки ОС на ноуте и собирания ошметков проектов - я такой "фух, хорошо что это btrfs". Так я узнаю что возился не зря. > Причем эту поделку - гарантированно переживет, поскольку большинству это совершенно не нужно. ИМХО можешь хоть fat12 использовать, даже на двоих с "экспертом" InuYasha, попутно соревнуясь с тараканами кто кого переживет, мне не жалко. А я предпочту более продвинутые технологии. > У меня вот ровно ноль юзкейзов под такой невероятный гибрид ужа с > ежом. Ни дома не нужен, ни в работе. Твоя эра заканчивается. А экспертиза как все делать сложно, дорого и хреново, мало кому нужна. Вместе с вашим "храните эн девайсов на складе". Вон то найдет своих почитателей, чтобы оно появилось были предпосылки. И мне пофиг на тебя и твои кейсы, у меня своя голова и я найду сабжу применения. Но сперва надлежит отладить и обезжучить. Чем мы толпой и займемся после того как выкатят -RC1. "And now the moment we've all been waiting for..." > в смысле наловить рабов, и сделать _бизнес_ - всего-то добавив в fsck > плашку с угрозами и не сделав ключ help. Очень спорная бизнес-модель как по мне и вдолгую не способствовала доверию к бренду и технологиям. Кстати, разнос в вермишель забыл. Так себе фича, имхо. Особенно если ее known issue назвать. Хотя для тебя самое то. Но если ты еще не прочухал я твою экспертизу использую после логической инверсии. Не, простреливать свои пяти мне не в тему, а вот знание как НЕ простреливать, на чужом примере ОК :) > Это Шишкину нельзя, а друзьям божка-с-пальцем - можна! У Шишкина было ровно столько же шансов как у Кента. Да и Торвальдс послал Кента за FTBFS и отсутствие в -next с весьма колоритными коментами, не особо дружественными я б сказал, больше похожими на ультиматум. Просто в отличие от шишкинэфса кент все же способен воспринимать аргументы и понимать что ему не вся картина видна. И в целом реагировать на критику конструктивно, хоть он будучи упрямым челом и довел половину ядра до белого каления, зато они объяснили rationale за "субоптимальными" решениями. Кому интересно может увидеть это, неплохая экскурсия в project management, для тех кому оно надо (тебе это имхо не в коня корм). > (ну вроде там еще были какие-то якобы разработки для специфических бизнес-заказчиков, но > это неточно, никто их не видал. Скорее всего просто все ограничивалось > более высоким уровнем сервиса, вплоть до прикомандированного навечно раба.) Это описание на шишкина похоже. Сидит какой-то нонейм, который без хуавея вообще ни о чем сам по себе, корчит из себя эксперта, а эксперт он - фиг знает по чему, нормальных проектов его дизайна нетути же. Эксперт по лизанию китайских ботинок - ну такое себе.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 06:11
	>У меня вот ровно ноль юзкейзов под такой невероятный гибрид ужа с ежом. Ни дома не нужен, ни в работе. Аналогично, хотя вот ext4, xfs и даже f2fs трудятся во всю.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	310. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Хм (?), 01-Ноя-23, 21:19
	> Аналогично, хотя вот ext4, xfs и даже f2fs трудятся во всю. Да, да. Повёлся я на обещания надёжности F2FS, потратил день, чтобы перегнать RPi на неё на новой карте и в результате, система через месяц посыпалась, хотя все логи и данные HA писались на внешний сервер. В dmesg ни одной ошибки, но имеем битые файлы и fsck высыпал кучу ошибок. До этого система благополучно прожила почти 2 года на ext4, пока SD карта не переключилась в RO. Так что спасибо не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	334. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 02-Ноя-23, 05:52
	> Да, да. Повёлся я на обещания надёжности F2FS, потратил день, чтобы перегнать > RPi на неё на новой карте и в результате, Я вот бакланам с опеннета с их NTFS, ZFS и прочей экспертизой на слово не верю - и поэтому вместо слушания сказок - закатил powerloss тесты рассматривая идею перевести рутфс одноплатников на это дело, раз "быстрое". И весьма быстро получил результат - когда файлуха уже не монтируется, но fsck это не чинит, и в общем то "что хотите то и делайте". Что не удивительно, Jeon один на 4 огромных проекта в самсе надрывается, какое там качество кода и его протестированость - понятно думаю. Нельзя на смертных по 4 огромных проекта навешивать но галере типа самса и ее манагерам это видимо невдомек. Ну и чего я буду делать если такая фигня у кастомера на железке случится?! Btrfs и ext4 этот тест без проблем переживают. Ну вот и думайте - насколько доверять вон тем опеннетовым "экспертам". Лучше всего - имхо тестить под СВОИ конфиги самому. А эксперты уровня нах и пох - не зря у них ники такие. И фанаты бсд с zfs отовсюду повылетали за дело, особенно бздями. > сервер. В dmesg ни одной ошибки, но имеем битые файлы и > fsck высыпал кучу ошибок. А у меня он вообще - ошибок на ФС не находил. Все ЗБС. Только не маунтится. Как так получается что для fsck все збс а для ядерного парсера нет - вызывает вопросы к качеству кода этой штуки. > До этого система благополучно прожила почти 2 года на ext4, пока SD > карта не переключилась в RO. > Так что спасибо не надо. Ага. Еще 1 познакомившийся с экспертами опеннета. А вы посмотрите что это за эксперт, копните его профайл, увидите.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 06:03
	> И теперь это уже не маргинальный фрик а весомая часть майнлайна. Фрик все еще фрик, в маинлайне он или нет. > В смысле, грохнуть жену и сесть пожизненно? Он хотя бы жену смог найти, куда большее достижение для фрика, чем этот ваш майнлайн.
	Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

	248. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 08:54
	>> В смысле, грохнуть жену и сесть пожизненно? > Он хотя бы жену смог найти, куда большее достижение для фрика, чем > этот ваш майнлайн. Общество и оценило его достижения по достоинству - упаковав на пожизненное. Ну такая себе оценочка, скажем прямо.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 23:24
	>> уж точно нищим не останется > Больше одной зарплаты за эту строчку в резюме не получит, а значит > его нищета гарантирована. Мне почему-то кажется, что если сравнивать с всякими опеннетными дрищами - участь Кента будет очень даже нормальной. Особенно глядя на всяких похов, с выгулом собак, под виндочкой, с нтфсом. Это конечно эпическая участь и предел мечтаний, но кажется можно и получше. Если что-то из себя в предметной области представлять и не быть как шишкин, а таки уметь выкатывать вот именно что-то хотя-бы отдаленно напоминающее продукт. Потом его толпой в кернеле таки могут и помочь допинать, но это нужно заслужить. И вон тот бесполезняк не прошел даже этот фильтр. Так что предел ваших мечтаний это быть нонеймом в дядиной галере. Никто не вспомнит что вы такие вообще существовали.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	36. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (4), 31-Окт-23, 09:59
	> из-за него получается жирнукс. Из-за тех (дистров), кто ядро собирает с кучей всего лишнего.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	15. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (244), 31-Окт-23, 09:06
	> Кopпopacты не нужны, даешь только православный код от независимого сообщества свободных > разработчиков! Давно пора сообществу объединиться и дружно выпилить весь некошерный код из ядра. Сообщество вокруг линуха в общем то и так достаточно объединенное. И кто будет определять что нужно? > В качестве ФС оставить только Reiser... А, вот кто?! Ну, вот ты ЭТИМ и пользуйся. А раз это ТЕБЕ надо - вот, ты этим и займись. И сообщество себе собери, если это и правда "надо" должно быть раз плюнуть. > А ZSTD вообще Facebook написал, там же куча ЗОНДОВ! Его написал вполне конкретный Yan Colett. Автор LZ4. А также Jarek Duda придумавший энтропийное кодирование ANS (также нанят фэйсбуком, само алго широко разошлось и много кем еще юзается, от эпла до игроделов) и еще Przemyslaw Skibinski (автор LZBench) т.к. это была довольно дружная тусовочка, кому надо даже знают где они отвисали, а кому не надо пусть теории заговора и разводят, зачем мешать.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	16. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Минона (ok), 31-Окт-23, 09:07
	А деньги на финансирование этого "свободного сообщества" ты где брать будешь?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	22. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 09:16
	> А деньги на финансирование этого "свободного сообщества" ты где брать будешь? Ну вот Кент взял упорством. Он просто класть хотел на глупые вопросы корпоративных холуев и фигачил. Он упорно гнул свою линию, невзирая на все трудности. В какой-то момент мир сдался и прогнулся под него. Это про таких как он поется "не стоит прогибаться под изменчивый мир, пусть лучше он прогнется под нас".
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Минона (ok), 31-Окт-23, 09:56
	>> А деньги на финансирование этого "свободного сообщества" ты где брать будешь? > Ну вот Кент взял упорством. Он просто класть хотел на глупые вопросы > корпоративных холуев и фигачил. Он упорно гнул свою линию, невзирая на > все трудности. В какой-то момент мир сдался и прогнулся под него. > Это про таких как он поется "не стоит прогибаться под изменчивый > мир, пусть лучше он прогнется под нас". Где Кент все эти 10 лет работал?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от амерский ведроид (?), 31-Окт-23, 10:33
	Рамблер к Нджинекс имеет отношение или нет,вот в чем вопрос... Такие вопросы видимо,будут всю историю опенсорса задаваться.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Минона (ok), 31-Окт-23, 10:49
	> Рамблер к Нджинекс имеет отношение или нет,вот в чем вопрос... Такие вопросы > видимо,будут всю историю опенсорса задаваться. Блаженны "мамкины воены опенсорса" верящие в то, что всё делается бесплатно.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (65), 31-Окт-23, 11:14
	На патреоне
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	69. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Анонус (?), 31-Окт-23, 11:26
	На его Линкедине написано "самозанятый разработчик". А на Патреоне > Kent Overstreet > creating bcachefs - a next generation Linux filesystem > 426 участника(-ов) > 82 Публикаций: > 2315 $/месяц
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	70. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Анонус (?), 31-Окт-23, 11:28
	Правда для Сан-Франциско 2300 баксов это наверное немного, т.е. живет он скромненько.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 31-Окт-23, 11:36
	Это не главное, главное, что каждый не может жить с патреона в принципе. Несколько особо выдающихся могут, а остальным что делать?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 15:36
	> Это не главное, главное, что каждый не может жить с патреона в > принципе. Несколько особо выдающихся могут, а остальным что делать? Ну как бы либо заапгрейдиться до этого уровня, или хотя-бы чего-то выше среднего - или... ну, мало ли, охранники в супермаркете так то тоже нужные чуваки. И если кто совсем не могет в продвинутый кодинг и прочие алгоритмы, можно, вот, накрайняк туда. Две штуки грина в месяц, конечно, за это не дадут. Особенно у вас.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 31-Окт-23, 18:51
	Не могут не потому что "тупые", а потому что в каком-нибудь гугле им предложат больше. И тк не все хотят быть бомжующими фриками, то вариант работать за подачки сразу отпадает.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 01:50
	> Не могут не потому что "тупые", а потому что в каком-нибудь гугле > им предложат больше. И тк не все хотят быть бомжующими фриками, > то вариант работать за подачки сразу отпадает. Ну, отпадает так отпадает, греби на галере. А я буду считать тебя за нонейма, и когда корп выкинет тебя как отработанный материал на мороз, и окажется что ты без них ничто и твой дом коробка от холодильника - ты уж там не плакай, ога? :)
	Ответить | Правка | Наверх | Cообщить модератору

	521. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Tron is Whistling (?), 18-Ноя-23, 11:08
	К моменту "когда" у него будет пенсия больше, чем у тебя доход за год. Такие дела.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 11:43
	для SF это аренда коробки от холодильника. Причем небольшого. А вот электричество, интересно, кто ему оплачивает? Оно там золотое.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	205. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (205), 01-Ноя-23, 01:52
	> для SF это аренда коробки от холодильника. Причем небольшого. > А вот электричество, интересно, кто ему оплачивает? > Оно там золотое. Ты по моему Кента с Ларабелем перепутал. Это Ларабель с фермой в подвале, и жрет 2 мегаватта в месяц. Там да, счет уже начинает ощущаться. А разработчику файлухи зачем мегаватты жрать?
	Ответить | Правка | Наверх | Cообщить модератору

	313. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 22:34
	> Ты по моему Кента с Ларабелем перепутал. Нет. Второй _зарабатывает_ и имеет стабильный доходец от своей фермы (точнее от ло..ов но это неважно - без фермы их не набрать). И будет иметь, что бы там с поделками других л-ов не случилось. А первый вот прям сейчас, как внезапно выяснили, занят поиском где бы срочно подзанять деньжат. И никаких определенных будущих доходов даже если взлетит - а если не взлетит то он вообще лузер и неудачник и ему места нет даже в коробке, потому что больше-то он ничего платежеспросного в жизни не сумел. > разработчику файлухи зачем мегаватты жрать? научись пользоваться гуглем и узнай цены на электричество в LA. Разработчику малтилейер файлухи таки придется жрать несколько больше чем твоя поделка на недоармах - потому что для малти надо таки малти. Так что стоит у него ящичек размером с тумбочку и с киловаттным питаловом как минимум. Только при таких размерах вообще имело бы хоть малейший смысл то что он затеял. (хотя чем дальше смотрю тем больше очевидно что оно вообще ни малейшего смысла не имеет) И чтоб летом не расплавился (а там бывает и под полтинник) - еще и кондиционер прямо в коробку встроен.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (337), 02-Ноя-23, 06:13
	>> Ты по моему Кента с Ларабелем перепутал. > Нет. Второй _зарабатывает_ и имеет стабильный доходец от своей фермы (точнее от > ло..ов но это неважно - без фермы их не набрать). Он вроде еще корпам на заказ бенчи делает, им тоже ведь интересно - в правильном направлении они двагают или нет? Самим узнавать - канительно, такую же тестовую ферму сетапить это гимор, время и бабки. А у этого уже все на мази, чего б ему денег не дать? И чсх дают. И Кенту насыпят. По другим причинам. Не помрет с голода в ближайшем времени теперь. > И будет иметь, что бы там с поделками других л-ов не случилось. В этом мире 100% гарантий даже страховой полис может не дать. А уж эксперты опеннета... > А первый вот прям сейчас, как внезапно выяснили, занят поиском где бы > срочно подзанять деньжат. На опеннете вообще любят чужие бабки считать. Наверное, как минимум на ламборжини в булочную подруливая. Свою, конечно, с личными кондитерами. > И никаких определенных будущих доходов даже если взлетит - а если не > взлетит то он вообще лузер и неудачник и ему места нет > даже в коробке, потому что больше-то он ничего платежеспросного в жизни > не сумел. Судя по тому что я вижу - более 95% жителей этого глобуса намного более крутые лузеры и неудачники. Включая и тебя. >> разработчику файлухи зачем мегаватты жрать? > научись пользоваться гуглем и узнай цены на электричество в LA. Если мне станет интересно - я могу спросить у тупо амеров из LA. Но я не вижу с какого бы хрена это для кодера проблемой должно быть. Он же не фороникс. > Разработчику малтилейер файлухи таки придется жрать несколько больше чем твоя поделка на > недоармах - потому что для малти надо таки малти. Он не обязан жрать в конкретной локации, серверов для тестов и проч можно много где засетапить. А тут еще после -rc1 другие свое электричество потратят. У него за 10 лет и так группка почитателей - появилась. Ща их станет сильно больше. > Так что стоит у него ящичек размером с тумбочку и с киловаттным > питаловом как минимум. Я думаю если ему станет что-то такое надо - ему это подгонят и с ремотным доступом или виртуализацией. Во всяком случае до 20 Тб он уже где-то догнался. Значит нормуль. > Только при таких размерах вообще имело бы хоть малейший смысл то что > он затеял. (хотя чем дальше смотрю тем больше очевидно что оно > вообще ни малейшего смысла не имеет) Ну смотри, смотри. Что-то мне кажется что история с девопсами повторится. И скоро за ветеранадминами отправятся и фанаты супер-помоек с их пафосом и непрактичными требованиями. > И чтоб летом не расплавился (а там бывает и под полтинник) - > еще и кондиционер прямо в коробку встроен. Да я то уже давно понял что ты любую фирму поставишь на умопомрачительные бабки, да еще забыв показать результат который бы того стоил.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Минона (ok), 31-Окт-23, 12:57
	> На его Линкедине написано "самозанятый разработчик". А на Патреоне >> Kent Overstreet >> creating bcachefs - a next generation Linux filesystem >> 426 участника(-ов) >> 82 Публикаций: >> 2315 $/месяц На заборе много чего написано.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	160. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:14
	дык патреон не ведет серой бухгалтерии - что написано, то на карточку и переведет, не забыв снять 7 (или уже 12?) процентиков в свою пользу. Жил бы он в скрепостане - хватило бы на квартирку в императорских мyдищах и на винишко запивать дошик. А в гейареа этого на электричество только - P&G известные п-сы. Зато повесточка, а не повестка.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от llolik (ok), 31-Окт-23, 09:14
	> даешь только православный код от независимого сообщества свободных разработчиков! Которые питаться будут, видимо, святым духом. А жить, видимо, под деревом. > Давно пора сообществу объединиться и дружно выпилить весь некошерный код из ядра. Вам пора допиливать HURD. Кошерность в наличии. Пригодность к повседневной работе, правда, пока сомнительная.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	24. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 09:23
	> Которые питаться будут, видимо, святым духом. А жить, видимо, под деревом. Кент так и попал в майнлайн, никто не спонсировал его 10 лет вджоба. Он просто упрямый чувак, который не хотел сдаваться и гнул свое. Так что вот - можно и без корпораций за спиной. Получите факты и распищитесь. И да, конечно у него есть ряд единомышленников которые постепенно прикинули что дельная штука и упрямый чувак это интересное комбо и стали тоже комитить. Забесплатно, ага. И тут вопрос в том что результат должен стоить того чтобы на него время потратить, а лидер проекта должен внушать доверие своими решениями. Иначе будет хреначить как шишкин, один в чистом поле. А каким бы крутым вы ни были, продвинутую файлуху в 1 фэйс в чистом поле хреначить пупок таки может и развязаться "вдолгую". Кент так то на прошлом ядре обломался т.к. не вкомитил в -next а сам между прочим не пробовал клмпилять под ВСЕ платформы где линух работает. А оно и покажи Торвальдсу FTBFS. Ну Кент и был послан в -next на ту итерацию, там толпа народа поможет затестить код и как минимум его билдовку на куче всего ДО того как это ухнуть ВСЕМ на бошку. Не, Торвальдс это не та тушка который FTBFS релизнет, это тертый калач, с ним такая фигня не случается. Он научился понимать что ему подсовывают и какие проблемы это принесет практически на уровне интуиции.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от llolik (ok), 31-Окт-23, 11:01
	Это всё, конечно, интересно, но Кент Оверстрит совершенно случайно занялся этим, когда ушёл из Гугла в Datera, которая, сюрприз, занималась хранилищами данных. На патреоне он пишет, что последнее время жил на сбережения, пока поживёт с Патреона, но если будет не хватать, то уйдёт искать работу. Шишкин работает в Хуавее и хрен его знает, чем там занимается. Видимо теорией, потому что практических результатов как-то не видать. И, честно говоря, такого персонажа из команды лично я-бы выботал сразу-же. При этом - это всего лишь одна конкретная ФС. Давайте проведём небольшой подсчёт: изменения в последнее ядро вносили 2058 человек. Насколько я помню последнюю статистику, которую я видел, процент волонтёров составлял тотальные 10%  от общего патчсета. Получается, что за зарплату в ядро ~1850 человек. Доход Кента на Патреоне €2,186/month (возьмём для простоты рассчётов 2000). Не знаю, сколько участвует мейнтейнеров, но давай, для простоты пусть они же будут активными разработчиками. Добьём до 1900 администраторов и прочих сопровождающих: Линуса, ГКХ и т.д. Получается, что на хотя-бы проживание/пропитание, в размере Кент-а, сообщество свободно должно собирать 1900 * 2000 = €3800000/month, что равно €45600000/year. это без учёта налогов и комиссий. Это только ядро, без libc и прочей экосистемы. Потянем?
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 31-Окт-23, 11:18
	>процент волонтёров составлял тотальные 10% Это на основе открытых данных, но каждый волонтёр же не обязан отчитываться о том, где он работает. А где работает большинство ИТ-шников? В корпорациях и тп. Поэтому реальный процент действительно независимых (в финансовом плане) волонтеров еще меньше.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 31-Окт-23, 12:33
	> Потянем? На самом деле легко. И не только это. Но есть нюанс. Длиной в пару сотен страниц, если излагать коротко. Ну или укладывающийся в совсем короткую формулировку: не при текущих социально-экономических отношениях. Но это совсем коротко и ничего не объясняет на самом деле. К сожалению.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	174. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (4), 31-Окт-23, 19:01
	В вашем мире розовых пони и не такое возможно, только какое это имеет отношение к реальности?
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 31-Окт-23, 20:21
	> В вашем мире розовых В каком именно?
	Ответить | Правка | Наверх | Cообщить модератору

	222. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 04:56
	>> Потянем? > На самом деле легко. И не только это. Но есть нюанс. Длиной > в пару сотен страниц, если излагать коротко. Если излагать коротко, такие вещи надо делать в стране где работают кикстартер и прочие индигого и патреоны. Там можно просто накинуть проект в стиле могу так-то и так-то, а что, дадите денег сделать это, ALL?! Зачастую ALL решает что затее - быть. Забыв спросить экспертов с опеннета. > Ну или укладывающийся в совсем короткую формулировку: не при текущих > социально-экономических отношениях. Но это совсем коротко и ничего не > объясняет на самом деле. К сожалению. У россиян уровень общества... как бы это сказать... еще не готов к постиндустриалу и таким взаимодействиям. Отставание годков на 200+.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	299. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 18:25
	> Если излагать коротко, такие вещи надо делать в стране где работают кикстартер > и прочие индигого и патреоны. Там можно просто накинуть проект в > стиле могу так-то и так-то, а что, дадите денег сделать это, > ALL?! Зачастую ALL решает что затее - быть. Забыв спросить экспертов > с опеннета. это хорошо работает для идеи продать, например, собачью какашку инкрустированную сваровски. Правда, один раз, поскольку число покупателей очевидно конечно. Или просто нести чушь на ютубе. Там даже миллионером можно стать, правда желательно личико посмазливее и пол предположительно женский. Число потре6лятей бесконечное зато. С каждого по копеечке... А для идеи тяжело и много пахать много лет подряд чтобы сделать что-то для людей - не работает. Вот вообще никак. Даже больше шансов в стране где работает только boomstarter и военкомат. Там хотя бы аренда развалюхи в мудищах дешевая. То есть я знаю чувака который не то чтобы пришел вот к успеху, но на еду себе _пару_раз_ заработал профессиональным трудом. Но он тощий и непривередливый. Т.е. эта еда на самом деле частенько - миска риса. А большинство прожектов на шитстартере заканчиваются хорошо если не скандалом а тихим исчезновением авторов навсегда.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 02-Ноя-23, 07:46
	> это хорошо работает для идеи продать, например, собачью какашку инкрустированную сваровски. С всяким технологичным добром тоже нормуль. Я проверял. > желательно личико посмазливее и пол предположительно женский. Число потре6лятей бесконечное > зато. С каждого по копеечке... Меня там интересовали чисто технологические штуки, и это все недурно работало. А насчет сваровски хрен его знает, я не эстет а технарь. > А для идеи тяжело и много пахать много лет подряд чтобы сделать > что-то для людей - не работает. Вот вообще никак. Смотрите дети это называется "выученная беспомощность". Когда этого лоха даже китаец безродный обставляет. Хотите быть такими? Берите пример с "эксперта". Тоже сможете вечно ныть, жаловаться, не показать ни 1 готового проекта, бжад, зато пальцы загнуть. Круто, ценно и гарантирует светлое будущее по жизни и любимую работу с достижением в ней успехоа </sarcasm>. > Даже больше шансов в стране где работает только boomstarter и военкомат. Там > хотя бы аренда развалюхи в мудищах дешевая. Как ты сам и сказал - "не живи в ж@пе". > тощий и непривередливый. Т.е. эта еда на самом деле частенько - миска риса. Пожиратели риса поумнее - себе сделали килобаксов, и довольно много. Но они в отличие от - не ныли и набивая себе цену могли и прототипы показать, немного убедительнее чтоб денег дать. > А большинство прожектов на шитстартере заканчиваются хорошо если не скандалом а тихим > исчезновением авторов навсегда. С твоим оптимизмом лучший бизнесплан - участок на кладбище ухватить. Со скидочкой. Для себя, ессно. Выгода же очевидна, да?!
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 08:00
	> С всяким технологичным добром тоже нормуль. Я проверял. не-а. вложенные усилия не оправдывают барышей. Поэтому мой знакомец начинавший с действительно технологичного добра - теперь перепродает китай галимый (с минимальным тюнингом чтоб нельзя было взять сразу у китайца). Пипл активно хавает, и его, пипла этого, оказалось куда больше чем фриков которым нужно или точнее которые готовы оплачивать в те же деньги высокотехнологичное и не ширпотреб. > Меня там интересовали чисто технологические штуки, и это все недурно работало. дурно. Поэтому они и не держатся больше пары лет. А чаще всего сразу бульк-вникуда (отдельный привет тем кто такое купит надеясь на докупить по мере роста) > А насчет сваровски хрен его знает, я не эстет а технарь. А ты цены смотри, эстет хренов. > Смотрите дети это называется "выученная беспомощность". Когда этого лоха даже китаец безродный > обставляет. спасибо, но я и не соревновался с китайцем в том что и сколько можно сделать за плошку риса. Я в конце-концов большую часть жизни прожил в очень богатой стране с бесконечными деньгами из дырки в болоте. >> хотя бы аренда развалюхи в мудищах дешевая. > Как ты сам и сказал - "не живи в ж@пе". это вот ты LA ведь сейчас обоcpaл? Ну понимаешь, климат восточного побережья подходит единицам. А в техасе тебя просто отп-дят. shelter state, ffffuck... > Пожиратели риса поумнее - себе сделали килобаксов, и довольно много. ха-ха-ха > С твоим оптимизмом лучший бизнесплан - участок на кладбище ухватить. Со скидочкой. Для себя, > ессно. Выгода же очевидна, да?! с твоим знанием жизни за пределами подвала - у тебя все бизнеспланы какой-то сплошной эпикфейл.
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 02:50
	> не-а. вложенные усилия не оправдывают барышей. Поэтому мой знакомец начинавший с > действительно технологичного добра - У тебя знакомые поди такие же лузеры как и ты сам. Мойкой собак занимайтесь, с вашим иррациональным забагованым менталитетом это потолок. И то какой-нибудь волкодав порвет нафиг. > теперь перепродает китай галимый (с минимальным тюнингом чтоб > нельзя было взять сразу у китайца). А тот китаец случайно не на кикстартере бутстрапался? Потом, когда разгонится, ему кикстартер, конечно, уже не особо то и требуется. Да и направление уже взлетело, +1 точно такое же - слишком банально. Вот если что заметно лучше конкурентов и не бакланить... но... у стартапов бывают факапы. > Пипл активно хавает, и его, пипла этого, оказалось куда больше чем фриков > которым нужно или точнее которые готовы оплачивать в те же деньги высокотехнологичное > и не ширпотреб. Ну тут уже каждому свое видимо. А можно и вообще собак мыть, на мой вкус купипродайство в чисотом виде - примерно настолько же возбуждающе. >> Меня там интересовали чисто технологические штуки, и это все недурно работало. > дурно. Поэтому они и не держатся больше пары лет. А чаще всего > сразу бульк-вникуда (отдельный привет тем кто такое купит надеясь на докупить > по мере роста) Да нормально они держатся. Просто если штука была дельная, тот кто ее делал отбутстрапался и стал относительно известным в некоем сегменте. Потом ему услуги кикстартера уже не особо и нужны, его и так знают, буфер на маневры и так есть и зачем тогда им кикстартер? Толпа китайцев с их выводками оттуда и полезли. Теперь им ессно нафиг не. >> А насчет сваровски хрен его знает, я не эстет а технарь. > А ты цены смотри, эстет хренов. Да надоели вы своими комплексами уже. Мысли вокруг денег крутятся только у лузеров у которых их нет. И вы так сказочно палитесь на эту тему, да еще с уверенным видом выдавая поучения. Столь же "ценные" как и технологический аспект. Извини, но - не хочется сидеть пешкой в мегакорпе с виндочкой и нтфс как предел мечтаний. > спасибо, но я и не соревновался с китайцем в том что и > сколько можно сделать за плошку риса. У тех которые на кикстартере плошек риса нормуль так то. И живут они получше тебя. По наверное всем мыслимым аспектам, начиная с здравоохранения какого-нибудь. > Я в конце-концов большую часть жизни прожил в очень богатой стране с > бесконечными деньгами из дырки в болоте. А они - научились как стать из грязи в князи. И придумали что делать с наковыреными из дыр редкоземельными элементами и проч, что еще денежнее. Вон тех на это не хватило, слишком ж@пные технологически. Теперь китай всех и взял за вымя с какими-нибудь неодимовыми магнитами. А те раки сидят с сибирью и дальним востоком забитым тем же самым, но найти, наковырять и извлечь пользу им не дано. Могли бы быть мощной технологической нацией, но - не судьба. А китайцы активно заселяют регион, догадываясь о том чего там есть и почему это им хорошо. >> Как ты сам и сказал - "не живи в ж@пе". > это вот ты LA ведь сейчас обоcpaл? Ну понимаешь, климат восточного побережья > подходит единицам. Вообще хороший климат в райских уголках, но там всякие папуасы которые только недавно отучились жарить себе подобных на костре. И если вебманчить там еще может прокатить то вот что-то более материальное по части технологий там все же душновато. > А в техасе тебя просто отп-дят. shelter state, ffffuck... По моему в РФии сейчас от314дят гораздо быстрее, и никогда не угадаешь по какому критерию. Толи что-то не того цвета одел, толи кто ремарки на свой счет принял, толи нация в паспорте у кого неправильная, или не той вере в пол бряцается, а может просто надо было срочно амбразуру заткнуть. >> Пожиратели риса поумнее - себе сделали килобаксов, и довольно много. > ха-ха-ха Они так то по сравнению с россиянами очень неплохо живут. И ряд из них неплохо отбутстрапились на кикстартере и прочих индигогах. А россияне в основном и вынуждены на подс@се у них быть. Делать самим такое же - дороже и хреновее. При том это еще и чисто технологический факап, у россиян все довольно плохо с тем же производством печаток. Оно дорогое и маломощное. Почти на уровне сша. Только вот богатых буратин чтобы отбить такие конские ценнички в роли покупателей - нету. Да и made in england или usa какой еще что-то значит, а in russia... эм... за рекламу товара не проканает. Взбесившиеся хрычи - на словах патриоты, но денег не дадут ни копья и вообще им и механические крутилки с помойки збс. > с твоим знанием жизни за пределами подвала - у тебя все бизнеспланы > какой-то сплошной эпикфейл. Ну, зато это будет мой эпикфейл (или уж там что) и мне будет некого винить за это. Гораздо обиднее если еще и как дурак повелся на чужой рецепт.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 01-Ноя-23, 21:24
	> Если излагать коротко, такие вещи надо делать в стране где работают кикстартер > и прочие индигого и патреоны. Там можно просто накинуть проект в > стиле могу так-то и так-то, а что, дадите денег сделать это, > ALL?! Зачастую ALL решает что затее - быть. Забыв спросить экспертов > с опеннета. Да, оно в принципе неплохо. И даже иногда работает. Но я о другом. Достаточно провернуть один "простой" фокус. Сделать так, чтобы рабочий час (день, неделя, минута, секунда - единицы могут быть любыми) человека стоил одинаково. Т.е. каждый получает за час труда одинаковое количество ресурсов (или денежных единиц: деньги - это ведь просто средства обмена продуктами труда, ничего более). Независимо от должности и специальности. Главное, чтобы труд был общественно полезен (продукты труда нужны ещё хотя бы одному другому человеку). При таком устройстве экономической системы оплатить труд одного человека - вообще не проблема. Никто даже не заметит, что он за что-то платил (потому что в таком случае все расходы будут распределяться на всё общество целиком).  Ну и да, всё написанное - это очень сжатое и краткое описание, чтобы передать саму идею. Там на самом деле, как и говорил, много чего ещё нужно. Вроде нормального социального обеспечения и т.д. > У россиян уровень общества... как бы это сказать... еще не готов к > постиндустриалу и таким взаимодействиям. Отставание годков на 200+. Нет, не было и не будет никогда никакого "постиндустриального общества". Просто потому, что всё это нужно рассматривать в совершенно другой плоскости. А "постиндустрилаьное общество" было придумано только с одной целью - запудрить всем мозги, пока "правильные" люди будут рубить бабло. Чтобы никто не понял, чем "правильные" люди на самом деле занимаются, что они - просто обычные паразиты.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	340. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 02-Ноя-23, 07:06
	> Достаточно провернуть один "простой" фокус. Сделать так, чтобы рабочий час (день, неделя, минута, завоняло коммуняками > секунда - единицы могут быть любыми) человека стоил одинаково. и человечеству мгновенно настанет п-ц. Под лозунгом "и таааак сойдет!" Раз час стоит одинаково - этот болт я забью первым попавшимся молотком. Причем на самом деле я разумеется никакие болты забивать не буду, вообще. Молоток тяжел, пыли много, час стоит одинаково. Поэтому я пошел гулять собак. И точно то же самое сделают все остальные кроме совсем уж больных фриков (да и у тех внезапно могут найтись навыки попроще кодинга - а цена та же), и болты забивать станет некому и привлечь к этому занятию никого не получится. Все возят пальцем по экрану формочки в юнити, если с собаками не сложились отношения. Цена ж одинакова. > При таком устройстве экономической системы оплатить труд одного человека - вообще не проблема. наоборот. При таком устройстве вообще непонятно кто будет платить. Ну то есть я догадываюсь, кто - Старший брат будет, который и будет решать, чей труд полезен а чей не очень. У коммуняк оно так всегда. Тебе - платить нечем. Ты же за час получаешь ровно столько, сколько и я. А чтоб что-то жрать, где-то спать и на чем-то сидеть - тебе понадобится очень, очень много этих самых чужих часов. Гораздо на самом деле больше чем у тебя их в сутках.
	Ответить | Правка | Наверх | Cообщить модератору

	354. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от ProfessorNavigator (ok), 02-Ноя-23, 12:57
	> завоняло коммуняками Вы говорите так, как будто это что-то плохое. Хотя сами наверняка даже не представляете, что это такое. Почитайте, там реально есть, что критиковать. Только для начала неплохо бы хотя бы в общих чертах представлять, что предлагали эти люди. > Раз час стоит одинаково - этот болт я забью первым попавшимся молотком. > Причем на самом деле я разумеется никакие болты забивать не буду, вообще. > Молоток тяжел, пыли много, час стоит одинаково. Поэтому я пошел гулять > собак. А это откровенная чушь. Во-первых, потому что вам же вашим изделием в том числе и пользоваться потом. Это только при капитализме человек полностью отчуждён от продуктов своего труда. Во-вторых, если вы сделаете плохо, то другой человек, который будет пользоваться вашим изделием, тоже сделает не очень. А его изделием пользоваться уже вам. Т.е. вы сами себе гадить будете? А в-третьих, это опровергнуто практикой, и не раз. В 1950 году там, где я живу, не было ничего. Лес и городок на 20 тысяч жителей, к которому посуху не добраться было просто - дорог не было, только по речке. Улицы все земляные, ни одной хотя бы мощёной, не говоря уж про асфальт. Из всей "промышленности" - дизель-электростанция на 50 киловатт и цех по заготовке рыбы. К 1957 году построен город на 300 тысяч жителей (плюс-минус), старый город перенесён на другое место, на противоположном берегу реки построен ещё один город. Города со всеми удобствами - пятиэтажные дома, водопровод, канализация, газ, электроэнергия. Квартиры выдавались абсолютно бесплатно. Первый стадион появился уже в 1950 году, первые кинотеатры - чуть позже. Построен цементный комбинат, город соединён с общей железнодорожной сетью (проложено более 200 км жд путей), проложены нормальные автомобильные дороги, начато строительство предприятий будущего промышленного узла (три химкомбината, завод по производству промышленных трансформаторов и др.). Ну и такая "мелочь", как ГЭС, на тот момент - одна из крупнейших в мире. 28,5 млн кубометров грунта земляной плотины, порядка 18 млн кубометров бетона. ГЭС соединена с общей энергосетью, в том числе проложена прямая линия до Московского промышленного узла (около 1000 км). Выработка электроэнергии - 10 370 млн кВт·ч в год, плюс-минус. И всё это за 7 лет, с нуля. Построено одними и теми же людьми, которые приехали сюда на стройку. Сами себе построили дома, построили плотину и ГЭС. И стоит оно до сих пор (70 лет уже почти), и простоит ещё столько же, если стрелять по нему не начнут. В городе на сегодня проживает около 700 тысяч человек. И это только одна стройка. В это же время - запущен первый спутник, создана атомная промышленность и т.д. После самой страшной войны в человеческой истории прошло чуть больше 10 лет, с момента, когда страна была полностью крестьянской, фактически - без промышленности, в руинах после гражданской войны - около 35 лет. Напомните, какие достижения в нашей стране за последние 30 лет? "...этот болт я забью первым попавшимся молотком". "Поэтому я пошел гулять собак". Ну-ну...   > Тебе - платить нечем. Ты же за час получаешь ровно столько, сколько > и я. А чтоб что-то жрать, где-то спать и на чем-то > сидеть - тебе понадобится очень, очень много этих самых чужих часов. > Гораздо на самом деле больше чем у тебя их в сутках. Это сейчас оно так. Ну и как вы сами сказали - нужно очень много часов. Потому что каждый сегодня зависит от каждого. Каждый зависит от общества. И в то же время является его частью. И экономическая система должна быть организована соответствующим образом. А не по типу "кто больше утащит".
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 14:24
	> А это откровенная чушь. Во-первых, потому что вам же вашим изделием в > том числе и пользоваться потом. Это только при капитализме человек полностью из ста собранных мной тумбочек я буду пользоваться в лучшем случае одной - а скорее всего мне именно тумбочка нахрен и не нужна. Поэтому я и буду их все делать одинаково хреново. И так будет у всех. > отчуждён от продуктов своего труда. Во-вторых, если вы сделаете плохо, то > другой человек, который будет пользоваться вашим изделием, тоже сделает не очень. именно (в том числе потому что то что он сделает ему самому тоже не нужно - тем более в таком количестве). Поэтому все в г-не, примерно одинаково - по подбородок. > К 1957 году построен город на 300 тысяч жителей (плюс-минус), старый вы уверены что это было - силами тех первых 20? Я вот уверен что силами зеков. большие гэс в совке другим способом и не строились. > и теми же людьми, которые приехали сюда на стройку. Сами себе > построили дома, построили плотину и ГЭС. И стоит оно до сих и внезапно сделались никому не нужны, потому что для эксплуатации гэс требуется совсем не квалификация бетонщика. Но на деле лагеря просто перевели в другое место, а вам об этом по молодости лет ничего не рассказали. > Это сейчас оно так. Ну и как вы сами сказали - нужно > очень много часов. Потому что каждый сегодня зависит от каждого. Каждый > зависит от общества. И в то же время является его частью. > И экономическая система должна быть организована соответствующим образом. А не по она и организована - в нормальном обществе. Кредит называетсо. Именно потому что обеспечить себя всем и сразу - невозможно продавая только свой труд. А где-то жить и что-то жрать тебе надо прям счас а не через недельку (или вот как у этого неудачника вообще через десять лет).
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 02-Ноя-23, 15:03
	> из ста собранных мной тумбочек я буду пользоваться в лучшем случае одной > - а скорее всего мне именно тумбочка нахрен и не нужна. > Поэтому я и буду их все делать одинаково хреново. > И так будет у всех. По-моему, я вам только что это всё наглядно опроверг, так что повторяться не вижу смысла. > именно (в том числе потому что то что он сделает ему самому > тоже не нужно - тем более в таком количестве). Поэтому все > в г-не, примерно одинаково - по подбородок. Да вот именно поэтому - потому что никто смысла в своём труде не видит. Зачем? Если у тебя всё "дядя-хозяин" заберёт и себе в карман положит. > вы уверены что это было - силами тех первых 20? Я вот > уверен что силами зеков. большие гэс в совке другим способом и > не строились. Так я и не говорил, что силами  только тех первых 20. Люди ехали сюда со всей страны, сами. Потому что им давали жильё и давали работу. С обучением - техникум и институт были одними из первых построенных объектов. И всё, повторюсь бесплатно. А зеки... Как вы думаете, как мои дед с бабкой здесь оказались? Вот так вот и оказались. На стройке год за 3 (или 4 - уже не помню) шёл. И было зеков от всего состава Куйбышевгидростроя не более 5% (и то - это я скорее всего сильно загнул). А в 1958 году дед квартиру получил. Потом ещё и побольше предлагали - вместо двухкомнатной, трёхкомнатную. И другая бабка тоже сидела, а семью её раскулачивали (точнее - сбежали они до того). Только вот ни от кого от них я не слышал ни слова осуждения. Даже когда уже можно стало. Наоборот, даже в девяностые повторяли, что всё было правильно.   > и внезапно сделались никому не нужны, потому что для эксплуатации гэс требуется > совсем не квалификация бетонщика. Так никто и не говорит, что все строители остались ГЭС обслуживать. Многие потом разъехались. Например в Египте Асуанскую плотину строили. А многие остались, работать на стройке промузла, потом - ВАЗа. Или просто работать - на построенных заводах. Дел всем хватало, а переобучение было бесплатным. > Но на деле лагеря просто перевели в другое место, а вам об > этом по молодости лет ничего не рассказали. Чушь откровенная. И даже понятно, зачем сочинённая. Чтобы не вспоминали, что можно и по-другому, а не как сейчас. > она и организована - в нормальном обществе. Кредит называетсо. Не наелись ещё? Кредитов? Мало? Ничего, посмотрим, что скажете через пару лет. Или даже через год. Если будет, кому говорить, с учётом всего происходящего... > Именно потому что обеспечить себя всем и сразу - невозможно продавая только > свой труд. Чушь. > А где-то жить и что-то жрать тебе надо прям счас а не > через недельку (или вот как у этого неудачника вообще через десять > лет). Вот потому и говорю - социально-экономические отношения должны выстраиваться совершенно по-другому. В СССР, пока всё как надо делали, никто на отсутствие жратвы не жаловался. Может и не было 150 видов колбасы, но голодных тоже не было.
	Ответить | Правка | Наверх | Cообщить модератору

	373. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 16:07
	> По-моему, я вам только что это всё наглядно опроверг, пока что только высказал свои прекрасные фантазии. О несуществующем манямирке. > Да вот именно поэтому - потому что никто смысла в своём труде не видит. Зачем? Если у тебя всё > "дядя-хозяин" заберёт и себе в карман положит. какая разница кто заберет? Мне стотыщ одинаковых тумбочек даром не нужны, забирай нахрен. Но дядя вообще-то денег заплатит (если они не все молотком собраны) а вот председатель твоего колхоза - просто пригрозит еще и корову отобрать. > Люди ехали сюда со всей страны, сами. Потому что им давали жильё и давали работу. а там откуда ехали - не давали. А кто у нас решает кому давать и где? Правильно, мудрые лучшие представители, через которых народ и потребляет все блага. > Наоборот, даже в девяностые повторяли, что всё было правильно.   так и говорили - правильно нас раскулачили. А отца - прадеда твоего - повесили. Тоже правильно. Ибо нефиг жить хорошо. > Так никто и не говорит, что все строители остались ГЭС обслуживать. Многие потом разъехались. и снова выживание на стройке века, и снова ни кола ни двора. Прекрасная жизнь! > Или просто работать - на построенных заводах. Дел всем хватало, а переобучение было бесплатным. потому что квалификация была - нулевая. А сварщик или слесарь шестого разряда - это седоватый лысеющий дядька сильно за 40. Потому что быстрее бывает очень редко. И переучить одного в другого - не получится. И это еще - все еще примитивные рабочие специальности. Так вот, у меня для тебя неприятный сюриприз - цивилизацию делают те дядьки. А у цивилизации чернорабочих ничего кроме китайского плана по черному металлу не получится. > Чушь откровенная. ври да не завирайся. Развалины лагерей стоят до сих пор. И полярная железная дорога тоже еще не вся заросла. Только выкормыш телевизора может отрицать то что все еще можно потрогать руками. И кладбища тех кто все это построил - тоже еще можно найти если чуток отойти оттуда где их уже перепахали бульдозерами. >> она и организована - в нормальном обществе. Кредит называетсо. > Не наелись ещё? Кредитов? Мало? Ничего, посмотрим, что скажете через пару лет. дурашка... У тебя горизонт планирования - дожить до следующей выплаты пенсии, я правильно понимаю? Ну да, конечно - планировать должна партея. А мы - куды пошлютъ. Ничего что в пятый раз придется все бросить и начинать на голом месте - вождям-то оно виднее. Зато без кредитов. > Может и не было 150 видов колбасы, но голодных тоже не было.   и это тоже вранье. То что ты их не видел - это примерно вот как "правильно раскулачили и посадили". Потому и не видел что не хотел увидеть. Я видел.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 02-Ноя-23, 17:49
	> пока что только высказал свои прекрасные фантазии. О несуществующем манямирке. "Гляжу в книгу - вижу фигу". Понятно)) Ну и да - придумайте уже что-нибудь новое. Выражение "манямирок", честно говоря, надоело уже. Фантазии ни на что другое не хватает? > Но дядя вообще-то денег заплатит (если они не все молотком собраны) а > вот председатель твоего колхоза - просто пригрозит еще и корову отобрать. Чушь. Колхоз то мне принадлежит, как его члену. И что-то там отобрать у меня могут только по решению всего колхоза, а никак не председателя. А "дядя" вам так заплатит... Потом догонит - и ещё заплатит. > а там откуда ехали - не давали. А кто у нас решает > кому давать и где? Правильно, мудрые лучшие представители, через которых народ > и потребляет все блага. И снова чушь. Это вы про сейчас говорите. Сегодня - да, всё так. > так и говорили - правильно нас раскулачили. А отца - прадеда твоего > - повесили. Тоже правильно. > Ибо нефиг жить хорошо. "Повесили" - это противоположная сторона. Белогвардейцы вешать любили. Пороть - тоже. Не все конечно, там люди всякие были. Слащёв например. А коммунисты (и то не напрямую можно сказать) участвовали в повешении тех, кто подсудимыми был на Нюрнбергском процессе. Но тут только пожалеть можно, что не всех повесили. А дело выживших живет и здравствует. В вашем лице в том числе, кстати. > и снова выживание на стройке века, и снова ни кола ни двора. > Прекрасная жизнь! Да ну, прям "выживание"?)) Такое выживание, что люди ещё и институт окончить умудрялись параллельно с работой. Я бы вот хоть сейчас на такое выживание подписался. > потому что квалификация была - нулевая. А сварщик или слесарь шестого разряда > - это седоватый лысеющий дядька сильно за 40. Потому что быстрее > бывает очень редко. И переучить одного в другого - не получится. > И это еще - все еще примитивные рабочие специальности. Опять чушь. Как думаете, сколько сварщиков работало на постройке ГЭС? С учётом того, что был возведён целый арматурный завод, чтобы варить готовые конструкции для тех самых 18 миллионов кубометров бетона. И квалификация их была - выше некуда: плотина уже почти 70 лет стоит. И, как и сказал, будет и дальше стоять. > Так вот, у меня для тебя неприятный сюриприз - цивилизацию делают те > дядьки. А у цивилизации чернорабочих ничего кроме китайского плана по черному > металлу не получится. А я что, где-то утверждал обратное?)) Тут вы сами с собой спорите. Как бы ладно. "Чем бы дитя не тешилось..." > ври да не завирайся. Это как раз к вам. Потому что про "развалины лагерей" - откровенная ложь. Да ещё и заезженная. Ознакомьтесь, если интересно: https://www.youtube.com/watch?v=AFCZR7FNVbs&list=PLHfd11lpeE... Мне лень тут очередное сочинение на тему писать. > У тебя горизонт планирования - дожить до следующей выплаты пенсии, я > правильно понимаю? Боюсь, что это скорее к вам)) Как говорится - у кого что болит, тот о том и говорит. С учётом вот этого: > То что ты их не видел - это примерно вот как "правильно > раскулачили и посадили". Потому и не видел что не хотел увидеть. > Я видел.
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 18:25
	> Фантазии ни на что другое не хватает? ну я вижу что у тебя фантазии действительно ни на что другое не хватает. дискуссия закончена > Ознакомьтесь, если интересно: нет, мне вранье коммуняк неинтересно.
	Ответить | Правка | К родителю #381 | Наверх | Cообщить модератору

	386. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 02-Ноя-23, 18:43
	> дискуссия закончена Up to you. > нет, мне вранье коммуняк неинтересно. Да понятно, что вам кроме собственного вранья и иллюзий ничего не интересно))
	Ответить | Правка | К родителю #384 | Наверх | Cообщить модератору

	370. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 02-Ноя-23, 15:13
	>> завоняло коммуняками > Вы говорите так, как будто это что-то плохое. Хотя сами наверняка даже > не представляете, что это такое. Почитайте, там реально есть, что критиковать. > Только для начала неплохо бы хотя бы в общих чертах представлять, > что предлагали эти люди. Да так то весьма не плохо для некоторых - жить за счёт других и опуская более способных. >> Раз час стоит одинаково - этот болт я забью первым попавшимся молотком. >> Причем на самом деле я разумеется никакие болты забивать не буду, вообще. >> Молоток тяжел, пыли много, час стоит одинаково. Поэтому я пошел гулять >> собак. Это констатация факта. Достаточно посмотреть на код Коммуниста, положив рядом учебник "С++ за 21 день". Болт как бы забит, но продержится он, только если его не трогать.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	372. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 02-Ноя-23, 15:25
	> Да так то весьма не плохо для некоторых - жить за счёт > других и опуская более способных. Это вы про сейчас? Да, всё так и есть. Конкуренция банальная за жратву. Самое что интересное, на ровном месте. Достаточно паразитов прихлопнуть, и всё внезапно поменяется. Вдруг выяснится, что если все нормально работают, то и всего же всем хватает. > Достаточно посмотреть на код Коммуниста, положив рядом учебник "С++ > за 21 день". Болт как бы забит, но продержится он, только > если его не трогать. А это здесь причём?)) Если что-то не нравится - включайтесь в разработку. Я только рад буду, у меня тупо времени на всё не хватает.
	Ответить | Правка | Наверх | Cообщить модератору

	409. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (409), 03-Ноя-23, 12:22
	>> Да так то весьма не плохо для некоторых - жить за счёт >> других и опуская более способных. > Это вы про сейчас? Это про леваков вообще, что очевидно из вопроса, на который был дан ответ. > Да, всё так и есть. Конкуренция банальная за > жратву. Самое что интересное, на ровном месте. Достаточно паразитов прихлопнуть, и > всё внезапно поменяется. Вдруг выяснится, что если все нормально работают, то > и всего же всем хватает. А управленец, не смыслящий в элементарной психологии, он кто? Пока он правит умами на Опеннет, может он и не паразит. Так ему ведь этого мало, он стремится вверх по иерархии. >> Достаточно посмотреть на код Коммуниста, положив рядом учебник "С++ >> за 21 день". Болт как бы забит, но продержится он, только >> если его не трогать. > А это здесь причём?)) Если что-то не нравится - включайтесь в разработку. > Я только рад буду, у меня тупо времени на всё не > хватает. При том, что люди без квалификации принимаются за работу и делают её как попало, когда механизм распределения по соответствующим местам отсутствует. Разработка начинается с дизайна. Есть готовность принять патч, меняющий 90%? Только кто будет делать такое, если с 0 может оказаться быстрее.
	Ответить | Правка | Наверх | Cообщить модератору

	426. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 03-Ноя-23, 15:56
	> Это про леваков вообще, что очевидно из вопроса, на который был дан > ответ. Ну да, логично. Обвини оппонента в собственных грехах, пусть выкручивается, опровергая очевидный бред. Классика, можно сказать. Докажите, что "леваки" сидят на шее у других - тогда поговорим. Только прежде чем что-то доказывать, ознакомьтесь с Манифестом коммунистической партии хотя бы. И подумайте - кто реально коммунист, а кто лишь называет себя таковым. > А управленец, не смыслящий в элементарной психологии, он кто? Неквалифицированный управленец? Вообще же - проясните свою мысль, а то не очень понятно о чём вот это и зачем. > При том, что люди без квалификации принимаются за работу и делают её > как попало, когда механизм распределения по соответствующим местам отсутствует. Разработка > начинается с дизайна. Вы о чём вообще?)) И да, дизайн - это не нужно. Эргономика - нужно, а дизайн - нет. > Есть готовность принять патч, меняющий 90%? Не вопрос - присылайте, посмотрим. > Только кто > будет делать такое, если с 0 может оказаться быстрее. Опять же не вопрос - делайте своё, лучше. Я совершенно не против. Пока же ничего, кроме пустой болтовни нет.
	Ответить | Правка | Наверх | Cообщить модератору

	448. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (409), 04-Ноя-23, 08:13
	>> Это про леваков вообще, что очевидно из вопроса, на который был дан >> ответ. > Ну да, логично. Обвини оппонента в собственных грехах, пусть выкручивается, опровергая > очевидный бред. Классика, можно сказать. Вот именно, классика. Цитирую себя дословно: "Да так то весьма не плохо для некоторых - жить за счёт других и опуская более способных." Ответом было: "Конкуренция банальная за жратву." Для непонятливых - я ни на кого не указывал. Так что нечего на зеркало пенять. > Докажите, что "леваки" сидят на шее у других - тогда поговорим. Предлагая сменить порядок в обществе, следует доказывать его состоятельность и превосходство. Не демагогией, а расчётами. И тем более не стоит перекладывать бремя доказательства на оппонента, если, конечно, нет желания в очередной раз показать свою суть. >> А управленец, не смыслящий в элементарной психологии, он кто? > Неквалифицированный управленец? Вообще же - проясните свою мысль, а то не очень > понятно о чём вот это и зачем. О неприемлемости демагогии при попытках управления. Не надо считать окружающих за дураков, тогда и не примутся зеркалить. >> При том, что люди без квалификации принимаются за работу и делают её >> как попало, когда механизм распределения по соответствующим местам отсутствует. Разработка >> начинается с дизайна. > Вы о чём вообще?)) И да, дизайн - это не нужно. Эргономика > - нужно, а дизайн - нет. Я об отсутствии квалификации автора, как примере плодов типичного коммунизма. Выше я заявил это "голословно", теперь обосную: Для программиста "дизайн" это синоним "архитектура" и относится к коду: иерархия классов, деление на функциональные блоки (работа с сетью, интерфейс пользователя и т.п.). Для пользователя "дизайн" это окошки и кнопочки. Выбор сделан. >> Есть готовность принять патч, меняющий 90%? > Не вопрос - присылайте, посмотрим. Не стоит подменять тезис, это демагогия. Не посмотреть, а принять - то есть безусловная посылка.
	Ответить | Правка | К родителю #426 | Наверх | Cообщить модератору

	456. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 04-Ноя-23, 13:41
	> Вот именно, классика. > Цитирую себя дословно: "Да так то весьма не плохо для некоторых - > жить за счёт других и опуская более способных." > Ответом было: "Конкуренция банальная за жратву." > Для непонятливых - я ни на кого не указывал. Так что нечего > на зеркало пенять. Ещё как указывали. А то, что как раз капиталисты сидят на шее у других - я вам докажу на раз-два-три. Экономическая система работает на разделении труда. Т.е. каждый производит какую-то малую часть большого целого. При этом без этой малой части целого не будет. Значит для производства целого одинаково важен труд каждого. От простого работяги, программиста или уборщицы, до директора предприятия. Однако почему-то те же директора получаю зарплату в разы выше, чем рядовые сотрудники. А владелец, если он не занимаtт какую-либо должность, так и вовсе банальный паразит. Ну и? Кто тут у кого на шее сидит? > Предлагая сменить порядок в обществе, следует доказывать его состоятельность и превосходство. > Не демагогией, а расчётами. Да я в общем-то так и делаю. Или вы требуете, чтобы я вам здесь вот прям научную работу написал? Так площадка, мягко говоря, для этого не предназначена. Но тем не менее - извольте. http://samlib.ru/editors/b/bobylew_j_w/society.shtml Только если соберётесь возражать - то извольте писать по пунктам, со ссылками на научные публикации. Иначе вы - обычный болтун. > И тем более не стоит перекладывать бремя > доказательства на оппонента, если, конечно, нет желания в очередной раз показать > свою суть. Так это вы набрасываете, что "леваки сидят на шее у других". А у нас как бы действует презумпция невиновности (смешно конечно, но формально - никто её не отменял). А значит бремя доказательства лежит на вас. Так что вперёд. А мы посмеёмся. > О неприемлемости демагогии при попытках управления. Не надо считать окружающих за дураков, > тогда и не примутся зеркалить. А?! И всё равно не понял, о чём вы. Выражайтесь яснее. Реально не понимаю, к чему вот это всё. Вы обвиняете меня в некомпетентности? Так я вроде бы не утверждал, что я чем-то руковожу. Вы обвиняете ещё кого-то в некомпетентности? Кого именно? > Я об отсутствии квалификации автора, как примере плодов типичного коммунизма. Обобщение, а значит сразу чушь. Тем более - без обоснований. > Выше я > заявил это "голословно", теперь обосную: > Для программиста "дизайн" это синоним "архитектура" и относится к коду: иерархия классов, > деление на функциональные блоки (работа с сетью, интерфейс пользователя и т.п.). Не нравится - не пользуйтесь. Или пишите что-то своё. Код открыт. > Для пользователя "дизайн" это окошки и кнопочки. Не нравится - не пользуйтесь. Или выдвигайте конкретные предложения. > Выбор сделан. Пафос прям зашкаливает)) > Не стоит подменять тезис, это демагогия. Не посмотреть, а принять - то > есть безусловная посылка. Ага, щаз. Если вы такой "умный" - делайте своё и развлекайтесь как хотите. Благо, код открыт. Не можете сделать своё - значит будете играть по моим правилам. C'est la vie.
	Ответить | Правка | К родителю #448 | Наверх | Cообщить модератору

	458. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (409), 04-Ноя-23, 16:19
	>> Вот именно, классика. >> Цитирую себя дословно: "Да так то весьма не плохо для некоторых - >> жить за счёт других и опуская более способных." >> Ответом было: "Конкуренция банальная за жратву." >> Для непонятливых - я ни на кого не указывал. Так что нечего >> на зеркало пенять. > Ещё как указывали. Ложь и клевета. Подтвердить цитатами, по моему примеру, не смог и не сможешь. Примешься юлить и выкручиваться, привычно передёргивая... Вместо этого, сейчас самое время тебе остыть, выкинуть из головы идеологию, внимательно перечитать "диалог" и осознать, что я сделал. Я не заставлял писать тебя нужное мне, что бы в итоге уделать тебя твоими выводами в твоей же системе ценностей. Я знал, что будет мне в ответ. Мне было интересно лишь, сколько сообщений займёт комбинация. Мой интерес удовлетворён и на этом закончился. А ты посчитай заодно. >> Выше я заявил это "голословно", теперь обосную: >> Для программиста "дизайн" это синоним "архитектура" и относится к коду: иерархия классов, >> деление на функциональные блоки (работа с сетью, интерфейс пользователя и т.п.). >> Выбор сделан. > Не нравится - не пользуйтесь. Или пишите что-то своё. Код открыт. Не надо обижаться, это вполне нормально для первой программы. Но и мой посыл подменять не следует. Это не наезд на код, а пример, что при коммунизме люди заняты не своим делом и делают его абы как. Очень кстати, что называется программа соответствующие.
	Ответить | Правка | К родителю #456 | Наверх | Cообщить модератору

	465. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 04-Ноя-23, 18:49
	> Ложь и клевета. Подтвердить цитатами, по моему примеру, не смог и не > сможешь. Примешься юлить и выкручиваться, привычно передёргивая... > Вместо этого, сейчас самое время тебе остыть, выкинуть из головы идеологию, внимательно > перечитать "диалог" и осознать, что я сделал. Я не заставлял писать > тебя нужное мне, что бы в итоге уделать тебя твоими выводами > в твоей же системе ценностей. Я знал, что будет мне в > ответ. Мне было интересно лишь, сколько сообщений займёт комбинация. Мой интерес > удовлетворён и на этом закончился. А ты посчитай заодно. Уважаемый, нельзя же так)) Я от хохота под стол укатился. Так и травму недолго получить. Великий Комбинатор, блин. Когда подтверждение вашего наброса будет, тогда и поговорим. Но что-то, чувствую, не дождусь. Ну хотя бы посмеёмся, и то хлеб... > Не надо обижаться, это вполне нормально для первой программы. Так никто вроде бы и не обижается. Я ж говорю: можете лучше - делайте, для того код и открыт. Я только порадуюсь - можно будет другими делами заняться. > Но и мой посыл подменять не следует. Это не наезд на код, > а пример, что при коммунизме люди заняты не своим делом и > делают его абы как. Очень кстати, что называется программа соответствующие. И как кислое связано с зелёным? А про "абы как" обсудили уже выше. Всё настолько абы как сделано было, что СССР 30 лет уже как нет, а мы всё что-то этим абы как пользуемся.
	Ответить | Правка | К родителю #458 | Наверх | Cообщить модератору

	472. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (409), 05-Ноя-23, 06:21
	Вот это стремление леваков - оказаться всегда правыми - весьма занятно, как феномен. Однако, в данном случая я тебе написал, что мой интерес закончился. Поскольку ты не понял, упрощу: ты впустую написал свой ответ, мелком по его структуре вижу, что нет смысла читать.
	Ответить | Правка | К родителю #465 | Наверх | Cообщить модератору

	473. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 05-Ноя-23, 11:56
	> Вот это стремление леваков - оказаться всегда правыми - весьма занятно, как > феномен. Забавно. Вы никаких вменяемых контраргументов не приводите, но при этом пытаетесь казаться правым. Т.е. делаете ровно то, в чём обвиняете других. Впрочем, как уже сказал - классика. > Однако, в данном случая я тебе написал, что мой интерес > закончился. Поскольку ты не понял, упрощу: ты впустую написал свой ответ, > мелком по его структуре вижу, что нет смысла читать. "Ничего не вижу, ничего не слышу, ничего не знаю! И вообще - я в домике, отстаньте от меня все!" Ох-хо-хо...
	Ответить | Правка | К родителю #472 | Наверх | Cообщить модератору

	474. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (409), 05-Ноя-23, 13:06
	Похоже, я недостаточно ясно выразился в #472. Но ты продолжай.
	Ответить | Правка | К родителю #473 | Наверх | Cообщить модератору

	401. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (401), 03-Ноя-23, 03:09
	> одинаково. Т.е. каждый получает за час труда одинаковое количество ресурсов (или > денежных единиц: деньги - это ведь просто средства обмена продуктами труда, Натурный эксперимент показал что приводит это к пафосным отчетам о своей нужности, продвижению всякого жулья и бесполезняка. С убиением мотивации тех кто может. А зачем стараться если ничего не изменится? В результате в магазине - купить нечего. Отчеты покупать не хотят, даже если денег напечатать. А больше ничего нет, фактическое состояние дел почему-то далеко от надписей на бумаге, и озверевший плебс рвет глотки за последний шкаф, а потом и последнего куря. > ничего более). Независимо от должности и специальности. Главное, чтобы труд был > общественно полезен (продукты труда нужны ещё хотя бы одному другому человеку). Все и становятся мастерами доказывания своей полезности - при мизерном результате. И так приходишь в магаз - а там фига. А на бумаге все ЗБС. Где-то я это уже видел. Капитализм это лечит. Жестко но по крайней мере коллапс в случае чего имеет ограниченный масштаб. А вон там вся страна крякнула когда отчетоклепательство превысило возможности экономики. И что могут сделать высокомотивированные инженеры той страны я видел, спасибо, сами пользуйтесь ЭТИМ. > При таком устройстве экономической системы оплатить труд одного человека - вообще > не проблема. В этой схеме только 1 факап: как отсеивать страдальцев фигней, особенно если они в отчетики умеют? А, никак? Капитализм имеет на этот счет план - если никто не платит за работу, она не нужна! Займитесь чем-то иным, или иначе. А вон те до упора метут ломом плац, обнаружив жестким способом что в магазе нечего купить. > деле, как и говорил, много чего ещё нужно. Вроде нормального социального > обеспечения и т.д. Увы, эту схему пытались заимплементить и не срослось. Реальные двуногие оказались менее сознательными, более жуликоватыми и хорошо стало совсем не тем кому следовало бы. А плохо стало стране в целом. > Нет, не было и не будет никогда никакого "постиндустриального общества". Просто потому, > что всё это нужно рассматривать в совершенно другой плоскости. > "правильные" люди на самом деле занимаются, что они - просто обычные > паразиты. Ога, при том паразиты обычно верткие ребята и в паразиты первым делом запишут кого угодно кроме них. В случае капитализма - ну, только паразитировать и совсем ничего не делать все же не выгодно. Инфляция жрет капитал, налоги на имущество и проч подстригают, а если товар не нужен - его не купят, и приходится так или иначе вертеться.
	Ответить | Правка | К родителю #311 | Наверх | Cообщить модератору

	425. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 03-Ноя-23, 15:41
	> Натурный эксперимент показал Натурный эксперимент как раз показал, что при внедрении рыночной экономики всё происходит так, как вы сказали. > Все и становятся мастерами доказывания своей полезности - при мизерном результате. И > так приходишь в магаз - а там фига. А на бумаге > все ЗБС. Где-то я это уже видел. Да, вот сейчас это как раз и происходит, толь с той разницей, что в магазине вроде бы всего до фига, а купить нечего. Ввиду отсутствия денег и продукции нормального качества. И дальше будет ещё хуже. > Капитализм это лечит. Капитализм работает ровно до того момента, пока можно свалить от него подальше. На какой-нибудь фронтир, где никого нет, но зато есть ресурсы. А поскольку такие времена закончились лет 200 назад... В общем у меня для вас плохие новости. И да, если что, всё происходящее в мире сегодня (голод, войны, нищета) - это всё капитализм. Он вот такой. Нравится? > В этой схеме только 1 факап: как отсеивать страдальцев фигней, особенно если > они в отчетики умеют? А, никак? Капитализм имеет на этот счет > план - если никто не платит за работу, она не нужна! > Займитесь чем-то иным, или иначе. А вон те до упора метут > ломом плац, обнаружив жестким способом что в магазе нечего купить. А я думал - догадаетесь. Впрочем - это ж надо голову напрягать, о чём я... В общем, если коротко, вводите такой показатель, как производительность труда (количество произведённых продуктов труда к затраченному времени), и смотрите в среднем по отрасли. Подробней - смотрите тут: http://samlib.ru/editors/b/bobylew_j_w/society.shtml#TOC_id2..., а то писать уже лень. > Увы, эту схему пытались заимплементить и не срослось. Реальные двуногие оказались менее > сознательными, более жуликоватыми и хорошо стало совсем не тем кому следовало > бы. А плохо стало стране в целом. Всё срослось, просто дураков к власти пускать не нужно. Если б не срослось, мы бы с вами сейчас не общались. Потому что и ваши, и мои предки в газовых камерах бы свой путь закончили. > Ога, при том паразиты обычно верткие ребята и в паразиты первым делом > запишут кого угодно кроме них. Да, всё так, достаточно вокруг посмотреть. > В случае капитализма - ну, только > паразитировать и совсем ничего не делать все же не выгодно. Инфляция > жрет капитал, налоги на имущество и проч подстригают, а если товар > не нужен - его не купят, и приходится так или иначе > вертеться. Сказки то не рассказывайте. На банковский сектор посмотрите. Ну и паразит не обязательно ничего не делает, он как раз обычно изображает бурную деятельность. И делает всё, чтобы было хорошо лично ему - паразиту. Только вот обществу от этого наоборот не очень хорошо становится. Что собственно мы и наблюдаем на практике - минус миллион населения в год. И так уже 30 лет. И не только у нас, что характерно, а везде, даже в Китае уже как бы "весело" с рождаемостью. А всё потому, что человек - животное общественное, причём не один миллион лет уже. Разделение труда и всё такое. И если обществу плохо, то и человеку рано или поздно плохо становится.
	Ответить | Правка | Наверх | Cообщить модератору

	436. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 17:52
	> Натурный эксперимент как раз показал, что при внедрении рыночной экономики всё происходит > так, как вы сказали. Я видел СССР 80х и 90х, ДО того как рыночек пришел. Страшнее ядерной войны выглядело. Даже дефолтсити весь раздристаный, обшарпаный, разваливается, рассыпается, ржавеет, не достроено, гниет под открытым небом, фонари не горят, асфальт как и в деревне гадюкино, ... . Потратить банку краски, балку покрасить? Что вы! Вот когда проржавеет - и все навернется с треском, кто-то может и получит люлей. Но там уже банкой краски не отделаешся. Объекты без собственников - это как-то вот так. Жизня в таком постапокалипсисе, с пустыми магазами - ну такое себе, имхо. А с чего полкам не пустыми быть, если все мастера отчеты строчить, и доказывать свою нужность, получая зарплату и - истошно протирая штаны и делая фигню? Почему фигню? Потому что при первом намеке на конкуренцию ЭТОТ ХЛАМ покупать резко перестали. В общем в том виде что-то не очень оно сработало, имхо. > Да, вот сейчас это как раз и происходит, толь с той разницей, > что в магазине вроде бы всего до фига, а купить нечего. > Ввиду отсутствия денег и продукции нормального качества. И дальше будет ещё хуже. В общем то в РФ верховодят примерно те же рожи которые вон то вызвали, выводов особо не сделали, с чего результату другому быть? А, теперь они еще не стесняются светить часами как ваша зарплата за год. Или два. Впрочем они и раньше себя не обижали. > мире сегодня (голод, войны, нищета) - это всё капитализм. Он вот > такой. Нравится? Я видел как у СССР получилось и на их фоне капитализм не так уж плохо - и неизмеримо честнее. По крайней мере не врут с три короба про высокое, сидючи с голой дж@ппой. А в коммерческой корпе честно говорят - мы тут собираемся чтобы делать то-то и то-то, как поработаем так и получим, деньги из ниоткуда не возьмутся. Если продажи не прут, ну вот вам лысый оклад чтоб совсем с голоду не умерли, и хорош. А если мегабаксы сделали - тогда вот вам совсем другой объем, с вашего же продукта! Хороший стимул не протирать штаны, как поработаешь напрямую маппится в благосостояние. Ясен хрен продукты так лучше получаются. И страдать фигней чревато выходит. >> Займитесь чем-то иным, или иначе. А вон те до упора метут >> ломом плац, обнаружив жестким способом что в магазе нечего купить. > А я думал - догадаетесь. Впрочем - это ж надо голову напрягать, > о чём я... В общем, если коротко, вводите такой показатель, как > производительность труда ...и все начинают его накручивать. И даже гнать Его Величество План. Улучшать что-то?! Расстрелять мерзавца, как это, конвеер стопорить?! Даешь план! Так что вот вам доисторическое г@вно, зато план выполнен. А разработчики и инноваторы ну разве что не враг народа, и то как повезет. > (количество произведённых продуктов труда к затраченному времени), Видел я какие продукты в результате этого получаются. Почему-то в результате при первом намеке на конкуренцию такие производители и продукты пролетели. Видимо, еще голимнее чем у вон тех получается. Так что вам ли их критиканить? > Всё срослось, просто дураков к власти пускать не нужно. Ну вот у капиталистов это более-менее естественно получается, и косячинг не вылезает за пределы корпы. А банкротство как раз о том чтобы сменить косячное руководство прежде всего и попытаться рестартануть фирму. Ну или если совсем никак, значит оно совсем гнилое и тогда только закрыть и распродать. Если до упора тянуть безблагодатную гирю и толпу тех кто работать не хочет пойдете вместе с этой гирей на дно. Что и случилось. > Если б не срослось, мы бы с вами сейчас не общались. Потому что и > ваши, и мои предки в газовых камерах бы свой путь закончили. Вон то стало актуально где-то к 60-70 годам прошлого века, когда мир стал сложнее, и старые подходы катить перестали. Ну а СССР так и не смог адаптироваться к этому. > Да, всё так, достаточно вокруг посмотреть. Можно подумать советская номенклатура была сильно другой. Те же примерно рожи и перекрасились по быстрому, заодно и показав чего все их моральные устои реально стоят. > Сказки то не рассказывайте. На банковский сектор посмотрите. Ну и паразит не > обязательно ничего не делает, он как раз обычно изображает бурную деятельность. Ну так банки дело добровольное. Не хотите - не пользуетесь. Все как бы честно. > И делает всё, чтобы было хорошо лично ему - паразиту. Только > вот обществу от этого наоборот не очень хорошо становится. По этой причине современный вариант капитализма таки - регулируемый. Особенно по части монополий и проч. Россияне и это поняли как-то по своему, госы замочили все живое. Получив самый дурацкий вид капитализма - государственный. Те же яйца что до него были, вид в профиль. А какой смысл для гос переложить деньги из левого кармана в правый? > Что собственно мы и наблюдаем на практике - минус миллион населения в год. Ну так человеколюбивая политика правительства стала воздаваться. А не должна была? Ща вам "русских" завезут, откуда там. > один миллион лет уже. Разделение труда и всё такое. И если > обществу плохо, то и человеку рано или поздно плохо становится. Насколько я вижу - у россиян все это было никак не 30 лет назад, а скорее 50+. Примерно с 70х прошлого века поперло ломовое отставание от более развитых стран.
	Ответить | Правка | Наверх | Cообщить модератору

	440. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 03-Ноя-23, 21:37
	По пунктам разбирать - больно долго получится, поэтому отвечу на всё разом, так сказать. Я понимаю, что в восьмидесятые и девяностые было, мягко говоря, не весело. И как раз об этом и говорю - нельзя было вводить элементы рыночной экономики. Но их ввели и получили закономерный результат - всё перечисленное вами. И начали их вводить второй половине пятидесятых, просто тогда это было незаметно из-за большого запаса прочности экономики. Какие элементы? Собственно хозрасчёт, что по сути есть возрождение конкурентной борьбы за ресурсы между хозяйствующими субъектами. Конкуренция же постепенно потянула за собой другие "радости". Результат закономерный - к середине восьмидесятых всё начало рассыпаться. Плюсом - Афганистан. Нужно было делать как раз противоположное - убирать взаиморасчёты между хозяйствующими субъектами полностью. Так чтобы всё можно было продать только государству и купить только у государства. А роль государства должна заключаться в удовлетворении запросов с мест. Нормальном удовлетворении. Т.е. с контролем - действительно ли требуется столько, сколько запросили, и возможно ли дать столько. Собственно почти так оно и работало после войны. Но потом дурь ударила в голову, и понеслась. А капитализм, если рассматривать его беспристрастно - всё. Он себя давно уже изжил. Как написал в другом посте - он работает ровно до того момента, пока от него можно свалить подальше. Сегодня главный вопрос: закончится ли капитализм вместе с нами или всё же кто-то выживет? И выяснится это всё не когда-то там, а в ближайшие 5-10 лет, а то и гораздо раньше.
	Ответить | Правка | Наверх | Cообщить модератору

	444. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 04:29
	> так сказать. Я понимаю, что в восьмидесятые и девяностые было, мягко > говоря, не весело. И как раз об этом и говорю - нельзя было вводить элементы > рыночной экономики. Совсем без них и СССР не обошелся, денежная система оказалась гибче, а "трудодни" и "талоны" - вы за них и инженерьте. > большого запаса прочности экономики. Какие элементы? Собственно хозрасчёт, что по сути > есть возрождение конкурентной борьбы за ресурсы между хозяйствующими субъектами. На мой вкус это забавная теория, но... 1) История не знает сослагательного наклонения, не узнаем что было бы. 2) Идея что без конкуренции получится что-то хорошее доверия не вызывает. Конкуренция хорошо прочищает мозги. 3) Уравниловка имхо ведет к доминированию бесполезнях, пафосным отчетам при отсутствии результата на полках. 4) Упомянутый пример с условной балкой никак не адресуется, нет шкурного интереса в коллективной собственности у конкретного индивидуала. 5) Если посмотреть сколько раз россияне учебники истории корежили и меняли то что на тетрадках написано (да, я видел и вариаты еще с интернационалом) - другие такой фигней не занимаются. Ваши правители заврались в край. > за собой другие "радости". Результат закономерный - к середине восьмидесятых всё > начало рассыпаться. А я то думал что рассыпаться стало от технологического отставания. Когда экспорт сдох, обмен технологиями и проч - отвалился, отставание накопилось, экспорт и валюта кончились. Ну а внутренние резервы прожрали клепатели отчетов. После чего оказалось что полки что-то пустые, а в отчетах все сильно лучше чем на полках. > Плюсом - Афганистан. Я вообще не понимаю что там СССР забыл. Порубаться с США через прокси? В результате огребли и те и другие. Почему это было круто и стоило того по моему не понял вообще никто. > было продать только государству и купить только у государства. А роль > государства должна заключаться в удовлетворении запросов с мест. Почитав "радио" 70х-80х я видел как это работает. Разница в заказе регионами микросхем на порядки, на вопросы "почему так" никто ответить не может. Намекает на компетенцию руководителей. Как вы думаете что было бы с вон тем если на них ВСЕ свалить, без failsafe? Имхо поплохело бы еще быстрее. > Нормальном удовлетворении. Т.е. с контролем - действительно ли требуется столько, > сколько запросили, и возможно ли дать столько. Ну вон там хмырь и написал что всему региону надо 100 микросхем в год. Зато его ценной ж@пе безопасно от проверок. Уж сто то микросхем ему найдут. То что в регионе будет жесткий дефицит не его проблема, он свой зад зато прикрыл. На практике получается что фиг с благом страны, свой зад прикрыть важнее. > Собственно почти так оно и работало после войны. Но потом дурь ударила в > голову, и понеслась. А капитализм, если рассматривать его беспристрастно - всё. > Он себя давно уже изжил. Ну, он перетек в адаптивные, гибридные формы. И дальше будет жить черти сколько. > выяснится это всё не когда-то там, а в ближайшие 5-10 лет, > а то и гораздо раньше. На мое мнение это будет выглядеть иначе. А для россиян я ничего хорошего через 5-10 лет не вижу, увы. Предпосылок нет.
	Ответить | Правка | Наверх | Cообщить модератору

	454. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 04-Ноя-23, 13:09
	> Совсем без них и СССР не обошелся, денежная система оказалась гибче Нет. Она - одна из главных причин того, что экономика посыпалась. Потому что в своём сегодняшнем виде позволяет концентрировать в одних руках ресурсов больше, чем было этими руками по эквиваленту произведено. Т.е. паразитировать. > 1) История не знает сослагательного наклонения, не узнаем что было бы. Узнаем. Только не что было бы, а что будет. Если повезёт - если люди головой думать начнут. Если нет - не узнаем. Просто потому, что узнавать некому будет. > 2) Идея что без конкуренции получится что-то хорошее доверия не вызывает. Конкуренция > хорошо прочищает мозги. А я и не предлагаю убирать её. Я предлагаю перевести её в другую плоскость. Из варианта "кто больше жрёт", во вариант "кто умнее". Не хочешь работать руками - не вопрос. Учись, подтверждай квалификацию, получай повышение. Лень учиться? Опять же не вопрос - работай руками. Но ресурсов всё равно будешь получать одинаково. Потому что в работе экономической системы одинаково важен труд как тех, кто работает руками, так и тех, кто работает головой. С точки зрения экономики важно сколько часов ты работал (т.е. сколько тебе нужно предоставить ресурсов взамен - еды, воды и т.д.), и сколько при этом произвёл (производительность труда). Часы рабочие у всех одинаковые, потребности - плюс-минус тоже. Значит за один час ты, работяга Вася (программист Петя) получишь ровно столько же, сколько директор завода Александр Петрович. А за то, что мало произвёл... Ну как вариант, вместо того, чтобы развлекаться вечером, будешь сидеть на курсах повышения квалификации. Или общественными работами заниматься. Или тебя и вовсе на другую работу переведут. Не захочешь подчиняться - ну так это уже полноценный саботаж. Дальше общество в лице трудового коллектива будет решать, что с тобой делать. Например - порицание вынести. Публично, при собрании всего коллектива. Если не поможет - ну так есть народный суд. Если же наоборот, много произвёл - так как бы молодец. Публичное одобрение тебе и сокращение рабочих часов на следующей неделе с сохранением заработной платы.    > 3) Уравниловка имхо ведет к доминированию бесполезнях, пафосным отчетам при отсутствии > результата на полках. Никакой уравниловки. Я лишь говорю, что уравнять нужно то, в чём люди и так по факту равны - в количестве потребляемых ресурсов. А не равны люди в другом - в знаниях и умениях. Ну так вот в эту сторону и нужно переводить конкурентную борьбу. И не как сейчас, а как это делалось в СССР - трудовое соревнование. Кто больше и лучше сделал - тому почёт, уважение и слава. > А я то думал что рассыпаться стало от технологического отставания. Это как раз следствие, а не причина. Экономическая система начала работать криво, а значит на науку и разработки тратилось ресурсов меньше. Как следствие - наука начала отставать. Ну и откровенные глупости, вроде попыток объявить генетику лженаукой и т.п. Поэтому и говорю - нельзя пускать во власть дураков. Если совсем упрощать - никакого продвижения по партийной линии. Ты начальник, потому что ты больше знаешь и умеешь, а не потому что "идеологически правильный". Но при этом каждый должен чётко понимать, что и зачем в государстве делается. А это уже работа системы образования. > Я вообще не понимаю что там СССР забыл. Порубаться с США через > прокси? В результате огребли и те и другие. Почему это было > круто и стоило того по моему не понял вообще никто. Ни одна война "крутой" быть не может. А с Афганистаном всё достаточно просто - в руководстве страны никто толком не понимал, какие цели мы перед собой ставим там. Что конкретно на практике хотим получить. Самостоятельное полноценное государство-союзника? Ну так это было невозможно, просто потому, что там людей нужно было бы лет 100 учить, строить дома, предприятия, школы и т.д. И в таком случае нужно было бы включать Афганистан в СССР, как ещё одну республику. Но тут бы государство уже просто не потянуло. Да и соседи по планете не оценили бы такого маневра. А послать их лесом тоже не вышло бы - опять же экономически не потянули бы. Но и не влезать туда было нельзя, иначе получили бы незатихающую войну на азиатских границах, героин и все сопутствующие. Оно в общем-то очевидно - достаточно на Афганистан сегодня взглянуть. Т.е. это был классический цугцванг, а значит ошибки были допущены гораздо раньше. В общем на мой взгляд наиболее безболезненным решением было бы всё же включение Афганистана в СССР на правах ещё одной республики. Но с той оговоркой, что в экономике нужно было перестать дурью маяться и начать заниматься делом. > Почитав "радио" 70х-80х я видел как это работает. Разница в заказе регионами > микросхем на порядки, на вопросы "почему так" никто ответить не может. > Намекает на компетенцию руководителей. Как вы думаете что было бы с > вон тем если на них ВСЕ свалить, без failsafe? Имхо поплохело > бы еще быстрее. Нет, повторюсь - оно всё работало. Просто начали вводить элементы рыночной экономики, а это в том числе привело к тому, что каждый стал за свою личную шкурку бояться, ибо конкуренция, а не делом заниматься. Результат - налицо. > Ну, он перетек в адаптивные, гибридные формы. И дальше будет жить черти сколько. Не-а. Всё просто, планета имеет конечные размеры и конечное же количество ресурсов. И либо мы начинаем их использовать рационально, а затем начинаем полноценную колонизацию Солнечной системы и дальше, либо вымираем. Капитализм рациональное использование не подразумевает ни в какой форме (и форма у него всегда одна, остальное - просто очередная попытка сместить акценты в нужную "правильным" людям сторону). Потому что построен на внутривидовой конкурентной борьбе за ресурсы. А это кровь, резня, голод. Можете поинтересоваться, чем подобное заканчивалось для других видов. Их сегодня обычно изучаю палеонтологи. Думаю - намёк ясен. Да и в целом каитализм противоречит эволюционному пути людей. Всю свою историю мы шли в сторону большей социализации и кооперации. Ну и так, на заметку - виду homo sapiense (т.е. нам) примерно 50 тысяч лет. Капитализм существует самое большее - 600 лет (если брать от зарождения мануфактур). И всю свою историю мы становились всё более социальными. Иными словами то, что происходит сегодня, просто небольшое отклонение в рамках статистической погрешности. Тем более, что по всем признакам как бы реально всё. Разгорающиеся по все планете войны тому подтверждением. > На мое мнение это будет выглядеть иначе. А для россиян я ничего > хорошего через 5-10 лет не вижу, увы. Предпосылок нет. Я вообще ни для кого ничего хорошего не вижу, не только для россиян. Будет много крови и войн. Надежда лишь на то, что в условиях дефицита ресурсов у людей голова начинает работать гораздо лучше. А значит есть шанс, что после кризиса удастся построить что-то вменяемое.
	Ответить | Правка | Наверх | Cообщить модератору

	491. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 14:52
	> Нет. Она - одна из главных причин того, что экономика посыпалась. Сомневаюсь. Но к ФС это все однако не относится. На правах идеи - этот подтред можно подвинуть куда-то в сторону. Сделав на форуме какую-нибудь секцию типа "офтопик" или "флейм". Я бы там может и подебатировал, а может и нет. Засорять топик про ФС спичем на грани политики и проч - мне не хочется. Все же в топике про ФС логично ФС обсуждать, ну может технологии вокруг, посетители не подписывались читать вместо ФС вот такие дебаты.
	Ответить | Правка | К родителю #454 | Наверх | Cообщить модератору

	494. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от ProfessorNavigator (ok), 08-Ноя-23, 21:16
	> Сделав на форуме какую-нибудь секцию типа "офтопик" или "флейм". Да кто б против был. Я только "за". > Все же в топике про ФС логично ФС обсуждать, ну может технологии вокруг, посетители не подписывались читать вместо ФС вот такие дебаты. Ну... Если пролистаете к тому, с чего всё началось, то заметите, что я в общем-то лишь высказал мнение по поводу "потянем ли содержать разработчиков". https://www.opennet.dev/openforum/vsluhforumID3/131934.html#95 И как бы ничего такого там не было. Но народу неймётся, и понеслась...
	Ответить | Правка | К родителю #491 | Наверх | Cообщить модератору

	139. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (139), 31-Окт-23, 15:49
	> Это всё, конечно, интересно, но Кент Оверстрит совершенно случайно занялся этим, когда > ушёл из Гугла в Datera, которая, сюрприз, занималась хранилищами данных. Ну молодец чувак: получил нужный бэкграунд, посмотрел вокруг, понял как такие вещи делать - и попер своей дорогой. Чем и крут. ИМХО, завидуй молча... > На патреоне он пишет, что последнее время жил на сбережения, пока поживёт > с Патреона, но если будет не хватать, то уйдёт искать работу. По-моему чертовски логичная надпись. А если ты так не можешь - ну окей, вот тебе я бы ни цента не насыпал. Да и остальные имхо тоже. И прочим похам - тоже. А за что? :) > Шишкин работает в Хуавее и хрен его знает, чем там занимается. Видимо > теорией, потому что практических результатов как-то не видать. И, честно говоря, > такого персонажа из команды лично я-бы выботал сразу-же. Он может и мощный теоретик - но абсолютная неспобность к даже минимальным компромиссам в большом проекте это грабли. Как и считание себя всегда и во всем правым. В большой штуке размером с линукс кернел есть чертова куча соображений от которых Шишкин страшно далек. И в этом месте в своем дизайне ПРИДЕТСЯ подвинуться. Иначе всем остальным его проще бортануть, чем огребать все связанные с этим проблемы. Даже если он трижды офигенный. > Получается, что на хотя-бы проживание/пропитание, в размере Кент-а, сообщество свободно > должно собирать 1900 * 2000 = €3800000/month, что равно €45600000/year. это > без учёта налогов и комиссий. Это только ядро, без libc и > прочей экосистемы. Потянем? ИМХО - это очень сильно зависит от того что и кто имеет предложить. А сообщество так то тоже довольно абстрактно. Ну вон Daniel Vetter'а перехватил после ухода из интеля небольшой но гордый стартап, предложив "работу мечты" на условиях где шутка про "вас пригласили директором корпорации Майкрософт" имевшая хождение в рунете - выглядит довольно блеклой. Это как бы фирма но состоит она из как бы вот того сообщества, руководилы разделяют вот те принципы, и просто основали фирму чтобы делать то что и раньше, но еще масштабнее. И вот сообщество они или нет? И если нет - с чего бы вдруг? А так развелось желающих считать чужие бабки. А скилл на эти бабки у вас есть? Что вы умеете чтобы вам как хотя-бы кенту вот именно сообщество накидало? Да и нормальные корпы за просто так денег давать не любят.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	149. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от llolik (ok), 31-Окт-23, 16:53
	Я тебе описал ситуацию. Всё. Исходя из какой альтернативной одарённости ты увидел здесь зависть - я не понял. От меня чуваку наоборот сплошной респект. Но то, что его разработки по-началу никто не спонсировал - это ИМХО неправда. > Он может и мощный теоретик - но абсолютная неспобность к даже минимальным > компромиссам в большом проекте это грабли. Как и считание себя всегда > и во всем правым. В большой штуке размером с линукс кернел > есть чертова куча соображений от которых Шишкин страшно далек. И в > этом месте в своем дизайне ПРИДЕТСЯ подвинуться. Иначе всем остальным его > проще бортануть, чем огребать все связанные с этим проблемы. Даже если > он трижды офигенный. Так, а я о чём. > А так развелось желающих считать чужие бабки. А скилл на эти бабки > у вас есть? Что вы умеете чтобы вам как хотя-бы кенту > вот именно сообщество накидало? Да и нормальные корпы за просто так > денег давать не любят. Ты вообще читал, что написано, или как всегда? Сформирую более конкретно, раз ты не смог: без корпов текущее "сообщество" не потянет оплату разработки production-ready ядра от слова совсем. Назови мне хоть один проект, который без корп.поддержки получает ~4 мегабакса в месяц донатов.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 31-Окт-23, 17:56
	Да нет, я уверен что так и есть - _разработки_ - никто не спонсировал. Просто у чувака было слишком много свободного времени на работе. А вот потом - состоялся осенний performance review, и пошел он жить в коробку от холодильника. С обещанием когда-нибудь вернуться и всем показать. Потому что непонятная возня с непонятно чем непонятно для чего - не была по достоинству оценена тимлидом. Ну или халявные денежки от IPO у лавки кончились, а продукт так и не появился.
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 02:12
	> Я тебе описал ситуацию. Всё. Исходя из какой альтернативной одарённости ты увидел > здесь зависть - я не понял. Я не знаю что за ситуацию ты описал. Но факты в том что Кент - вот - может покодить файлуху. И в один фэйс запинать это в майнлайн. Без корпа за спиной. И это круто. А подсчет чужих денег и вертухание перед корпами по моему это человека не украшает. Во всяком случае в линуксной экосистеме это отличный способ испортить себе карму. Линуксоиды всегда были гордым, сильным, самодостаточным проектом. И там люди которые умеют взять свое, а не лохи типа поха, ненавидящие свою работу, рекламящие винду и выгуливающую собак (какая шикарная иллюстрация успеха юниксвея или что там у них было). С такой рекламой пох добился того что отрекламил изучение альтернативных вэев, его участь мне не нравится, сорь :) > От меня чуваку наоборот сплошной респект. Но то, что его разработки по-началу > никто не спонсировал - это ИМХО неправда. Не вижу спонсорв которые бы прицельно спонсировали дизайн. А то что кто-то сто лет назад где-то работал, бэкграунд поднакопил, управление проектами немного посмотрел и проч... 1) Не делает его property of ... corp. 2) Не делает corp спонсором дизайна, корп возможно даже не в курсе что дизайн существует. 3) Чел не обязан до гроба жизни грести на ссаной галере которую однажды утопит манагер росчерком пера, списав проект в утиль по желанию левой пятки. >> он трижды офигенный. > Так, а я о чём. Ну вот тут консенсус. > Ты вообще читал, что написано, или как всегда? Сформирую более конкретно, раз > ты не смог: без корпов текущее "сообщество" не потянет оплату разработки > production-ready ядра от слова совсем. Ну во первых учитывая что ряд корпов пусть и умереенного размера состоят из выходцев этого сообщества - я вообще не понимаю почему жесткое противопоставление обязано быть. Во вторых, колхоз дело добровольное. И там никто никого не заставляет. Вопрос взаимовыгодных взаимодействий. Есть это - есть взаимодействия. Нет - ну, не судьба. В третьх, все и сразу не отвалится. И оно взлетело без корпов. Да, если те или иные корпы устранятся - масштаб снизится. С другой стороны и специфику этих корпов окучивать не надо будет и ряд вещей упростится. Поэтому имхо в реальном мире это более-менее самобалансирующийся процесс, где никто не имеет единоличного контроля а при серьезных терках он отребалансируется в что-то видоизмененное, с устранением тех шероховатостей. > Назови мне хоть один проект, который без корп.поддержки получает ~4 мегабакса > в месяц донатов. Я могу сказать что например помог бутстрапнуть несколько одноплатников и штук вокруг. Мне это было надо, я и впрягся. За это я свое разумеется получил. И там все причастные в обиде не остались, и повторить потом решили, и не раз. А направление взлетело. Так что это все еще и работает. Если предложить что-то более-менее полезное окружающим, а не распальцы уровня пох. За это ессно никто не заплатит. И сказ о крути нтфс и виндочки спеца врядли украшает как эксперта, хотя-бы потому что все это - вообще не его заслуга.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	236. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (4), 01-Ноя-23, 06:52
	Удивительно, почему это люди не хотят становиться столманутыми фанатиками и вопреки своим интересам батрачить за подачки? Во тупые!
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 09:08
	> Удивительно, почему это люди не хотят становиться столманутыми фанатиками и вопреки своим > интересам батрачить за подачки? Во тупые! Судя по тому что я вижу в результате они батрачат на еще более паршивых условиях. Хотя конечно острстрелить назло соседу свою пятку - ну тоже вариант, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (4), 01-Ноя-23, 06:37
	>Назови мне хоть один проект, который без корп.поддержки получает ~4 мегабакса в месяц донатов. Это же User294, он тут уже лет 10 всем рассказывает, как хорошо попрошайнить и бомжевать вместо того, чтобы найти высокооплачиваемую работу в солидной компании. Разумеется ни одного доказательства этому он никогда не приводит кроме своей шизы. Вот и тут ожидаемо слился.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	252. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 09:12
	> Это же User294, он тут уже лет 10 всем рассказывает, как хорошо попрошайнить > и бомжевать вместо того, чтобы найти высокооплачиваемую работу в солидной компании. Глядя на экземпляров типа поха, с виндочкой, нтфс и выгулом собак можно посмотреть на светлое будущее которое получается у солидных работяг в результате. Мне в этом будущем что-то не нравится. И вэйности для их носителей что-то не сработали, имхо. > Разумеется ни одного доказательства этому он никогда не приводит кроме > своей шизы. Вот и тут ожидаемо слился. И только безымянные додики все в белом. Рассказывают о мегадостижениях. В фиг знает чем. Наверное, в троллинге. Другой активности не замечено.
	Ответить | Правка | Наверх | Cообщить модератору

	351. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (351), 02-Ноя-23, 12:12
	Ты там ниже ответишь на вопрос про udp congestion control? Или опять начнешь рассказывать что в колбасе потребности нет?
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 16:11
	> Ты там ниже ответишь на вопрос про udp congestion control? Или опять > начнешь рассказывать что в колбасе потребности нет? напоминаю - http3 придуман гуглем. У него в такой колбасе потребности и правда нет - у него канал бездонный. А что у тебя забился гуглевым мусором - ну это твои проблемки, выкручивайся как хочешь. Технология неплохо уже отработана криворукими авторами битторента. Сами жить не будем и другим не дадим. Гугль вполне умеет делать правильные выводы.
	Ответить | Правка | Наверх | Cообщить модератору

	387. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (387), 02-Ноя-23, 19:18
	Это я знаю. Но надо же показывать как 294 в жир забегает ногами. Теперь у него два варианта. Или рассказывать что за него светлое будущее сделали корпорации, как им захотелось. Полностью забитый канала, каждое ПО должно само следить за полосой и т.д. А его "работе" место в мусорке. Только потому что по пути трафика другой udp трафик всё передавил. Прогресс. Второй вариант - он не понимает совсем в архитектуре ит и его предел - бирюльки катать на ардуинках. В то время пока умные дядьки тестируют и делают отличные delay-based протоколы. К сожалению лавочники всегда побеждают науку. Поэтому мы останемся с гугл-миром и вот такими голубями раскидавшими шахматы^W^W с ардуинкой.
	Ответить | Правка | Наверх | Cообщить модератору

	404. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 03:44
	> Это я знаю. Но надо же показывать как 294 в жир забегает > ногами. Теперь у него два варианта. Или рассказывать что за него > светлое будущее сделали корпорации, как им захотелось. Я никогда не утверждал что корпорации в принципе не могут сделать ничего стоящего. Я лишь против тезиса что на это у них есть какая-то монополия и это единственный возможный формат. Сабж лютый пруф обратного. И даже в btrfs core дизайна 1 конкретный человек делал. Таков путь: мы еще не научились в продвинутое совместное использование мозгов на таком уровне. > Полностью забитый канала, каждое ПО должно само следить за полосой и т.д. Если то что есть начинает вести себя неадекватно, тогда теория не выдержала проверку практикой и - надо заменить такое решение на то что будет работать лучше. Если у кого-то при этом что-то сколлапсирует, возможно, им пора проапгрейдить свое оборудование. Потому что их клиенты хотят большего чем они обеспечивают. > А его "работе" место в мусорке. Только потому что по пути трафика другой udp > трафик всё передавил. Прогресс. Я в таком случае отманеврирую и начну выглядеть так же, поэтому мне тоже ЗБС будет. А кто не адаптировался к изменениям - тот вымирает. Это древний паттерн. Я его усвоил. > Второй вариант - он не понимает совсем в архитектуре ит и его > предел - бирюльки катать на ардуинках. В то время пока умные > дядьки тестируют и делают отличные delay-based протоколы. А корпы делают замену этим дядькам именно потому что все ЗБС и им просто некуда деньги потратить, вот, страдают фигней. Логика, блин. > К сожалению лавочники всегда побеждают науку. Поэтому мы останемся с гугл-миром и > вот такими голубями раскидавшими шахматы^W^W с ардуинкой. Ну как бы высокие концепции это прекрасно но должно вести к практически значимым результатам. Электричество в виде игрушки для 5 фриков было бы намного менее эпично чем то что создалось из-за развития технологий вокруг. И уж конечно легиона бизнесов. Только представьте себе где был бы гугл если бы электричеством занимался пяток фриков на планете? Его бы не было! Или самый край это был бы DHL номер два. А мы бы обсуждали flow control дедушкиной берданкой в рамках RFC1149 "потому что пакеты весь подоконник засрали".
	Ответить | Правка | Наверх | Cообщить модератору

	442. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (442), 03-Ноя-23, 22:26
	Картонный. Ты может хоть на минуту свой фонтан остановишь и подумаешь зачем делают дэлей-бейзед протоколы согласования? Ах да, я же забыл. Только в ОС 50 летней давности она нормально применяется. А в модном ядре для всех оно так и не внедренр.
	Ответить | Правка | Наверх | Cообщить модератору

	445. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 04:38
	> Картонный. Ты может хоть на минуту свой фонтан остановишь и подумаешь зачем > делают дэлей-бейзед протоколы согласования? Ах да, я же забыл. Только в > ОС 50 летней давности она нормально применяется. А в модном ядре > для всех оно так и не внедренр. Как показали натурные испытания, иной раз и картонный - EPIC WIN. А некоторые вот только пальцы топырить умеют. На мое нескромное мнение вы можете юзать ваши протоколы 50-летней давности и ос - а мне весь этот мусор не уперся. Я за весь этот шит и такой работинг ни цента не отсыплю, а вот насчет сабжа - уже можно посмотреть чем этому типу можно помочь. И да я буду просто смотреть вокруг и наблюдать как и что работает и какие проблемы это привносит. И если работает хреново - значит пора это списать в утиль и попробовать что-то иное. Незвисимо от гениальности и чего там еще.
	Ответить | Правка | К родителю #442 | Наверх | Cообщить модератору

	403. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 03:33
	> напоминаю - http3 придуман гуглем. У него в такой колбасе потребности и > правда нет - у него канал бездонный. А что у тебя > забился гуглевым мусором - ну это твои проблемки, выкручивайся как хочешь. Хыхы, а вот всякие ретард-провайдеры с бсд-тазиками и конским оверселом - это и правда не проблема гугли. И в этом плане мои потребности не особо далеки от гугловых. Данные должны летать. По той инфраструктуре которая есть. Без идиотских взбрыков с ломовыми таймаутами и полпроцента использования канала и икающим видео в real-world сценариях. > Технология неплохо уже отработана криворукими авторами битторента. Сами жить не будем и > другим не дадим. Гугль вполне умеет делать правильные выводы. Академконцептуалы не оставили иного выбора кроме как "взять и у...ть!". Бывает так что шишкинобразные фрики и ушлые обладатели тазиков - понимают только такое. Теперь придется с этим жить и это тот случай когда я считаю что гугл все сделал правильно. А не можешь качать данные клиентов - не будь провайдером. Вали булочки печь, или чего там у тебя получается без трехэтажного облапошивания клиента.
	Ответить | Правка | К родителю #375 | Наверх | Cообщить модератору

	402. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 03:25
	> Ты там ниже ответишь на вопрос про udp congestion control? Или опять > начнешь рассказывать что в колбасе потребности нет? Приличный человек хотя-бы ссылку, чтоли, кинул. Вы, блин, показали что даже неразать эту колбасу не умеете - но хотите порассуждать о ней? При том в ветке про ФС почему-то?
	Ответить | Правка | К родителю #351 | Наверх | Cообщить модератору

	237. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (5), 01-Ноя-23, 06:58
	Изменения одной строки там тоже считаются, но не факт, что по суммарному объёму перевешивают вклад Кента. Так что это довольно сомнительная экстраполяция.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	52. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Шарп (ok), 31-Окт-23, 10:36
	Эдик, если код написан корпорацией, то это не значит, что там зонды. У тебя шиза прогрессирует.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

9. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
Сообщение от Аноним (8), 31-Окт-23, 08:35
К слову, в новости не упомянуты симпатии автора к Rust и мысли переписать на него. Часть утилит для работы/обслуживания вроде как на Rust, в репе у него целая папка https://github.com/koverstreet/bcachefs/tree/master/rust (но не копался, просто искал, где трудится после Google, и заметил краем глаза).
Ответить | Правка | Наверх | Cообщить модератору

	55. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Анонин (?), 31-Окт-23, 10:42
	Он ее собирается потом переписать на раст - тут упоминалось https://lwn.net/Articles/895266/. Но придется дождаться полноценной поддержки раста в ядре.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (8), 31-Окт-23, 11:10
	Именно об этом я и сказал. По вашей ссылке: > Overstreet said that there is already some user-space Rust code in the repository Я где-то наткнулся, что какие-то утилиты для обслуживания ФС уже на Rust, но, возможно, неправильно понял.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (145), 31-Окт-23, 16:00
	>в новости не упомянуты симпатии автора к Rust и мысли переписать на него Отличный повод держатся подальше от этой фигни.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (10), 31-Окт-23, 08:53
Почему Шишкин так не смог?
Ответить | Правка | Наверх | Cообщить модератору

	26. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (26), 31-Окт-23, 09:31
	Потому что не хотел
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от амерский ведроид (?), 31-Окт-23, 10:35
	Если бы работал в гугломазоне,то без вариантов тянул лямку 100500 лет
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от llolik (ok), 31-Окт-23, 12:00
	> Если бы работал в гугломазоне,то без вариантов тянул лямку 100500 лет Он работал в КрасноШапке, сейчас работает в Хуавее (ну, по крайней мере, мне не известно, что он оттуда уходил). И в чём отличие?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от амерский ведроид (?), 31-Окт-23, 12:12
	Майкрософт и Эпла. Теперь ваша очередь.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 15:57
	>> Если бы работал в гугломазоне,то без вариантов тянул лямку 100500 лет > Он работал в КрасноШапке, сейчас работает в Хуавее (ну, по крайней мере, > мне не известно, что он оттуда уходил). И в чём отличие? Ну, блин, Кент вот смог сделать что-то работающее, в виде в котором это замайнлайнили. Хоть и попив кровушки. А Шишкин сделал - ну вот чего? Что он из себя в отрыве от корпорации являет? Он сможет выйти и сказать "я сделал это", показав что-то кому-то полезное на практике? Дизайн Кента достаточно интересная штука. А Шишкин теоретизмы в основном разводит. При полной неспособности решать разногласия с майнлайном. Ну а вечно вне майнлайна висеть - кхм, а оно кому-то надо в таком виде?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	150. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от llolik (ok), 31-Окт-23, 16:55
	>[оверквотинг удален] >> Он работал в КрасноШапке, сейчас работает в Хуавее (ну, по крайней мере, >> мне не известно, что он оттуда уходил). И в чём отличие? > Ну, блин, Кент вот смог сделать что-то работающее, в виде в котором > это замайнлайнили. Хоть и попив кровушки. А Шишкин сделал - ну > вот чего? Что он из себя в отрыве от корпорации являет? > Он сможет выйти и сказать "я сделал это", показав что-то кому-то > полезное на практике? Дизайн Кента достаточно интересная штука. А Шишкин теоретизмы > в основном разводит. При полной неспособности решать разногласия с майнлайном. Ну > а вечно вне майнлайна висеть - кхм, а оно кому-то надо > в таком виде? А я о чём по твоему написал? Не об этом же?
	Ответить | Правка | Наверх | Cообщить модератору

11. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+4 +/–
Сообщение от Аноним (-), 31-Окт-23, 08:54
Ну, кент малацца. Через 10 лет впашки он таки дожал свое. Будущее принадлежит вот таким.
Ответить | Правка | Наверх | Cообщить модератору

12. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
Сообщение от Аноним. (?), 31-Окт-23, 08:56
К слову, а в сравнении с BTRFS, что стоит выбирать?
Ответить | Правка | Наверх | Cообщить модератору

	17. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+17 +/–
	Сообщение от Аноним (17), 31-Окт-23, 09:08
	ext4
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 31-Окт-23, 09:12
	> К слову, а в сравнении с BTRFS, что стоит выбирать? Сабж только войдет в январский релиз кернела как экспериментальный образец. И наверняка багов там будет немеряно, это ПЕРВЫЙ крупномасштабный разлет по планете. Ну вот и думай что выбирать. ...а вот годиков через 3-5 такой вопрос будет смотреться уже намного более осмысленно. Ты же не думал что звездолет экспериментальной модели отладят за два дня? И даже за 2 месяца - не отладят. И btrfs в 2.6.32 или где там его приняли - пару лет тоже использовать было достаточно рисково. А потом лажу разумеется вытряхнули. Да знаешь, даже EXT4 далеко не сразу стабильным и беспроблемным стал, а там фич даже и 10% нету. Если тебе покамикадзить на тестовом наборе данных - тогда другой вопрос, разумеется! Жди -rc1 и вперед на мины^W^W тьфу, добро пожаловать на борт то-есть.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	306. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (306), 01-Ноя-23, 20:14
	В целом полностью согласен с анонимом выше, за исключением одного - пробовал использовать BTRFS с 2017 года по 2023 и имею сказать, что "лажу" так до конца и "не вытряхнули" (( Она у меня два раза за это время крашилась до необратимого состояния (хотя я в потроха ФС не лез и обращался с ней бережно). Как думаете, сколько раз крашилась за это время ext4 на тех же самых хостах? Ага, угадали! Ноль :)
	Ответить | Правка | Наверх | Cообщить модератору

	405. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 03-Ноя-23, 10:30
	> В целом полностью согласен с анонимом выше, за исключением одного - пробовал > использовать BTRFS с 2017 года по 2023 и имею сказать, что > "лажу" так до конца и "не вытряхнули" (( > Она у меня два раза за это время крашилась до необратимого состояния > (хотя я в потроха ФС не лез и обращался с ней бережно). > Как думаете, сколько раз крашилась за это время ext4 на тех же > самых хостах? Ага, угадали! Ноль :) На поверку все случаи подобных репортов которые я видел - оказывались сбоящим железом. Скажи, чувак, а у тебя при работе в крейсерском режиме не было "csum error" случайно? Да, кроме всего прочего это еще и неплохой детектор глюкваого железа. Ну вот не дохнет это на исправном железе. И вон то случается только если там битая оепратива или глюкавый проц. А EXT4 что, ему все пофиг - у него даже чексум нет, даже и не узнаешь что данные побились. Поэтому юзерь узнает о факапах где-то сиииииильно опосля, когда либо метаданные станут совсем трухой. В чем проблема? В том что когда это все вылезает, состояние данных и метаданных уже воображение не поражает совсем. Правда я чаще на такое с нтфсом натыкался но это только потому что у юзерей его больше, чисто статистически. Как еще вариант - RAID56, но там честно warning сделали что - экспериментальное. Если кто забил на warning и не понимал что и как - ну, упс.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–4 +/–
	Сообщение от Минона (ok), 31-Окт-23, 09:15
	ZFS
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	29. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 09:45
	>  ZFS Out of tree выкидыш, даже без экстентов, с которым даже багрепорт на кернел не повесишь. Очень ценно. Только отстало на 2 поколения технологий и имеет нефиксабельные проблемы с внемайнлайновостью.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–4 +/–
	Сообщение от лютый арчешкольник... (?), 31-Окт-23, 09:46
	>ext4 для бэкапов нет, для данных да. >ZFS деградантская ФС, через год начинает на том же самом железе тупить. всё давно на btrfs перетащил, полет сразу стал шелковистым....
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	37. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Пряник (?), 31-Окт-23, 10:02
	Вот через год и узнаем правду.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Минона (ok), 31-Окт-23, 10:14
	> Вот через год и узнаем правду. Не узнаем, его арч развалится раньше :)
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от Аноним (125), 31-Окт-23, 14:44
	ты перепутал арч с манжарой
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (202), 01-Ноя-23, 00:33
	Так он же болгарин
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от лютый арчешкольник... (?), 31-Окт-23, 21:57
	>Вот через год и узнаем правду. с btrfs уже намного больше прошло, увы фанбои зфс, не тормозит. да, на тех серваках разумеется oracle linux
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	406. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 10:32
	>>Вот через год и узнаем правду. > с btrfs уже намного больше прошло, увы фанбои зфс, не тормозит. да, > на тех серваках разумеется oracle linux Меня они уже лет наверное 8-10 стращают как у меня данные просрутся. А они все не просираются. Может, секрет в том что у меня исправное железо, я мониторю системные логи, не запускаю всякие блобомодули рушашие оперативу, и откровенных системных факапов нет? Ну вот и файлухи пушистые и шелковистые, чего им не?!
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 12:09
	Если хочется повозится с тем, что не в ванильном ядре, то Reiser4 тогда уж.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	103. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Минона (ok), 31-Окт-23, 12:59
	> Если хочется повозится с тем, что не в ванильном ядре, то Reiser4 > тогда уж. Сам возись с этим.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (128), 31-Окт-23, 14:48
	А кто-нибудь пробовал рейзер4? Как оно?
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 15:13
	Я пробовал ещё с 3-ими ядрами. Не хуже ReiserFS. Но, в какое-то время, перестали выпускать патчи под свежие мажорные релизы ядра, откатился на ReiserFS. Потом снова возобновили, но не возвращался.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (159), 31-Окт-23, 17:09
	А по сравнению с мейнстрим файловыми системами?
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от kusb (?), 31-Окт-23, 20:30
	Интересно было бы поставить на NTFS
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	254. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 09:42
	> Интересно было бы поставить на NTFS На нтфс так то пора уже скорее положить, имхо. Дизайн возрастом 35 лет без намека на интересные фичи.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Окт-23, 15:36
	ФС из топика и стоит выбирать когда допилят до уровня использования обычными пользователями. Пользы от неё больше
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

33. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Пряник (?), 31-Окт-23, 09:53
> Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния. Это Redirect-On-Write. А CoW - это когда при записи происходит копирование оригинальных данных в другое место.
Ответить | Правка | Наверх | Cообщить модератору

	40. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (5), 31-Окт-23, 10:11
	"Редирект" здесь при создании копии файла. При модификации блока копируется старый, изменяется, сохраняется.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Минона (ok), 31-Окт-23, 10:12
	>> Copy-on-Write (COW), при котором изменения не приводят к перезаписи данных - новое состояние записывается в новое место, после чего меняется указатель актуального состояния. > Это Redirect-On-Write. А CoW - это когда при записи происходит копирование оригинальных > данных в другое место. Айтишники любят изобретать новые термины.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	140. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 31-Окт-23, 15:55
	Redirect-On-Write это маркетинговый булшит от менеджеров. Нет никакого отдельного RoW, есть только особенности реализации CoW
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	170. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Пряник (?), 31-Окт-23, 18:35
	Название Copy-on-Write сбивает с толку. Никакого Copy не происходит, данные просто пишутся в другое место!
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:10
	> Название Copy-on-Write сбивает с толку. Никакого Copy не происходит, данные просто пишутся > в другое место! Это как посмотреть. Есть группа блоков с 2 референсами на них. Это 2 разные файла. У одного меняется хвост. Его дописывают в другое место и view файла строится при помощи метаданных так чтобы хвост брался воооооон оттуда. По смыслу это чем-то уже немного напоминает копирование. Ведь теперь у хвостов 2 копии. Просто очень оптимизированное, отложенное во времени и довольно круто завернутое. А "redirect" может означать что угодно вплоть до перенаправления в /dev/null.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Пряник (?), 01-Ноя-23, 11:09
	Copy-on-Write - это когда идёт перезапись оригинальных блоков. А оригинальные копируются в другое место. Именно так работают снимки в LVM.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 10:50
	> Copy-on-Write - это когда идёт перезапись оригинальных блоков. А оригинальные копируются > в другое место. Именно так работают снимки в LVM. В конечном итоге - по итогам операции у нас 2 как-бы копии файла, при том как минимум часть таки в результате отличается и являет собой "измененную копию". Да, это очнеь неточное описание действа. И не отражает оптимизации когда копируется только дельта, и в виде когда чтение обычно как раз и не требуется. ...но есть много вариантов как это делать, каждому с его особенностями и оптимизациями названия придумать задолбаться можно, а антиподом этому семейству технологий на самом деле является "in place" перезапись (nocow в терминах btrfs). Это когда изменения сразу валятся в энный регион файла, а старая версия при этом существовать перестает, соответственно, и отменить это действо нельзя просто и дешево уже. В таком виде копий нет совсем. А то что в LVM это вообще кусок позора жутчайший. Нафига оно такое надо черт бы его знает.
	Ответить | Правка | Наверх | Cообщить модератору

	522. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Пряник (?), 21-Ноя-23, 13:51
	Есть над чем подумать. При перезаписи блока он ведь не целиком меняется. Поэтому он копируется и меняется частично. Например, мы поменяли в текстовом файле одну букву, а не всю строку.
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

42. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
Сообщение от Аноним (42), 31-Окт-23, 10:13
Лучшя ФС! Срочно всем мигрировать на неё!
Ответить | Правка | Наверх | Cообщить модератору

	85. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 12:15
	Сначала посмотрим, как её сервисные утилиты справляются с проблемами. Что, таковых ещё нет?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:06
	проблем-то? Да не то чтобы нет, но выпаймити, издержки роста, и вообще подождите, еще пишутъ же ж!
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:11
	> Сначала посмотрим, как её сервисные утилиты справляются с проблемами. Что, таковых ещё нет? Как можно получить проблемы если -rc1 еще не вышел? Вы собираетесь pre-RC ядро сбилдить? Это как-то слишком уж хардкорно.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

47. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–3 +/–
Сообщение от Аноним (47), 31-Окт-23, 10:30
>расширенной функциональности, имеющейся в Btrfs и ZFS, такой как включение в раздел нескольких устройств, многослойные раскладки накопителей, репликация (RAID 1/10), кэширование, прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), срезы состояния (снапшоты), верификация целостности по контрольным суммам, возможность хранения кодов коррекции ошибок Рида—Соломона (RAID 5/6), хранение информации в зашифрованном виде (используются ChaCha20 и Poly1305) NIH-синдром какой-то. lvm2, luks2, ecryptfs, https://github.com/FS-make-simple/fusecompress , https://github.com/opencoff/rsbep ,
Ответить | Правка | Наверх | Cообщить модератору

	144. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (-), 31-Окт-23, 15:59
	> NIH-синдром какой-то. lvm2, luks2, ecryptfs, Да вот желающих пользоваться этим миндфаком после того как btrfs попробовали уже что-то не очень много. Все же ряд вещей сильно лучше получается если в ФС интегрировано.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–2 +/–
	Сообщение от Аноним (173), 31-Окт-23, 18:56
	Чем лучше-то? Тем что гвоздями прибито к ненужному говну?
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:28
	> Чем лучше-то? Тем что гвоздями прибито к ненужному говну? 1) Тем что это лучше в целом работает. Простите но файлухе виднее что кому принадлежит и поэтому какойнить снапшот на ее уровне - сильно эффективнее чем позорная блевотина в LVM на тему. 2) С управлением девайсами и местом это еще эпичнее. Файлуха может видя кому что принадлежит целенаправленно расчистить "этот девайс", урезать размер ФС и отдать девайс. Вон та блевотина так сделать поднапряжется. Знание аллокации это прерогатива ФС, поэтому в блочных терминах "расчистить девайс" не описывается. Это ФС надо информировать, хоть как. Если кто скажет что так не надо, я скажу что мне не надо менеджмент, когда девайс вынуть низя по простому. 3) Если посыпался mirror, файлуха с чексумами знает какой правильный и может self heal из исправного. Попробуйте этот номер вообще своими lvm организовать. При этом файлуха как раз явно в курсе на каком девайсе трабл а на каком ЗБС и это позволяет осмысленно парировать факап. Это уповает на явное знание аллокации и/или девайсов VS что это такое VS чексум этого. А вон там это вообще как в нормальном виде делать? 4) В случае btrfs большая часть операций реконфигурации оформляется в терминах CoW и потому достаточно безопасны и нет никаких проблем КОРРЕКТНО возобновить действо с точки сбоя. Как вы это хотите в лвмной блевотине делать я не знаю. А слушать про белое не одевать, обтягивающее не носить нам надоело. И мы таки накормим тех кто вздумает такое лечить тампаксами.
	Ответить | Правка | Наверх | Cообщить модератору

50. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
Сообщение от Аноним (50), 31-Окт-23, 10:33
> почти три года потребовалось на устранение замечаний и недоработок Сколько раз пришлось переименовывать color в colour и наборот?
Ответить | Правка | Наверх | Cообщить модератору

	82. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 12:11
	Не больше, чем master в main.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:08
	да погоди, еще ж даже и не начинали по настоящему! linux-next это еще далеко не 6.7
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	216. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:31
	> да погоди, еще ж даже и не начинали по настоящему! linux-next это > еще далеко не 6.7 Попробуй перечитать топик, Карл... таки это уже не -next а натурально 6.7 :)
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 18:16
	нету никакого 6.7 "ожидается" Сколько ни перечитывая крипопереведенную тобой чушь.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 11:59
	> нету никакого 6.7 "ожидается" > Сколько ни перечитывая крипопереведенную тобой чушь. 1) Я пообещал 1 местному моду ака шигорину что НЕ буду новости фигачить, раз моды считают допустимым поливать меня калом за мои взгляды и попустительствовать этому. И таки держу слово. Как максимум присылая ссылки, но пахал, извини, Чирков. Так что претензия на неправильную голову, чисто технически. Если бы анон переводил - было бы указано Автор: Аноним. А так только "наводку прислал". Кредитсы на опеннете честные. А так и цель достигнута и обещание не нарушил. Забавно, да? :) 2) Я лично обнаружил ЭТО в git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git когда pull делал. И прислал Чиркову ссыль прямо на комит. Еще вопросы есть? Это если что репа майнлайна. Что в нее прилетело - "будет в 6.7", как максимум "revert", но это экзотика и "маловероятно", особенно - для экспериментальной фичи. Я не шутил сказав что плотно трекаю майнлайн, так то планировал 6.6 релизный утащить, у kernel.org какие-то технические проблемы возникли, try again later оказалось с бонусом внагрузку! Окно приема патчей на 6.7 открылось, я и охренел, прислал ссыль на комит Чиркову, еще до того как Фороникс раздуплился. Ну вот совпали тайминги, из-под пера Торвальдса фичу утащил буквально. ...как-то так можно и оценить чьи знания в линухе up to date а кто погулять вышел ;)
	Ответить | Правка | Наверх | Cообщить модератору

56. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (56), 31-Окт-23, 10:43
>патч включает около 95 тысяч строк кода Чот многовато. Явно много ненужного содержит.
Ответить | Правка | Наверх | Cообщить модератору

	59. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Массоны Рептилоиды (?), 31-Окт-23, 10:59
	Так удали лишнее, в чём проблема?
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 15:28
	Да чё там, оставить printk("Hello, World!\n");
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от амерский ведроид (?), 31-Окт-23, 11:01
	Как всегда амуде тонну всякого запихали небось.Вчера альтовский кернел распаковал - 1.3 гига уже. Пару мб на выходе,но учитывая,что в два раза больше строк вносится чем выкидывается, причем  стахановскими темпами,то как-то неприятно немного.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	84. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (80), 31-Окт-23, 12:13
	Название темы новости внимательно перечитай. Подумай, каким боком к ней AMD.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от амерский ведроид (?), 31-Окт-23, 12:17
	Они всегда пихают,даже для того чего еще нет и этим очень гордятся. Новость да,новость про файлуху которой начнут пользоваться лет через десять.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 31-Окт-23, 17:29
	не, так мы этого слона не продадим. Либо через год таки начнут (кто не начнет - по пятницам двойную порцию кнута) либо слохнет.
	Ответить | Правка | Наверх | Cообщить модератору

115. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (115), 31-Окт-23, 13:45
Вот это я понимаю ревью 10 лет длилось. На работе пару дней не посмотришь уже бегут...
Ответить | Правка | Наверх | Cообщить модератору

119. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
Сообщение от Аноним (-), 31-Окт-23, 14:01
>Попытки продвижения Bcachefs в основной состав ядра начались в 2020 году, после чего ещё почти три года потребовалось на устранение замечаний и недоработок, выявленных после рецензирования. Весной этого года был предложен обновлённый набор патчей, который несколько раз отклонялся, но в, конечном счёте, в сентябре был принят в ветку linux-next Шишкин, бери пример! Вот так надо пахать!
Ответить | Правка | Наверх | Cообщить модератору

	124. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (124), 31-Окт-23, 14:40
	Да, кстати, как в воду глядел: > "... Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято." https://habr.com/ru/articles/559014/
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (80), 31-Окт-23, 15:24
	Он архитектор, кодят помощники.
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	146. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 31-Окт-23, 16:03
	> Он архитектор, кодят помощники. Что-то не больно дофига реально работающих экспонатов наархитектил этот филин-стратег. Единственный реально живой рейзер это 3 версии. И тот норовит тома в капусту порубать fsck'ом. Четвертый никогда не достигал адекватного качества, чтобы в майнлайн попасть речь вообще не шла, а пятый вообще vaporware по сути.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:04
	так плохая дорога тебе не расскажет что он там наархитектил. Но, подозреваю, нифига не на $2300 да и те сегодня набрались, а завтра донат пошел на нищасных дитишек палистинцив. А это у него - такое хобби, хоть и связанное с профессиональной деятельностью, но в свободное время и по желанию, а не прикованное к ноге ведро. Он же не е6анько какое, взрослый уже человек, понимающий что "плавать с викингами хорошо смолоду".
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (176), 31-Окт-23, 19:07
	Он пишет бесполезные вещи, хоть и взрослый человек... вот Кент да, толкает крутую ФС, а Шишкину пора на свалку истории.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (4), 31-Окт-23, 20:28
	Всю жизнь мечтал 10 лет впахивать за донаты, чтобы потом мой код приняли в Linux, и корпорации наконец-то смогли им воспользоваться бесплатно. Вот такой я куколд. Обзавидуйтесь.
	Ответить | Правка | Наверх | Cообщить модератору

	315. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 01-Ноя-23, 22:58
	Не, ну ты губы-то не раскатывай. Принимают далеко не каждый кот. Как насчет 10 лет впахивать нахаляву вот вообще (тогда - еще было можно), двести раз переделывать потому что все бандерлоги того требуют (и нет, не комментарии менять, а перепахивать код) а потом все равно пойти найух? А вот с автором devfs именно это и произошло. Причем код работал, и мы им лет пять успешно пользовались. Просто его рыло не понравилось б-жку с пальцовкой и его прихлебателям. Вот этому - обзавидуйся!
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (4), 02-Ноя-23, 08:14
	А если бы приняли, то все равно поддерживать пришлось бы ему практически в одиночку. И смысл подлизывать всяким Пинусам? Так что Шишкин, может и правильно поступил, что не стал.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 08:39
	> А если бы приняли, то все равно поддерживать пришлось бы ему практически > в одиночку. Угу - мы тебе тут все поломали своим более лучшим (лучшим не для тебя, конечно, а по заказу нашего любимого платинового спонсора) - бегом чинить, а то мы тебя выкинем и кота твоего следом! > И смысл подлизывать всяким Пинусам? Так что Шишкин, может > и правильно поступил, что не стал. абсолютно. Над ним совершенно не каплет. Будете жрать хуавеевские полки и благодарить с поклоном в пол. А хобби останется хобби, не вызывающим омерзения из-за необходимости сотрудничать с больными фанатиками и грантопилами.
	Ответить | Правка | Наверх | Cообщить модератору

	352. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от maximnik0 (?), 02-Ноя-23, 12:13
	>А вот с автором devfs именно это и произошло. Была ошибка в дизайне - если у сетевой карточки нет индивидуального номера устройства видного через  pci биус ,а таких сетевых карточек несколько - не удивляйтесь странным сетевым интерфейсам, и то что устройства могут тупо не видиться.В дистрибутиве Alt очень долго это чинили скриптами eth vlan и вздохнули когда вышел udev .Правда там тоже кое что ломали,в основном поменялись идентификаторы устройств,но хоть какая то логика работы появилась.
	Ответить | Правка | К родителю #315 | Наверх | Cообщить модератору

	218. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:37
	> так плохая дорога тебе не расскажет что он там наархитектил. Но, подозреваю, > нифига не на $2300 да и те сегодня набрались, а завтра > донат пошел на нищасных дитишек палистинцив. Ну как бы для меня всего этого не существует - и мне пофиг что он там (не) наархитектил соответственно. Я это никогда не увижу, вероятно, в отличие от сабжа. Которому тестовые забеги по моей линии будут сделаны как только -rc1 маркируют имхо. > А это у него - такое хобби, хоть и связанное с профессиональной > деятельностью, но в свободное время и по желанию, а не прикованное > к ноге ведро. Я рад за его хобби или что там еще, а мне какое дело до всего этого, если оно не транслируется в измеримые для меня бенефиты? Это в таком виде лишнее, ненужное знание и бесполезный код. И я совершенно не обязан положительно отзываться о таком страдании фигней или чем-то поддерживать таких людей. > Он же не е6анько какое, взрослый уже человек, понимающий что "плавать с > викингами хорошо смолоду". Ну если ему китайская галера милее - это его выбор, но лично я подальше от этого всего буду держаться. И от продукции галеры (ибо видел я что они с ФСами делают и какие там баги, лишь немногим лучше самсуня) и от самой галеры, это довольно жесткий рабовладелец коему есть из чего выбирать - там целый миллиард за воротами. И это таки постепенно станет траблами гребцов, когда их постепенно будут просто скидывать в море, с аргументом что акулы GC выполнят естественным спосбом, зачем париться больше, дескать.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	191. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Ю.Т. (?), 31-Окт-23, 21:49
	Прочел его интервью, на которое здесь давали ссылку. Думаю, я его понял. Он, по видимости, семи пядей, у него приличная работа в большой корпорации, и он не сделает рабочей ФС в составе ядра примерно никогда. Чтобы это провернуть, нужно биться и суетиться, как этот Кент - а Шишкин так не станет. Ну, и ему мешает, что он математик (!) отечественной школы. То есть без ста теорем и без полиморфизма ему и изделие программное не в сласть.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	229. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 05:52
	Дело не в том, сделает или не сделает "рабочий ФС". В самом начале, он хитро так представил себя наследником Рэйзера и продолжателем его дела. И все ему поверили. Изначально надо было сообществу чётко сказать: "Ребята работать с файловой системой не буду, у меня к нему лишь академический интерес".
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Ю.Т. (?), 01-Ноя-23, 07:30
	Но дело именно "в том". Получится или не получится научно построенное изделие типа "файловая система". Впрочем, в самом начале он мог и не знать, так сказать, себя, или не представлять объема вненаучных проблем, связанных с такой затеей.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:10
	> - а Шишкин так не станет. Ну, и ему мешает, что > он математик (!) отечественной школы. То есть без ста теорем и > без полиморфизма ему и изделие программное не в сласть. Он к тому же будет иметь весьма синтетические взгляды на проблематику, без учета эксплуатационных пожеланий и проблем. А на практике девайсы и ФС фэйлят не так как это теоретики себе представляли. И что там будет с красивым на бумаге дизайном хоть сто раз доказанным теоремами - большой вопрос. С высокой вероятностью ничего хорошего. А теоретически-заурядный дизайн сделанный с учетом практических данных запросто даст мастеркласс на тему self heal или чего там еще. К тому же в реальном коде бывают совершенно дурацкие баги вида "на 20-м терабайте все же случается какая-то фигня". Шишкин файло на 20 терабайт создать не сможет - и об этом узнает тот кто это поюзает на таком файле. Ведь желающих тестировать его штуку было целые полтора землекопа.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	296. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Ю.Т. (?), 01-Ноя-23, 17:48
	Нет, это уже начинаются чудеса. "Чем больше проектирования, тем хуже". У человека солидная подготовка в вопросе, другое дело, что он, возможно, не обладает качествами ни "директора", ни "билла". Между прочим, кентовскую систему серьёзно испытывать тоже будет примерно некому.
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 13:40
	> Нет, это уже начинаются чудеса. "Чем больше проектирования, тем хуже". У этого явления даже название есть - overengineering. Это когда вы слишком вдарились в это самое, ушли в какие-то дебри, и столкнувшись с дохреналионом проблем породили совершенно неодупляемого МОНСТРА в попытке выкатить гранд-универсальное решение всех мыслимых проблем человечества в 1 программе. Получается урод которого малореально майнтайнить, сложно менять под всплывшие новые данные, и вообще, это как кит - норовит быть раздавлен своим весом. Кодить и майнтайнить ЭТО никто не хочет а багов - легион. В этом случае наступает печальный момент когда вы понимаете: переделать с ноля проще чем тянуть эту гирю дальше, за отсутствием перспектив. А все усилия соответственно вообще угроханы зафиг. Так фейлят большие проекты. Добро пожаловать в реальный мир. > У человека солидная подготовка в вопросе, другое дело, что он, возможно, не обладает > качествами ни "директора", ни "билла". Архитектура и менеджмент проектов - довольно плотно пересекающиеся вещи. > Между прочим, кентовскую систему серьёзно испытывать тоже будет примерно некому. We'll see about that...
	Ответить | Правка | Наверх | Cообщить модератору

	434. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Ю.Т. (?), 03-Ноя-23, 17:27
	Потому что [правильный] ответ -- [оптимальное] количество проектирования. Ставится задача, проводится разаработка. Цель в модели достигнута - начинается стройка. Не для того ли сочиняли промышленные ГОСТы и прочие ИСы?
	Ответить | Правка | Наверх | Cообщить модератору

	462. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 04-Ноя-23, 17:27
	> Потому что [правильный] ответ -- [оптимальное] количество проектирования. Судя по таймингам Reiser4/5 с этим не задалось. К тому же реалии не стоят на месте, и если тупить с фазой проектирования, она может не закончиться никогда, потому что будут новые данные, кейсы, типа сторажей и проч. В софтварных проектах главное - вовремя угомониться, согласившись на какой-то компромисс, и таки выкатить релиз. Иначе за идеалом можно гнаться вечно. А релиз не состоится никогда, потому что люди столько не живут. > Ставится задача, проводится разаработка. Цель в модели достигнута - начинается стройка. Ну как бы да, делать дизайн совсем без формулировки проблемы - это глупо. Но так если кто и делал то на заре файлух, в эпоху FAT12 какого. Более сложные дизайны - когда все уже на мази, скажем структуры переделывать очень мучительно. И агрит тех кто в это уже вляпался. > Не для того ли сочиняли промышленные ГОСТы и прочие ИСы? Их сочиняли в основном для interop. Так что я могу притащить Gerber на любую фабу и уповать что они печатку по ним сделают более-менее одинаково, так что можно пойти на ту фабу, или эту. А если б каждая фаба требовала свой формат - это был бы задник. Как с ними взаимодействовать тогда? Однако не все области столь же хороши, скажем 2D контуры и 3D модели уже более проблемный топик. А каким ISO или гостам соответствуют файлы автокада? Многие однако хотят вот их. Бывает так что стандарт, увы, "де факто".
	Ответить | Правка | Наверх | Cообщить модератору

122. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (122), 31-Окт-23, 14:13
Когда доделает, HDD уже и не будет в помине
Ответить | Правка | Наверх | Cообщить модератору

	133. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (80), 31-Окт-23, 15:15
	Ага, Иксов не будет, GCC не нужен, ...
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Hippopotamus (ok), 31-Окт-23, 17:44
	У меня на арче нет иксов. GCC есть
	Ответить | Правка | Наверх | Cообщить модератору

	270. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от kusb (?), 01-Ноя-23, 13:36
	Ядрёная консоль, я надеюсь
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Анонин (?), 31-Окт-23, 20:09
	Ядро уже давно компилится шлангом и даже возможно работает на большем кол-ве девайсов чем линукс - все ядра для андроидов собраны шлангом. Иксы тоже уже не нужны, вяленый и икс-вяленый прекрасно заменяют для 99.9% пользователей. Но вот на счет хдд не был бы так уверен))
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	271. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от DEF (?), 01-Ноя-23, 14:07
	У меня SSD, Wayland, LLVM. модно, стильно, молодежно.
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	143. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (145), 31-Окт-23, 15:59
	Будет, возможно даже больше чем сейчас. Мало кому захочется включить компьютер через год простоя и не обнаружить там своих файлов.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	153. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 31-Окт-23, 17:01
	Как будто с современным hdd это не так же.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 31-Окт-23, 17:41
	Тут на Тубе было видел где чел тестировал сохранность файлов на SSD. Целый год 4 диска пролежали в ящике стола, не включались. Спустя год 2 штуки включил, проверил - все файлы на месте. Еще через год другие 2 проверит.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	166. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 31-Окт-23, 17:53
	да там хрен с файлами - таблицы маппинга живы или не совсем. У малтилейер ssd - через год уже не то что файлы, а вообще не прочитается ничего. С другой стороны - ну а нахрена во-первых, выключать, а во-вторых какие-то там файлы, тебя чо, из морозилки забыли вовремя достать? У нас тут облачка, белогривые лошарики, дома хранить ничего не принято, а то дом-то нынче шибко умный, на твой прон как начнет др-4ить, так стены трясутся и ты со стула падаешь.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от turbo2001 (ok), 31-Окт-23, 21:36
	> У малтилейер ssd - через год уже не то что файлы, а вообще не прочитается ничего. Похоже на байку. Полностью забитый samsung 970 pro пролежал 15 месяцев в коробке, все данные на месте.
	Ответить | Правка | Наверх | Cообщить модератору

	451. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от RM (ok), 04-Ноя-23, 10:22
	> Полностью забитый samsung 970 pro пролежал 15 месяцев в > коробке, все данные на месте. так это же Samsung 970 Pro, прследний нормальный из потребительского сегмента, на MLC  и с соответстаующим ценником. Типа топ, не показатель средней температуры по больнице. Я, как 980 Pro  увидел, побежал купил пару 970 Pro в стол. Потому что АртефактЪ оно теперь.
	Ответить | Правка | Наверх | Cообщить модератору

	459. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от turbo2001 (ok), 04-Ноя-23, 17:01
	Да, был неправ. Почему-то думал, что 970 - это TLC, как 980 и 990.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 01-Ноя-23, 05:22
	> да там хрен с файлами - таблицы маппинга живы или не совсем. > У малтилейер ssd - через год уже не то что файлы, а > вообще не прочитается ничего. > С другой стороны - ну а нахрена во-первых, выключать, а во-вторых какие-то > там файлы, тебя чо, из морозилки забыли вовремя достать? У нас > тут облачка, белогривые лошарики, дома хранить ничего не принято, а то > дом-то нынче шибко умный, на твой прон как начнет др-4ить, так > стены трясутся и ты со стула падаешь. Вы по диагонали читаете О_о? Чел создал рандомные файлы, записал их, создал хэши, на год убрал в коробку, через год проверил - у всех файлов хэши совпали.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	291. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 17:21
	человеку просто повезло с дисками. Один раз. Причем никто не обещает что через еще год данные снова прочитаются. (судя по каким-то там хэшам - человек феноменально безграмотный и даже не понимает как это работает) Более того - из-за поворота индустрии (дерьма) в сторону безумных плотностей и наращивания числа уровней - можно уверенно _обещать_ что современные диски _вообще_ не прочитаются и не будут подлежать восстановлению в принципе - не какие-то там "хэши", а просто - трупик. но вы продолжайте веровать что обманули физику.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 01-Ноя-23, 17:31
	> Более того - из-за поворота индустрии (дерьма) в сторону безумных плотностей и > наращивания числа уровней Вот с ЭТИМ я соглашусь. То как народ уверенно переходит с условного TLC на QLC и бездумно пишет в пятизвездочных обзорах "да все норм, че. Быро же файло записалось" не задумываясь как там все работает и насколько нынешние диски "мухлюют" чтобы создать видимость скорости - оторопь берет. А производители все грозят вводом PLC (правда тут есть подозрение что не будет его все таки, возни много, контроллеры нужно еще мощнее делать, а выигрыш небольшой) и тогда будет полная жесть, еще чуть и появятся WORM SSD :)
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от пох. (?), 01-Ноя-23, 18:33
	> Вот с ЭТИМ я соглашусь. То как народ уверенно переходит с условного > TLC на QLC и бездумно пишет в пятизвездочных обзорах "да все А кто его спрашивать-то собирается вообще? Все, не выпускают мелких и надежных ssd, давай дасвиданье. Мелких и надежных hdd УЖЕ нет. В принципе нет их. (ну может какие 2.5" фуджитсы еще выпускаются, но их с улицы не купишь) > а выигрыш небольшой) и тогда будет полная жесть, еще чуть и > появятся WORM SSD :) боюсь что они таки WMRO. Записать-то получится, а вот прочитать только первый раз и то если сразу. Ну а чотакова, у вас ценные данные а не загрузочная флэшка что-ли? Во даете, чего ж они не в облачках-то, для большей надежности одновременно гуглевом, амазонском и мэйлрушечном - чтобы все были в курсе вашей личной жизни.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 01-Ноя-23, 20:30
	> А кто его спрашивать-то собирается вообще? Все, не выпускают мелких и надежных > ssd, давай дасвиданье. > Мелких и надежных hdd УЖЕ нет. В принципе нет их. (ну может > какие 2.5" фуджитсы еще выпускаются, но их с улицы не купишь) Ну тут же "рыночек" порешал. Если SSD на QLC стоит в полтора раза дешевле TLC, то народ берет. Постепенно производители говорят "так не покупает никто TLC" и либо переводят его в премиум сегмент либо вообще свернут производство. Переход уже идет, разве что на QLC народ все таки не так быстро пересаживался раньше потому что первые образцы были ну очень унылые, но тепреь их хорошо замаскировали, припудрили, а порой вообще не говорят про начинку (Кингстон этим отличается например). И никто не замечает, что по мере заполнения диска он что-то начинает тормозить, а потом тормозить ОЧЕНЬ сильно. С HDD тут вы про SMR? Ну есть надежда что SMR это временное решение, просто у WD с HAMR не получилось, а у Сигейт - получилось, в связи с чем Сигейты уже презрительно назвали SMR диски "Archive drives".
	Ответить | Правка | Наверх | Cообщить модератору

	314. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 22:36
	> С HDD тут вы про SMR? Ну есть надежда что SMR это временное решение а постоянное - когда мелких дисков ВООБЩЕ не останется - никаких. Найди мне что-то меньшее 6 терабайт не smr ?
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (321), 02-Ноя-23, 01:15
	SkyHawk от сигейтов и их предшественники по категории - всё_для_видео?
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 02:11
	>> С HDD тут вы про SMR? Ну есть надежда что SMR это временное решение > а постоянное - когда мелких дисков ВООБЩЕ не останется - никаких. > Найди мне что-то меньшее 6 терабайт не smr ? Ну WD40PURZ например, там CMR\PMR, с WD40PURХ правда непонятно, в спеках есть TRIM, но утверждают что это не SMR
	Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

	345. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 07:47
	а, ну да, еще вот диски под видеонаблюдение. С нулевой надежностью и долговечностью и то ли урезанные по интерфейсу, то ли на самом деле 5400. И скоро их таких тоже не останется. Как я тебе видимона6лядение в 8k буду на такого недомерка писать? Подавайте мне 40T!
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 15:12
	> И скоро их таких тоже не останется. Опять мимо, среди обычных WD Blue есть CMR-диски на каждую ёмкость: https://documents.westerndigital.com/content/dam/doc-library... Purple отличаются наклейкой и прошивкой с добавлением экзотических команд, от этого надежность и долговечность в ноль не падают.
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 15:24
	_были_. Сейчас ты их в продаже - не найдешь. (не надо мне показывать твое (не)умение искать по амазону) нет, не наклейкой.
	Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

	377. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 16:20
	Лол, не были, а будут. Это самые новые диски, которые до нас ещё не доехали. >> нет, не наклейкой. > наклейкой и прошивкой
	Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

	379. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 17:22
	> _были_. Сейчас ты их в продаже - не найдешь. > (не надо мне показывать твое (не)умение искать по амазону) > нет, не наклейкой. Ну да, там есть поддержка "стриминговой" записи с игнорированием потенциальных ошибок для достижения устойчивой скорости записи + там NCQ работает иначе чтобы можно было писать несколько потоков одновременно. Но прикол в том, что все это включается только если контроллер явно включает через расширения ATA протокола. На том же Реддите обсасывали - на десктопах диск должен работать как обычный. Вероятно :)
	Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

	382. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 17:55
	> Вероятно fuuu...ck не, в принцие они даже и работают, с некоторыми э... особенностями, правда, я не видел самых последних, по известным причинам, но есть у меня подозрение что там все только хуже. У purz/rx из занятного было то что они во-первых гелиевые (т.е. это опять переделанная тошиба), во-вторых 4k only без эмуляции кроме какой-то одной мелкой модели. Ну а из не очень занятного - что они тоже э... wmro. Т.е. при попытке использовать в сервере очень быстро дохли от неведомых причин.
	Ответить | Правка | К родителю #379 | Наверх | Cообщить модератору

	391. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 19:46
	>> Вероятно > fuuu...ck > не, в принцие они даже и работают, с некоторыми э... особенностями, правда, > я не видел самых последних, по известным причинам, но есть у > меня подозрение что там все только хуже. У purz/rx из занятного > было то что они во-первых гелиевые (т.е. это опять переделанная тошиба), > во-вторых 4k only без эмуляции кроме какой-то одной мелкой модели. Ну а смысл сейчас эмулировать 512 байт? Так и так все винты уже давно 4К, логично что наконец-то решились на 4Kn > Ну а из не очень занятного - что они тоже э... wmro. > Т.е. при попытке использовать в сервере очень быстро дохли от неведомых > причин. А вот это не очень радует, реально. И какие симптомы?
	Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

	395. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 22:51
	> Ну а смысл сейчас эмулировать 512 байт? а ты загрузиться-то уверен что сумеешь? видеорекордеру-то понятно незачем. > А вот это не очень радует, реально. И какие симптомы? насколько я помню (2019й год же ж) - не детектится или вообще не стартует (поди разбери у этих альтернативно одаренных, что там на самом деле) Без всякого объявления войны (ну или опять же без видимого альтеративно одаренными - то есть может он щелкал и ресетился, главное чтоб smart был чистеньким)
	Ответить | Правка | К родителю #391 | Наверх | Cообщить модератору

	429. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 03-Ноя-23, 16:43
	>> А вот это не очень радует, реально. И какие симптомы? > насколько я помню (2019й год же ж) - не детектится или вообще > не стартует (поди разбери у этих альтернативно одаренных, что там на > самом деле) > Без всякого объявления войны (ну или опять же без видимого альтеративно одаренными > - то есть может он щелкал и ресетился, главное чтоб smart > был чистеньким) Ну вот я смотрю отзывы по тому же Яндекс.Маркету, у многих либо DOA приезжает либо дохнет после нескольких включений сразу. Неясно, тут могли и при доставке уронить, конечно, но у многих реально долго не живет. Еще интересно читать про "большой ресурс" и "меняем примерно через год", правда это 24/7. В общем неясно, видеть бы статистику по отказам.
	Ответить | Правка | К родителю #395 | Наверх | Cообщить модератору

	431. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 03-Ноя-23, 16:49
	блин ну ты нашел где смотреть. Их может растамаживали без подъемного крана, или перегружали вилами. У меня инфа от обитателей нормальных стран. Где, правда, амазон любит бросить диски в антистатическом пакетике в коробку метр на метр и метнуть ее через двухметровый забор потому что рабу некогда возиться со звонком, но такое там никто и не будет использовать, запихивают обратно плашмя (или уже потом не удивляются во всяком случае). И в менять через год самом по себе нет ничего страшного, но есть разница между начал давать ошибки и плавно помер, и просто перестал видеться системой в принципе. Вот когда про диски начинают рассказывать второе - я ищу другую модельку без особых разбирательств, что и почему там происходит. Ну нахрен.
	Ответить | Правка | К родителю #429 | Наверх | Cообщить модератору

	467. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 04-Ноя-23, 19:29
	> блин ну ты нашел где смотреть. Их может растамаживали без подъемного крана, > или перегружали вилами. Эти хотя бы не трут негативные отзывы, а если смотреть по всяким известным инторнет магазам комплектухи - все отзывы прекрасные и ни одного негативного, так не бывает. А то что они там возят абы как - это да, про это там все тоже пишут. Да еще народ на пунктах выдачи не парится. И кстати специально заморочился проверить, пишут что на гелии Purple только от 8 (или 10) терабайт.
	Ответить | Правка | К родителю #431 | Наверх | Cообщить модератору

	378. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 17:18
	>> И скоро их таких тоже не останется. > Опять мимо, среди обычных WD Blue есть CMR-диски на каждую ёмкость: https://documents.westerndigital.com/content/dam/doc-library... > Purple отличаются наклейкой и прошивкой с добавлением экзотических команд, от этого надежность > и долговечность в ноль не падают. Причем команды там действительно интересные - разрешают игнорировать ошибки записи если это было явно запрошено хостом. Дескать все равно видеопоток, пара битых кадров не меняет ничего. Обычный десктопный SATA контроллер этого вообще не умеет.
	Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

	413. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 13:55
	> Причем команды там действительно интересные - разрешают игнорировать ошибки записи если > это было явно запрошено хостом. Дескать все равно видеопоток, пара битых > кадров не меняет ничего. Обычный десктопный SATA контроллер этого вообще не умеет. Обычному десктопному контроллеру - похрен! Что кернел или кто там скажет слать, то он и пошлет. Фичесет девайса и валидность этого действа ему довольно до балды. Более того - у многих эмбедед железок такой же AHCI интерфейс к их контроллеру (даже если оно и не через PCI шину). Если на той стороне линка обиделись на команду, девайс отлуп вернет. А так "обычный десктопный контроллер" запросто отсылает даже всякие "сервисные" команды, если вы знаете какие и с какими параметрами. Но кернел довольно специфично себя ведет если накопитель делает что-то неожиданное. Скажем WD выпавший в Failsafe не хочет выполнять многосекторное чтение через read dma multiple, соглашаясь только на простой read по 1 сектору. А кернель не в курсе таких вещей и на это очень обижается, пытаясь ресетить девайс и что там еще. Что ессно никогда не дает ожидаемый эффект. Но вот контроллеру SATA это все до балды, он довольно простая железка. Горе от ума бывает больше у всяких трансляторов типа USB<->SATA и тому подобного добреца с фирмварой и трансляцией команд, там уже оно может и не пускать всякий кастом через себя.
	Ответить | Правка | К родителю #378 | Наверх | Cообщить модератору

	432. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 03-Ноя-23, 16:59
	>[оверквотинг удален] > Но кернел довольно специфично себя ведет если накопитель делает что-то неожиданное. Скажем > WD выпавший в Failsafe не хочет выполнять многосекторное чтение через read > dma multiple, соглашаясь только на простой read по 1 сектору. А > кернель не в курсе таких вещей и на это очень обижается, > пытаясь ресетить девайс и что там еще. Что ессно никогда не > дает ожидаемый эффект. Но вот контроллеру SATA это все до балды, > он довольно простая железка. Горе от ума бывает больше у всяких > трансляторов типа USB<->SATA и тому подобного добреца с фирмварой и трансляцией > команд, там уже оно может и не пускать всякий кастом через > себя. Ну как бы все таки это все должно быть host aware: Вот что Сигейт писали еще годы тому назад про свои диски для видеонаблюдения. "Perhaps surprisingly, complete data integrity for video is not vitally important. That's because a small error introduced into a video stream doesn't compromise the overall integrity of the visual image. While a small, perhaps imperceptible, flaw may occur, the overall video is still intact. However, in order to manage the vast amounts of video and related metadata in a surveillance system, a keyed relational database or similar traditional data organizational system is often used. It is absolutely critical that reads and writes for such systems employ the utmost levels of error correction and detection to ensure data integrity isn't compromised. An important feature of the SV35 Series disc drive is its support of the ATA-7 streaming command set. ATA-7 is a recent extension of the industry-standard ATA command set for controlling disc drives. The streaming component of this standard enables the SV35 Series drive's reads and writes to be customized for either video or data payloads. Using the ATA-7 streaming commands, both of these requirements are elegantly met." Судя по спекам для того чтобы писать на диск в режиме стриминга система должна явно инициировать запись в таком режиме. Теперь вопрос - с чего бы обычному хосту такое делать? Не говоря уже о том что диск так же должен быть готов к записи обычных данных, для которых ошибки - ни-ни.
	Ответить | Правка | К родителю #413 | Наверх | Cообщить модератору

	471. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 05-Ноя-23, 06:09
	> Ну как бы все таки это все должно быть host aware: Судя по описанию, там добавочные команды которые хост может юзать для вот именно видео, если захочет. А не захочет - ну и хрен с ними, по идее. И это реально надо только системам выделенным под съемку видео с камер наблюдения, где непрерывность потока их все, даже если пару кадров и вылетит. Для более обычного софта - если этими фичами пользоваться - вылетит несколько секторов под метаданными ФС - и чего?! Там соответственно соображения другие, лучше пытаться записать данные гораздо настырнее. Даже если займет дольше. > Вот что Сигейт писали еще годы тому назад про свои диски для > видеонаблюдения. В случае видео - лучше продолбать кусок кадра, чем надолго озадачиться retry/reset/recovery и в итоге продолбать пару минут в результате, реалтайм не ждет. КМК основная трабла - обычные файлухи и софт типа кернела не особо хорошо себя ведут налетев на бэды в этом аспекте vs съемка видео. В чем-то похожие траблы есть для RAID - там TLER сделали, с лимитом времени на операции рекавери, иначе диск считают дохлым и он уходит офлайн. А это видимо некая перепевка идеи под видеосистемы. > Using the ATA-7 streaming commands, both of these requirements are elegantly met." Ну это какое-то расширение набора команд. Умеет ли его линух и что там с софтом - ахз, смотреть надо, специфичное знание для видяшников. > Судя по спекам для того чтобы писать на диск в режиме стриминга > система должна явно инициировать запись в таком режиме. Теперь вопрос - > с чего бы обычному хосту такое делать? Обычному - да ни с чего. Но если софт в системе засабмитит эти команды, имхо, писючный контроллер не будет возражать. Ему то какое дело что там за команды и почему. Вот какой-нибудь usb-sata bridge может и обидеться на нежданчик, а AHCI какому, имхо, похрен и есть шансы что в вон тех железках примерно такой же AHCI и стоял - изобретать новый интерфейс контроллера при наличии устаканившегося стандартного желающих довольно мало. А у usb кстати сто лет есть стриминг потоков (isochronous EP), но там это вообще совсем для мультимедии, типа поток байтов в/из звуковуху гнать. Там тоже кстати retry нет - попортится чуток - и хрен с ним! Лучше чем надолго заткнуться в попытках идеального recovery. А вон то это продолжение идеи, чтобы и накопители так же себя вели. > Не говоря уже о том что диск так же должен быть готов к записи обычных > данных, для которых ошибки - ни-ни. Видимо в том режиме - tradeoff другие, чтобы непрерывно писать - и черт с парой ошибок. Но вот чего бы именно контроллеру на расширения команд возбухать - ахз. Скорее на PC операционки не юзают такие команды просто - а им оно зачем? Но думается если послать такие команды - оно, имхо, прокатит. И вопросы к софту и его умениям скорее. А чего, даже всякие vendor cmd прокатывают же.
	Ответить | Правка | К родителю #432 | Наверх | Cообщить модератору

	374. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 16:10
	> Ну есть надежда что SMR это временное решение, просто у WD с HAMR не получилось, а у Сигейт - получилось, в связи с чем Сигейты уже презрительно назвали SMR диски "Archive drives". На самом деле Seagate не меньше отличился. Он сейчас своим даташитом на Barracuda Compute гордо говорит, что дома нужен только SMR - в десктопах, в домашних серверах, в DAS. Передовые достижения, говорит. Особо универсальные диски, говорит. Ещё это минное поле (где есть риск встретить SMR) у него простирается на 2 ТБ выше - 2..8ТБ против 2..6ТБ у WD. Если бы по плотности записи получалось лучше, чем у WD, он бы опережал его по введению новых ёмкостей, но на деле немного отстаёт. Вроде именно из-за роста плотности WD сейчас добавил новые CMR-диски на 2..6ТБ. SMR с нами навсегда, но он не спешит вытеснять CMR и особо плох только в домашнем варианте (DM-SMR), где богатый внутренний мир наружу не выставляется как в HA-SMR и HM-SMR.
	Ответить | Правка | К родителю #308 | Наверх | Cообщить модератору

	380. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 17:40
	> и особо плох только в домашнем варианте (DM-SMR), где богатый внутренний > мир наружу не выставляется как в HA-SMR и HM-SMR. Ну общался с владельцами (сам такое не беру хотя и было интересно пощупать) - по их ощущениям чисто как хранилка файлов "положил и забыл" - более менее. По началу-то, при первой записи, все довольно быстро. А вот когда народ начинает, не дай бог, торренты на него качать, вот тогда быстро начинается полное веселье. Особенно когда он уходит в себя на минуты или трещит безостановочно. Систему ставить тоже не очень вариант. Но как архивный - может быть, если маркировать соответственно. Что до HAMR - то пока только корпоративные заказы, дойдет ли до массмаркета уже вообще не ясно. С другой стороны в отличие от SMR в HAMR вроде как нет этих трюков с зонами и переписыванием данных туда-сюда.
	Ответить | Правка | Наверх | Cообщить модератору

	385. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 18:40
	> С другой стороны в отличие от SMR в HAMR вроде как нет этих трюков с зонами Seagate лукавит, противопоставляя друг другу PMR, SMR и HAMR. Потому что перпендикулярная запись (PMR) никуда не девается, а однозначное отсутствие SMR принято обозначать словом CMR (Conventional...) и когда надо, Seagate этому следует. Логично в будущем совместить HAMR с черепицей и это не просто моя догадка: > "And by the way, HAMR can use SMR as well on top of it", говорит William David Mosley, Chief Executive Officer & Director, Seagate Technology Holdings Plc - https://s24.q4cdn.com/101481333/files/doc_financials/2023/q4... О будущих дисках говорить неприятно, Seagate уже слал первый HAMR-диск избранным клиентам в 2018, сейчас тоже... шлёт первый HAMR-диск... избранным клиентам... у остальных производителей есть похожие фокусы. Короче, это не наше собачье дело, есть в природе этот диск и эти избранные клиенты, или нет их.
	Ответить | Правка | Наверх | Cообщить модератору

	390. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 19:40
	>[оверквотинг удален] >> С другой стороны в отличие от SMR в HAMR вроде как нет этих трюков с зонами > Seagate лукавит, противопоставляя друг другу PMR, SMR и HAMR. Потому что перпендикулярная > запись (PMR) никуда не девается, а однозначное отсутствие SMR принято обозначать > словом CMR (Conventional...) и когда надо, Seagate этому следует. Логично в > будущем совместить HAMR с черепицей и это не просто моя догадка: >> "And by the way, HAMR can use SMR as well on top of it", говорит William David Mosley, Chief Executive Officer & Director, Seagate Technology Holdings Plc - https://s24.q4cdn.com/101481333/files/doc_financials/2023/q4... > О будущих дисках говорить неприятно, Seagate уже слал первый HAMR-диск избранным клиентам > в 2018, сейчас тоже... шлёт первый HAMR-диск... избранным клиентам... у остальных > производителей есть похожие фокусы. Короче, это не наше собачье дело, есть > в природе этот диск и эти избранные клиенты, или нет их. Но зачем поверх HAMR вешать SMR? Смысл и того и другого был в преодолении текущих лимитов на плотность, причем сами Сигейты называли SMR "stop-gap solution". Если они успешно достигнут рабочего HAMR (обещают винты до 40 ТБ), то зачем им такая химера? Не говоря о том что вешать одну так себе обкатанную технологию поверх другой новой технологии это собирать все возможные баги и портить репутацию.
	Ответить | Правка | Наверх | Cообщить модератору

	392. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 20:09
	> Но зачем поверх HAMR вешать SMR? Чтобы отодвинуть следующее ограничение по ёмкости на диск, когда к нему подойдут. Или удешевить не-самые-ёмкие-диски через уменьшение числа необходимых пластин и головок. Для конкуренции с SSD нужна низкая цена за терабайт (боюсь, об остальных плюсах быстро забудут, если HDD и SSD сравняются по цене). Удешевлять корпус, двигатель, подшипник, электронику больше некуда, выход только в наращивании ёмкости на один диск и тут все средства хороши. Toshiba вот планирует впихнуть ещё одну, одиннадцатую, пластину.
	Ответить | Правка | К родителю #390 | Наверх | Cообщить модератору

	393. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 20:30
	>> Но зачем поверх HAMR вешать SMR? > Чтобы отодвинуть следующее ограничение по ёмкости на диск, когда к нему подойдут. > Или удешевить не-самые-ёмкие-диски через уменьшение числа необходимых пластин и головок. Рискованно + те же грабли что с SMR уже сейчас есть. > Для конкуренции с SSD нужна низкая цена за терабайт (боюсь, об остальных > плюсах быстро забудут, если HDD и SSD сравняются по цене). Удешевлять > корпус, двигатель, подшипник, электронику больше некуда, выход только в наращивании ёмкости > на один диск и тут все средства хороши. Toshiba вот планирует > впихнуть ещё одну, одиннадцатую, пластину. Тут да. По скорости винтам уже никак не соперничать разве что параллельно писать на разные пластины. По секурности винты тоже не радуют, SSD можно дешево очистить TRIM-ом. Как вариант давить на надежность? Сейчас у SSD с этим тоже сложности.
	Ответить | Правка | К родителю #392 | Наверх | Cообщить модератору

	394. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 21:59
	> + те же грабли что с SMR уже сейчас есть. Но их сейчас не воспринимают как явные грабли. Принимают как данность, что без SMR нет дисков на 26 ТБ и, наверное, учатся работать с HM-SMR. > параллельно писать на разные пластины. Две головки уже могут одновременно писать (Exos 2X14, 2X16, 2X18 - видно в продаже б/у или восстановленные, DC HS760), но это чтобы время перезаписи диска не росло дальше (вместе с количеством пластин, например), почти что мера против замедления. По скорости перестали пытаться конкурировать после отказа от дисков на 10K, 15K RPM. > По секурности винты тоже не радуют В каких-то HDD есть фича Instant Secure Erase (+другие названия): "шифровать весь диск и всегда выставлять расшифрованным - только ради того, чтобы диск по команде Sanitize мог стереть ключи и таким образом быстро как бы удалить данные". Некоторые SSD на самом деле возвращают данные по оттримленным адресам (обратное поведение называют DRAT и DZAT) - данные будут читаться, пока до них не доберётся сборщик мусора. > Как вариант давить на надежность? Есть только одна актуальная статистика - от Backblaze, там HDD в среднем проигрывают. Если надолго класть без питания, то HDD интуитивно лучше подходят, но производители на эту тему не говорят. Так что цена очень важна. С другой стороны лента подпирает, но там приличный порог вхождения (цена привода в миллион рублей) и нет онлайн-доступа.
	Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

	415. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:09
	> Но их сейчас не воспринимают как явные грабли. Принимают как данность, что > без SMR нет дисков на 26 ТБ и, наверное, учатся работать с HM-SMR. В btrfs Zoned энное время завезли как раз. При том - сам WD аж. Прикольно видеть комиты с @wdc.com - хорошая реклама фирмы так то :). А до кучи zoned и флешастым девайсам полезен, как раз крупноблочной природе флеша соответствует. По совсем иным причинам но интерфейс софту наружу такой же а остальное мало кого и интересует в софте. > Две головки уже могут одновременно писать (Exos 2X14, 2X16, 2X18 - видно > в продаже б/у или восстановленные, DC HS760), но это чтобы время > перезаписи диска не росло дальше (вместе с количеством пластин, например), почти > что мера против замедления. По скорости перестали пытаться конкурировать после отказа > от дисков на 10K, 15K RPM. Кому надо было скорость SSD всяко быстрее: передать новый адрес это ж не головы сгонять. А параллельная запись в произвольные места треюует >1 механику voice coil что удорожает тушку. Такие потуги были но это дорого, менее технологично и в целом в массы не пошло. Зато SSD навешивают контроллеру кучу чипов на параллельные шины, дорожек на печатку накинуть и чипов допаять - сильно проще чем механику голов. Так что скорости IO и стали пробивать потолок. > по команде Sanitize мог стереть ключи и таким образом быстро как > бы удалить данные". При этом предлагается на честное слово поверить блобикам фирмварии что оно и правда так... > Некоторые SSD на самом деле возвращают данные по > оттримленным адресам (обратное поведение называют DRAT и DZAT) - данные будут > читаться, пока до них не доберётся сборщик мусора. Вообще там по идее есть флаг - трет девайс как zero сектора или нет. И кернель учитывает это. Если кто в этом флаге гонит - ну, кто ему доктор, это уже совсем паленая фирмварь. А так btrfs например и сам не дурак забатчить группу TRIMов в асинхронном виде. Потому что в синхронном это видите ли перфоманс записей роняло. А тут накопили побольше, желательно alignment пожирнее если получилось (так фирмвари в общем случае удобнее) и пуляют уже батчем. Так куда лучше работает в целом. > Есть только одна актуальная статистика - от Backblaze, там HDD в среднем > проигрывают. Если надолго класть без питания, то HDD интуитивно лучше подходят, > но производители на эту тему не говорят. Магниты не размагничиваются со временем в отличие от вполне себе утекающего из мелких хлипких ячеек заряда. Там конечно FEC ломовой, но если все заряды утекут, никакой FEC этому не поможет, такой досадный нюанс...
	Ответить | Правка | К родителю #394 | Наверх | Cообщить модератору

	430. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 03-Ноя-23, 16:46
	> А параллельная запись в произвольные места треюует >1 механику voice coil Проблема в том, что любая параллельная запись того же требует. Одна головка или двадцать - линейная скорость всё равно около 200 МБ/с, потому что в один момент работает только одна головка, без независимой механики иначе не смогли. Если бы линейные скорости масштабировались с числом головок, на 20 головках было бы 4 ГБ/с, как у PCIe Gen3. И говорили бы: "это лишь линейные скорости, но всё-таки...". > При этом предлагается на честное слово поверить блобикам фирмварии что оно и правда так... Ну зато по нему молотком бить удобно. > Магниты не размагничиваются со временем в отличие от вполне себе утекающего из мелких хлипких ячеек заряда. Там ещё подшипник, нанометровый слой смазки на пластинах, прошивка во флеше, на больших ёмкостях гелий (но технологии 9-10 лет, пока без скандалов с утеканием), флешка как буфер и хранилка метаданных на дисках 20+ ТБ у WD (OptiNAND), всем им может поплохеть. На стороне SSD зависимости от температуры и циклов перезаписи, но... всё равно HDD выглядит получше, чем почти новый SSD в холодильнике.
	Ответить | Правка | К родителю #415 | Наверх | Cообщить модератору

	435. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 03-Ноя-23, 17:38
	> но... всё равно HDD выглядит получше, чем почти новый SSD в холодильнике. upd: но и позиционирование не как средства для холодного архива портит ситуацию. Производитель никогда не скажет: "вы можете положить жёсткий диск на полку и он через 5 лет включится". Это не аргумент за SSD, это к тому, что и SSD, и HDD лучше включать и проверять раз в несколько лет. Более-менее убедительные заявления про сохранность были для M-DISC (DVD и BD) и из-за схожести технологии они вроде переносимы на HTL BD-R.
	Ответить | Правка | К родителю #430 | Наверх | Cообщить модератору

	475. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (353), 05-Ноя-23, 16:24
	> Проблема в том, что любая параллельная запись того же требует. Ну вот тут SSD сильно в плюсе - там interleaving ограничен только жабой на сложность печатки, число пинов чипа и число чипов на борде. Скоростное IO и ушло на SSD. > Одна головка или двадцать - линейная скорость всё равно около 200 МБ/с, Теоретически наверное можно пытаться писать во все головы параллельно. Практически это вероятно упрется в неидеальности механики и с такой плотностью не прокатит. > потому что в один момент работает только одна головка, без независимой механики > иначе не смогли. Если бы линейные скорости масштабировались с числом головок, > на 20 головках было бы 4 ГБ/с, как у PCIe Gen3. Думаю что упирается в неидеальность механики - на новом проходе, вероятно, позиции пачки голов немного отличаются, дорожки немного не совпадут уже. Плотность такая что оно даже на изменения температуры рекалибровки делает. >> При этом предлагается на честное слово поверить блобикам фирмварии что оно и правда так... > Ну зато по нему молотком бить удобно. Фирмварь как-то влияет на молоток? А так кому оно реально надо - юзают демагнетизаторы. Там диск в ноль очень быстро. Хотя те кого я видел больше ленты с бэкапами чистили, стирать их приводом - за гранью зла. Но винчи это прекрасно аннулирует (после этого они невосстановимы, сервометки тоже слетят). > Там ещё подшипник, Гидродинамик как правило, износ только при старт-стопах, в рабочем режиме со всех сторон подперто давлением масла и контакта металл-металл нет. Если надолго бросить может заклинить но расклинить легко, сделав "тик-так" вокруг шпинделя. > нанометровый слой смазки на пластинах, Головы не касаются пластин. Они на воздушной, а сейчас иногда и гелиевой, подушке ЛЕТАЮТ над поверхностью на мизерном расстоянии. По этой причине удары и фатальны - при резком ударе голова таки встретится с крутящимся блином и запилит его, а вот это уже фигово. > прошивка во флеше, NOR малой емкости - хранит данные долго и надежно в отличие от хлипкого NAND. Даже антики из 1990х живые. Но кому они нужны с их емкостью? > на больших ёмкостях гелий (но технологии 9-10 лет, пока без скандалов с > утеканием), Ога. Но, кстати, сервисники пищут что если он утек - первой отваливается запись, а чтение может остаться, потому что для записи расстояние до поверхности критичнее, при попадании воздуха головы дальше от блина, запись перестает получаться, но утверждают что читается. Да и если данные капец нужны - перезаправить гелием не настолько уж нереально имхо. Обдерут, конечно, за такое. > флешка как буфер и хранилка метаданных на дисках 20+ ТБ > у WD (OptiNAND), всем им может поплохеть. А тут вопрос в том насколько оно уповает на эту флешку без бэкапа на блинах. Если что не прошлось с флехи но на блинах было - в чем проблема? Реальные траблы обычно начинаются если не прочлись сервисные части фирмвари, трансляции и проч. > На стороне SSD зависимости от температуры и циклов перезаписи, И от циклов ЧТЕНИЯ. Современный флеш все больше DRAM напоминает. 1) Утекает заряд за обозримое время и требует регенерацию (фирмварой) для чего девайс ессно должен быть запитан. 2) Чтение может вызывать утечку заряда ("read disturbance"). После эн чтений контроллер может делать регенерацию. 3) Однотипный паттерн в соседних ячейках срывает чтение. Поэтому там рандомизеры чтобы поток данных был без кучи нолей-единиц. Но ничему не противоречит если после рандомайзера на энных данных получится наоборот неудачный паттерн. > но... всё равно HDD выглядит получше, чем почти новый SSD в холодильнике. Для долговременного хранения бэкапов и проч - пожалуй. TLC/QLC очень уж сыпуч и текуч. А на MLC с 2 уровнями или SLC - дорого получается.
	Ответить | Правка | К родителю #430 | Наверх | Cообщить модератору

	478. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 05-Ноя-23, 21:59
	Уровень гелия вообще косвенно измеряется самим диском, есть SMART-параметр 0x16 Current Helium Level. Было бы веселее, если бы он постепенно полз в сторону нуля, но у меня 4 года держится на 100. Тема немного раскрывается тут (патент на измерение, анализ утечек, проблемные SMART'ы): https://www.hkepc.com/forum/viewthread.php?fid=63&tid=2639295 https://www.reddit.com/r/DataHoarder/comments/wl20q2/just_a_.../ > Головы не касаются пластин. Они на воздушной Но это не мешает смазывать пластины PFPE даже после отказа от парковки на них или восстанавливать слой со словами "будем исходить из того, что это необходимо для спасения данных". Кажется, это слишком тонкие материи. Есть успокаивающий вывод насчёт архивного хранения и испарения смазок из тех трёх мест, где они есть: https://digitalpreservation.gov/meetings/documents/othermeet... > А тут вопрос в том насколько оно уповает на эту флешку Таки сильно: > RRO metadata is generated in the factory during manufacturing. In prior generation HDDs, the RRO metadata would be stored on a disk, whereas OptiNAND stores this data in iNAND ... iNAND technology can enable both SLC for write-heavy operations and TLC for read-heavy operations in the same device. - https://documents.westerndigital.com/content/dam/doc-library... > И от циклов ЧТЕНИЯ В какой-то пдфке вижу "Threshold for read reclaim: 100,000" (перенос данных через 100 000 чтений), ну учитывать это несерьёзно. "На стороне SSD" - имел в виду, что зависимости можно использовать для более надёжного хранения. Использовать знание, что чем ниже температура и чем меньше циклов, тем меньше утечка заряда.
	Ответить | Правка | К родителю #475 | Наверх | Cообщить модератору

	492. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 15:51
	> Уровень гелия вообще косвенно измеряется самим диском, Ну да, я видел это в SMART. > немного раскрывается тут (патент на измерение, анализ утечек, проблемные SMART'ы): > https://www.hkepc.com/forum/viewthread.php?fid=63&tid=2639295 Бж, на китайском, или что это? Корейский? Японский? Впрочем картинка с завариванием гермозоны понятная вроде. Только и чинить их в случае чего наверное за это . > на них или восстанавливать слой со словами "будем исходить из того, > что это необходимо для спасения данных". Ну как бы если это ничего не портит - и хрен с ними наверное. > Есть успокаивающий вывод насчёт архивного хранения и испарения смазок из тех > трёх мест, где они есть: Поскрябав по сусекам и раскидав smartctl -a в разные стороны... 9 Power_On_Hours          0x0012   080   080   000    Old_age   Always       -       141180 Если я не облажался с калькулятором - _ЭТО_ >16 лет power on time набрало. А если его выключить то и еще лучше будет, температуры ниже и вообще. Наверное чуть старше вон той доки. > https://digitalpreservation.gov/meetings/documents/othermeet... ...да, вот этой... вон экспонат примерно той эпохи накопался, живой до сих пор. > would be stored on a disk, whereas OptiNAND stores this data in > iNAND ... iNAND technology can enable both SLC for write-heavy operations > and TLC for read-heavy operations in the same device. Ну если они в SLC зоне хранят критичные данные то и фиг с ним. Заодно и к #$%сам по девайсу менее чувствительно. > В какой-то пдфке вижу "Threshold for read reclaim: 100,000" (перенос данных через > 100 000 чтений), ну учитывать это несерьёзно. "На стороне SSD" - > имел в виду, что зависимости можно использовать для более надёжного хранения. А таки там за чтение считается любая операция чтения, в т.ч. соседних ячеек и проч. И сам по себе заряд еще утекает. Поэтому современные контроллеры SSD AFAIK могут учитывать такое. > Использовать знание, что чем ниже температура и чем меньше циклов, тем > меньше утечка заряда. Ну да. Ячейки менее разболтанные и процессы замедленны. Износ моделируется при повышенных температурах и экстраполируется на обычные, чтобы за обозримое время результат получать. Никто же не будет эн месяцев или тет чекать что там с флехой будет.
	Ответить | Правка | К родителю #478 | Наверх | Cообщить модератору

	496. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 08-Ноя-23, 23:19
	> Ну если они в SLC зоне хранят критичные данные то и фиг с ним. Надо ещё, чтобы диск не говорил "ой, всё" при повреждении некритичных данных. Поведение производителей можно кое-как предугадать по старым SSHD - раньше они таки конвертировали гибридные диски в обычные после отказа флеша. Toshiba на своём сайте оговаривала, что диск сконвертируется в обычный, про Samsung и современные на 2012 год SSHD в целом - то же самое говорили на форуме ixbt. Хотя почему-то отложилось, что SSHD считали менее надёжными именно из-за флеша. > Ну да. Ячейки менее разболтанные и процессы замедленны. Износ моделируется при повышенных > температурах и экстраполируется на обычные, чтобы за обозримое время результат получать. > Никто же не будет эн месяцев или тет чекать что там > с флехой будет. Есть на это стандарты открытые... точнее, бесплатные, за регистрацией: JESD218(+JESD219). Там формулы, trace тестовой нагрузки, требования к сохранности изношенных (на границе заявленного TBW) SSD. Гугол на "arrhenius equation ssd endurance" тоже хорошо отвечает.
	Ответить | Правка | К родителю #492 | Наверх | Cообщить модератору

	504. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (504), 11-Ноя-23, 00:29
	> Надо ещё, чтобы диск не говорил "ой, всё" при повреждении некритичных данных. Довольно часто так и бывает, но тут вопрос кто что считает критичным и ничего не мешает тому или иному производителю протупить или облажаться в той или иной фирмвари или выводке девайсов. > говорили на форуме ixbt. Хотя почему-то отложилось, что SSHD считали менее > надёжными именно из-за флеша. Ну как бы 1) Народ привык что на HDD можно писать "безлимитно". Если это не так, это обламывает ожидания. 2) Вон то это все же стремный момент, и большой вопрос что по факту откаблучит неведомый фирмвареблоб и насколько это близко к ожиданиям юзерей и авторов ФС. 3) На мой вкус я предпочту handling такого аспекта открытым ПО типа сабжа, в понятном и прозначном виде. С живыми авторами под боком на случай если лажа вышла. А закладываться в таких вещах на мутноблоб с хзкакой логикой - на мой вкус лотерея, типа как раздать гранаты зоопарку обезьян и посмотреть что будет. Может и ничего ужасного. А может и все разнесет нафиг. > Есть на это стандарты открытые... точнее, бесплатные, за регистрацией: JESD218(+JESD219). > Там формулы, trace тестовой нагрузки, требования к сохранности изношенных (на границе > заявленного TBW) SSD. Гугол на "arrhenius equation ssd endurance" тоже хорошо > отвечает. Ну я какие-то варианты этого и читал видимо энное время назад. Не думаю что там что-то радикально новое. А здравый смысл подсказывает мне что какой-нибудь QLC у которого циклов перезаписи мизер - не особо живучая штука, и никакая магия не может из г-на конфетку сделать. А FEC идеально чинит ошибки пока может, но после энного порога - наступает резкий и внезапный облом, у броадкастеров сравнимая штука называется "digital cliff effect" - в том смысле что может наступить резко и внезапно и не всегда можно предугадать этот момент. Юзеру к тому же подробные детали работы FEC не вывешены (большая часть юзеров все равно ничего не поймет). И вы там можете гадать насколько FEC плохо, но реально фирмвар вам эти данные не особо то и кажет. Более того - я электронику малость разрабатываю, и знаете да, есть стандарты, есть даташиты, а есть ушлые маркетологи, которые всегда придумают как пролезть под планкой - и все вроде честно, и денег фирме сэкономили вон сколько впарив юзерам максимально поганое Г.
	Ответить | Правка | К родителю #496 | Наверх | Cообщить модератору

	322. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 01:30
	> Более того - из-за поворота индустрии (дерьма) в сторону безумных плотностей и наращивания числа уровней Когда индустрия понизила плотность, это предпочли не замечать =) Наверное, слишком мешало рассказывать, что нонеча не то, что давеча. Но я подскажу - переход на 3D NAND, отказ от планарной 15нм TLC NAND. Аналогично есть не-SMR диски любой ёмкости. А если смело предположить, что надёжность не так уж связана с плотностью? У HDD за время существования плотность выросла на 9 порядков, но они только перестали прилипать головками к пластинам и страдать массовым падежом от всяких мух и дятлов. > не выпускают мелких и надежных ssd Допустим, что подменять надёжность на количество уровней - это нормально (нет). Ну так 3D MLC повсюду продаётся в виде Samsung SM883. И ты на стороне "индустрии дерьма", раз не знаешь об этом, ширпотреб-то гораздо выгоднее покупать.
	Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

	324. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Kuromi (ok), 02-Ноя-23, 02:16
	> так 3D MLC повсюду продаётся в виде Samsung SM883. И ты > на стороне "индустрии дерьма", раз не знаешь об этом, ширпотреб-то гораздо > выгоднее покупать. Только не забудьте что Samsung хитро трактует термин MLC как "все что не SLC", так что вчитывайтесь. Именно они придумали приколы вроде "4-bit MLC". А еще 3D у них зовется "V-NAND", маркетологи хреновы.
	Ответить | Правка | Наверх | Cообщить модератору

	414. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 13:59
	> У HDD за время существования плотность выросла на 9 порядков, но > они только перестали прилипать головками к пластинам и страдать массовым падежом > от всяких мух и дятлов. Они сейчас паркуются на рампу - ЭТО чисто технически "прилипнуть к пластине" не может, потому что никогда не касается ее. И так уже много лет. Начиная вот где-то с кончины дятлов, когда их HGST купили, с примерно тех пор они полюбили парковку на рампу, и остальные быстро содрали улучшение. > Допустим, что подменять надёжность на количество уровней - это нормально (нет). Ну > так 3D MLC повсюду продаётся в виде Samsung SM883. И ты > на стороне "индустрии дерьма", раз не знаешь об этом, ширпотреб-то гораздо > выгоднее покупать. Ну вы ж хотели быстро, терабайтами, за копейки... ну вот и получили. Как говорится, бойтесь своих желаний - они выполняются :)
	Ответить | Правка | К родителю #322 | Наверх | Cообщить модератору

	439. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 03-Ноя-23, 18:23
	> Они сейчас паркуются на рампу - ЭТО чисто технически "прилипнуть к пластине" не может, потому что никогда не касается ее. И так уже много лет. Знаю, но на старое решение интересно смотреть из 2023 года. Парковать головки прямо на пластины? Звучит надёжно. Прилипают? Отлично. Положить в морозилку и молиться? Легонько ударить? Вот время-то было, не делают больше таких дисков.
	Ответить | Правка | Наверх | Cообщить модератору

	476. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 05-Ноя-23, 16:28
	> Знаю, но на старое решение интересно смотреть из 2023 года. Парковать головки > прямо на пластины? Звучит надёжно. Прилипают? Отлично. Положить в морозилку и > молиться? Легонько ударить? Вот время-то было, не делают больше таких дисков. И это к лучшему. Взлет голов прямо с блина? Это сыкотно, как ни крути. Пыль в гермозоне, шансы что прилипнет. А то и голова оторвется, и тогда вообще капец котенку.
	Ответить | Правка | Наверх | Cообщить модератору

	466. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 04-Ноя-23, 18:55
	> Ну вы ж хотели быстро, терабайтами, за копейки... ну вот и получили. > Как говорится, бойтесь своих желаний - они выполняются :) Надо ещё понять, чего бояться. Если смешать в кучу ресурс, надёжность, data retention и принципиально отказаться от ручного overprovisioning'а, то бояться можно собственной тени. Всё страшно и непонятно и слова какие-то незнакомые говорят, верните мне SLC-диски, ведь они были такие дорогие, что можно было с чистой совестью пойти за VelociRaptor'ом и не забивать себе голову всякой чушью.
	Ответить | Правка | К родителю #414 | Наверх | Cообщить модератору

131. Скрыто модератором	+1 +/–
Сообщение от Аноним (-), 31-Окт-23, 14:57
> Линус Торвальдс утвердил запрос на включение файловой системы Bcachefs в основной состав ядра Linux и добавил реализацию Bcachefs в репозиторий, в котором развивается ветка ядра 6.7, релиз которой ожидается в начале января. Добавленный в ядро патч включает около 95 тысяч строк кода. Проект уже более 10 лет развивает Кент Оверстрит (Kent Overstreet), который также разработал входящую в состав ядра систему кэширования блочных устройств на SSD-накопителях Bcache. Вот уж что точно пойдёт на 4 пне!
Ответить | Правка | Наверх | Cообщить модератору

148. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
Сообщение от Аноним (145), 31-Окт-23, 16:07
Rust We've got some initial work done on transitioning to Rust, with plans for much more: here's an example of walking the btree, from Rust: cmd_list Отсюда https://bcachefs.org/ Ну вы поняли к чему они ведут.
Ответить | Правка | Наверх | Cообщить модератору

	152. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от пох. (?), 31-Окт-23, 17:00
	угу - уже можно обойти вокруг btree и спеть песенку или рассказать сказочку о виличии хруста. Как обычно, в общем. Расслабьтесь, не взлетит, а если и да - япнется недалеко да все больше вниз.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (176), 31-Окт-23, 19:04
	Еще как взлетит. В Btrfs и Bcachefs очень все круто продумано, за ними будущее наравне с мегастабильной и быстрой ext4 для простых сетапов. Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры, даже кластеризацию не продумали на уровне фс, а понаписали-то 30 лимонов строк кода. Я уж молчу про потерю производительности на волюмах через некоторое время использования, после чего требуется аж пересоздавать тома. В особенности если планируется создавать кластерное решение, то сейчас лучше для нижнего уровня использовать Btrfs или ext4, но никак не ZFS.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (182), 31-Окт-23, 20:13
	Экстенты не вчера придумали, и если разрабы ЗФС решили что они им не нужны, то наверное у них были для этого основания. Я сомневаюсь что они глупее опеннетовского анонима. У той же виндовой НТФС экстенты например есть, только это почему-то не добавило ей ни скорости, ни устойчивости к фрагментации. > Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры Лол, можно подумать что БТРФС и бкэшфс не точно такие же комбайны, с той только разницей, что сделаны какими-то мутными криворукими двоечниками ))
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (176), 31-Окт-23, 22:49
	Btrfs, вот это наиболее оптимизированный комбайн, более современный, там всё замечательно работает. На текущем этапе Btrfs очень стабильна, рекомендую под серьезный продакшн, чего не скажешь о ZFS, где за много лет так и не решили проблемы с фрагментированными блоками и потерями производительности на волюмах.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от t (??), 01-Ноя-23, 15:59
	но у btrfs есть недостаток - на ней нормально образы виртуалок не покрутить.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:52
	> Экстенты не вчера придумали, и если разрабы ЗФС решили что они им > не нужны, то наверное у них были для этого основания. Когда ZFSники дизайнили свое нечто, экстенты только-только появлялись и входили в оборот. А основанием может быть и "как проще было". Когда некто делает чуть ли не ПЕРВЫЙ дизайн такого рода это тоже аргумент, иначе можно надорваться. Но потом если идея была хоть немого дельной придумает как сделать v2/nextgen идеи, с учетом факапов - сделав лучше чем было до. Так и появился btrfs. Цикл повторяется. Кент посмотрел на проблемы btrfs и сделал bcachefs. Это уже стало быть gen3 технологии в каком-то роде. > Я сомневаюсь что они глупее опеннетовского анонима. У той же виндовой НТФС > экстенты например есть, только это почему-то не добавило ей ни скорости, > ни устойчивости к фрагментации. Но btrfs не требуются гигазы кешей чтобы нормально работать, так что ей реально пользоваться даже на мелочи. А ZFS без гигз на кеш вообще лучше не трогать. Потому что этому месиву без экстентов не с чему быть быстрым "самому по себе". А то что рамдиски быстрые никто и не сомневался, но это не заслуга структур ФС. Штуке кента тоже гигазы не потребуются. И вообще почему-то ZFS на цитаты никто расхватывать не хочет. Потому что проблемный и кривой дизайн, с которым только героические многолетние мучения костыляторов хоть немного это вытянули. >> Ту же ZFS лучше даже не пытаться использовать из-за переусложненной архитектуры > Лол, можно подумать что БТРФС и бкэшфс не точно такие же комбайны, > с той только разницей, что сделаны какими-то мутными криворукими двоечниками )) Почему-то они однако гибче и больше современных возможностей. А ZFS потребовалось цать лет чтобы рефлинки несчастные накодить. Которые в btrfs к тому моменту уже лет 10 были. Или даже больше, я со счета сбился. Да даже в XFS сову на глобус натянули быстрее, хоть он и не cow изначально. Это вообще уж позор, господа, ZFS-а сделали на его же поле некромансеры с классикой?! КапецЪ!
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	243. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (243), 01-Ноя-23, 08:12
	Все эти "фичи" ничто по сравнению с проблемой "write hole". А она решена только(!!!) в ZFS. Альтернатива лишь одна - дорогие HW RAID контроллеры с батарейкой. Новомодные FS созданы пока лишь для потери данных. Да, вероятно, очень быстрой и с рефлинками.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (244), 01-Ноя-23, 09:50
	> Все эти "фичи" ничто по сравнению с проблемой "write hole". Вам не приходило в голову что сценарии использования, а потому и проблемы и приоритеты у разных людей могут быть разные? > А она решена только(!!!) в ZFS. Простите, у btrfs например нет никаких особых проблем в RAID1 на эту тему. А еще есть нормальный менеджмент, когда можно подоткнуть девайс, вынуть, изменить схему хранения, и все это на ходу, шустро и относительно безопасно. А всякие RAID5/6/etc - это довольно нишевые развлечения by design. > Альтернатива лишь одна - дорогие HW RAID контроллеры с батарейкой. Бла-бла-бла. Теперь сделайте мне так чтобы мой ноут не подыхал от одного бэда. А, не можете? Ну тогда идите в пень, сапожники бессапожные. Нафиг мне технология которая даже мою задницу обслужить не может? Чтобы сидя с голым задом рассуждать что где и чего бороздит? > Новомодные FS созданы пока лишь для потери данных. > Да, вероятно, очень быстрой и с рефлинками. Что-то пока ничего не потерялось. Сколько уже лет мне это обещают - я и забыл.
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (269), 01-Ноя-23, 13:24
	> А еще есть нормальный менеджмент, когда можно подоткнуть девайс, вынуть, изменить схему хранения, и все это на ходу, шустро и относительно безопасно Всё это хорошо когда оно работает в жизни, а не только во влажных фантазиях создателей ФС. Потому что если говорить о BTRFS, то оно даже дисковое пространство не даёт нормально освободить, требуя для этой операции наличия свободного (!) места на диске. Это просто абсурд какой-то... Как при таком дизайне у них работают остальные функции -- даже проверять не хочется. Да и я вот совсем не уверен, что возможность менять наживо тип рейда является хорошей идеей: гипотетические удобства не оправдывают рисков и лишнего усложнения системы. Делать такое перестроение без подстраховки в виде бэкапа никто не станет, а если всё равно надо делать бэкап, то зачем тогда вообще нужна такая функциональность? Выглядит как усложнение ради усложнения.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от t (??), 01-Ноя-23, 16:04
	менял тип рейда наживую на пулах с данными в несколько ТБ, проблем с этим не ловил.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (269), 01-Ноя-23, 16:26
	Повезло. Я бы на такое не осмелился, учитывая что разрабы btrfs даже raid5/raid6 не осилили.
	Ответить | Правка | Наверх | Cообщить модератору

	416. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:14
	> менял тип рейда наживую на пулах с данными в несколько ТБ, проблем > с этим не ловил. Я даже крешил пару раз такие операции. И таки ничего за это нет. Ну остается оно с смесью блочных групп, указатели оно ж еще не перевесило и GC блокам в прошлом формате не сделало. Там вообще можно запросить "новую дефолтную схему хранения" а старая останется какой была и конверсия случится по мере перезаписи - все новые записи будут в новой схеме, но старые блоки специально никто ворошить не будет. Такая вот "фоновая конверсия".
	Ответить | Правка | К родителю #281 | Наверх | Cообщить модератору

	309. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 20:37
	>> Все эти "фичи" ничто по сравнению с проблемой "write hole". > Вам не приходило в голову что сценарии использования, а потому и проблемы и приоритеты у разных > людей могут быть разные? "данные ети ваши нам и даром не нужны"! (ну да, что еще ждать от фс разра... поддержание вялого барахтания которой спонсирует теперь мордокнига? Ей и правда не так уж и нужны твои котики. Новых поназапостишь. Сам. Добровольно и с песней. А твой relation graph раскидан по двум десяткам локэйшнов и переживет даже ядерную войну, а не то что отказ дисков или рассыпавшуюся от своих девичьих проблем фс.)
	Ответить | Правка | К родителю #256 | Наверх | Cообщить модератору

	417. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:30
	> "данные ети ваши нам и даром не нужны"! Да где как. Я вот напротив разогнал надежность одноплатников с SD/eMMC раскладывая там btrfs с схемой DUP, так что единичный бэд в дохрена лет более не киляет всю железку с системой как в вашим гребаным EXT4 или какой там у вас FAT в моде. Более того оно само чинит такое, заметив по чексуме где битое а где нормальное. Если такая фигня чаще чем ~раз в год это ессно повод озадачиться починкой/заменой девайса начинающего осыпаться, ДО того как удастся срубить джекпот у теорвера. > (ну да, что еще ждать от фс разра... поддержание вялого барахтания которой > спонсирует теперь мордокнига? У мордокниги разные данные есть. И врядлли они мечтают какую-нить базу на 30ТБ из бэкапов вынимать. И это у них тоже на btrfs, коли баги "на 20-м терабайте может случиться фигня" чинят. Как тебе такие логические цепочки, мистер эксперт? :) > Ей и правда не так уж и нужны твои котики. Новых поназапостишь. Сам. Добровольно > и с песней. А твой relation graph раскидан по двум десяткам локэйшнов и переживет > даже ядерную войну, а не то что отказ дисков или рассыпавшуюся от своих > девичьих проблем фс.) Но таки ресторить базу на 30 тер долго, кастомно и канительно. И это то что любой корп будет активно избегать. В общем нафиг эти сказки и этих сказочников. Мне вы уже который там год то обещаете кончину моих данных? А я вас уже столько лет в гробу и вижу с вашими энтерпрайзными переростками и прочими требованиями хранить на складе запасные девайсы энной модели. И обоими руками за то чтобы всех этих тараканов #$%нуть тапкой с железной подошвой.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Анонин (?), 31-Окт-23, 19:18
	Неужели так не будет сишных дырений при работе с памятью??
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	449. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (449), 04-Ноя-23, 08:18
	Не, будут свои, эксклюзивные для Раста дыры .
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (179), 31-Окт-23, 20:00
	даже если и перепишут (в чем я сомневаюсь). Это будет опционально и эталонная реализация останется на си.
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	181. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Анонин (?), 31-Окт-23, 20:12
	Тут сам автор этого хочет. Как он где-то писал (то ли в коментах, то ли в интервью каком-то) ему пришлось писать на си, потом что необходимые структуры в ядре для взаимодействия с растом были только в планах и сложно было оценить когда они будут готовы (потому что это не от него зависело).
	Ответить | Правка | Наверх | Cообщить модератору

154. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
Сообщение от Аноним (124), 31-Окт-23, 17:04
Не взлетит. Пипл поклюёт как Btrfs, и будут ждать новую.
Ответить | Правка | Наверх | Cообщить модератору

	188. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от Аноним (4), 31-Окт-23, 20:35
	Потому что большинству все эти фичи и не нужны. Нужна скорость, а с ней и у Ext4 с XFS все не хуже, как минимум.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 02-Ноя-23, 04:04
	ext4 с пофайловым сжатием и снапшотами была бы хороша (и чтобы и то, и то было не хуже, чем на оффтопике). e2compr был да сплыл, blksnap/dattobd/elastio-snap мутные и на замену VSS не тянут. Странно NTFS хвалить, но чёрт возьми, там эти фичи есть и ими удобно пользоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	418. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:33
	> ext4 с пофайловым сжатием и снапшотами была бы хороша У нее видите ли структуры для этого - не очень заточены. Для снапшотов не через джеппу надо CoW уметь, а это изначально как in-place делано. Да еще дурное наследие EXTов, так что вот вам лимит на число инодов. Это выжимка по максимуму легаси дизайна, попытка сделать летающее авто прямо из того что есть, не имея возможности привинтить Mr. Fusion. Ну оно и если работает - то уж как получится.
	Ответить | Правка | Наверх | Cообщить модератору

	433. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (317), 03-Ноя-23, 17:17
	> Для снапшотов не через джеппу надо CoW уметь Для снапшотов-как-способа-версионирования, где нужна хорошая работа с большим числом снапшотов. А для снапшотов-как-средства-для-бэкапов можно без CoW, который к тому же не бесплатно обходится. btrfs не смог в дефрагментацию со снапшотами, в таком смысле: "Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.".
	Ответить | Правка | Наверх | Cообщить модератору

	477. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 05-Ноя-23, 21:16
	> Для снапшотов-как-способа-версионирования, где нужна хорошая работа с большим числом > снапшотов. А для снапшотов-как-средства-для-бэкапов можно без CoW, У лично меня промежуточный сценарий. Я делаю снапшоты перед любым большим потенцильно ломающим изменением. Чтобы в случае откатиться. С другой стороны снапшоты - НЕ бэкапы и не заменяют бэкап на 100%. Зато быстрые и эффективные (а если это не так то зачем оно такое). > который к тому же не бесплатно обходится. btrfs не смог в дефрагментацию со снапшотами, Тем не менее, можно откатить эффект этого unshare блоков дедупалками. Это не идеально но продвинутым штукам - продвинутые причуды. > в таком смысле: "Defragmentation does not preserve extent sharing, e.g. files created > by cp --reflink or existing on multiple snapshots. Due to that > the data space consumption may increase.". Ну да. Однако как increase, так дедупалкой и decrease обратно. Если показать дедупалке всю иерархию конечно. Ext4 страшно далек от таких проблем - он вообще shared блоки не умеет. Как впрочем и сжатие, cow, чексумы, вот это все. Не говоря уже про человеческий менеджмент места и девайсов. Если что-то такое попытаться LVM и проч с сравнимыми возможностями - получится вообще кошмар.
	Ответить | Правка | Наверх | Cообщить модератору

	479. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 05-Ноя-23, 23:00
	> Тем не менее, можно откатить эффект этого unshare блоков дедупалками Но если вовсю пользоваться версионированием, то тогда unshare выжрет всё место и перед дедупом надо будет удалить снапшоты во избежание. > С другой стороны снапшоты - НЕ бэкапы Конечно, достаточно того, с ними меньше проблем с консистентностью бэкапа. И раз для бэкапа нужен только один временный снапшот, то больших наворотов не требуется. Самый большой требуемый наворот - чтобы пользователь мог не думать о том, куда будет писаться diff ("the shadow copy storage area can be on the same volume" - мелкософт). > Ext4 страшно далек от таких проблем Да, это всё не имеет отношения к "платности" CoW'а, неудачно сформулировал. Платить ведь приходится: - большим write amplification (WAF) на SSD - большей фрагментацией - производительностью > получится вообще кошмар У близости к земле бывают свои плюсы (хоть они и касаются не снапшпотов, а других фич, имеющихся в btrfs/zfs) - некоторые держат MergerFS + SnapRAID - получается недо-RAID5/6, не теряющий данные на живых дисках после смерти массива (из-за отсутствия striping'а) и не разваливающийся (из-за объединения не на блочном уровне; файлы всегда целиком лежат на одном диске).
	Ответить | Правка | Наверх | Cообщить модератору

	480. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 06-Ноя-23, 01:02
	> и перед дедупом * перед дефрагментацией, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	493. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 08-Ноя-23, 19:33
	> Но если вовсю пользоваться версионированием, то тогда unshare выжрет всё место и > перед дедупом надо будет удалить снапшоты во избежание. Ну, у меня для версионирования проектов GIT есть, там еще коменты, мерж, "мультиплеер", и проч. А спамить себя пачками мало изменяющихся снапшотов на уровне глобального менеджмента систем - оно надо? Но если надо, у btrfs при сильно большом числе снапшотов скорость работы с метаданными IIRC может просесть. Кент же если не ошибаюсь догнался до миллиарда, чтоли, снапшотов. Возможно это самый заснапшоченый капитан звездного крейсера с машиной времени. Не то чтобы мне это надо, но технически может быть названо преимуществом дизайна сабжа. Лично меня больше интересует заявляемая "компактность метаданных" и "скорость", имхо. А возможно и хитроджепый кеш с учетом избыточности, до кучи несколько продвинутых хранилок забацать - почему бы и нет, раз уж оно так умеет? Не основной сценарий для меня но на правах приятного бонуса - вполне. >> С другой стороны снапшоты - НЕ бэкапы > Конечно, достаточно того, с ними меньше проблем с консистентностью бэкапа. С другой стороны, 1 бэд под shared экстентом может сильно испортить настроение. Ведь не прочтется то вся пачка. Конечно если избыточность была это хорошо, но возможны и иные варианты. Скажем dd в блочные устройства, ошибка менеджмента снапшотов, пых питальника унесший все диски, системный сбой RAM/CPU/... вынесший метаданные ФС, или еще какой грубый факап который снапшотом не откатывается. > И раз для бэкапа нужен только один временный снапшот, то больших наворотов не > требуется. Снапшоты удобны с точки зрения бэкапирования что они не будут меняться под бэкапалкой. Приветы, видимо, VSS, только тот - капец тормоз и ресурсожор. А в этих дизайнах снапшоты по сути халява. Однако понимание консистентности состояния файлов "in flight" это все же весьма отдельный топик. Кстати в btrfs можно в ряде случаев и рефлинками это обыграть. Да и в сабже, вероятно, тоже. Я так скажем виртуалки зацеплял: делаю рефлинк диска прямо c запущеной VM, и цепляю рефлинка. Внутрях тоже btrfs обычно. Это как бы неправильно ("некорректный шатдаун"), но cow похрен, там лишь чуть более старое состояние будет. И кстати cow-на-cow таки тоже не рекомендуется. Но я c этими гипердвигателями возился столько что мне таки можно, если осторожно. Ибо я очень хорошо понимаю какой у меня размер дельт, что я собираюсь сделать, и вообще. > Самый большой требуемый наворот - чтобы пользователь мог не думать > о том, куда будет писаться diff ("the shadow copy storage area > can be on the same volume" - мелкософт). Я терпеть не могу их shadow copy, дико тормозное и контринтуитивное нечто. Юзеры не понимают как это работает, технари обычно не оценивают тупняки и жор места в контринтуитивном виде, и кому оно в таком виде надо я ХЗ. Однако у лично меня - снапшоты в btrfs идут "на 1 уровень выше /" и его при нормальной работе системы таки не видно. Но при желании поменеджить это просто новое измерение, в котором живет некий ансамбль миров. Можно выбрать в который из них хочется попасть. Технически делается монтированием "full view" в любую точку иерархии. Но вот тут я понимаю как это работает. Саму структуру с subvolumes вот так - придумали убунтуи. Нормально придумали как по мне. >> Ext4 страшно далек от таких проблем > Да, это всё не имеет отношения к "платности" CoW'а, неудачно сформулировал. Ext4 вообще нифига не умеет по сути и потомок намного более архаичных дизайнов. Его некорректно сравнивать с cow. Записи деструктивны (in place), полный журнал тормозной как черти что или если на это забить то структуры ФС конечно консистентны будут но вот файл из наполовину новой головы и старого хвоста - сомнительная радость. А без журнала данных это вообще никак не обыгрывается же. > Платить ведь приходится: > - большим write amplification (WAF) на SSD Я помониторил статистику, сделал commit time побольше (200 секунд), врубил SSD + spread, да и пришел к выводу что если системный SSD за 5 лет протерся на аж 3%, не выглядит большой проблемой. Конечно, если бы это была нагруженная БД это другой разговор. Но я не DBA, мне пофиг, а для DB придумали NOCOW. > - большей фрагментацией 1) SSD пофиг. 2) У btrfs дефрагер есть. Не идеальный но все же. ZFSники... ну, это их проблемы. Сабж - waiting for -rc1, тогда понятнее будет. 3) С другой стороны cow может писать выноски с полной скоростью куда там удобно. В целом - ну да, чуть медленнее. Но не критично. И в сумме для меня оно того стоило учитывая новые возможности. А на одноплатниках где DUP парирует редкие единичные бэды это вообще EPIC WIN. Один с EXT4 у клиента рассыпался и было совсем не круто: бэд libc6 накрыл, девайс резко и без предупреждения стал тыквой. Возможность такой тыквы - хреновое свойство, DUP улучшает теорвер в другую сторону. Системные образа у меня мелкие - ополовинивание места не парит. > - производительностью >> получится вообще кошмар В моих сценариях - не получается никаких кошмаров. Так на глаз от ext4 вообще малореально отличить в большинстве случаев. Кстати btrfs'ники с своим bg_tree новомодным - сделали ext4 и xfs по скорости монтирования, я получил приятный бонус к скорости загрузки систем в ряде случаев. Кент вообще сразу на перфоманс ориентировался, premature optimizations сыграли с ним дурную шутку, типа FTBFS на ряде архитектур, терок с майнтайнерами, W^X viol и проч. > У близости к земле бывают свои плюсы (хоть они и касаются не > снапшпотов, а других фич, имеющихся в btrfs/zfs) - некоторые держат MergerFS > + SnapRAID - получается недо-RAID5/6, не теряющий данные на живых дисках > после смерти массива (из-за отсутствия striping'а) и не разваливающийся (из-за объединения > не на блочном уровне; файлы всегда целиком лежат на одном диске). Для меня 1 из ключевых плюсов btrfs это простой понятный и логичный менеджмент файлухи, минимум возни с ней, self heal/малообслуживаемость, ненужность fsck и проч. Чего и Кенту желаю. И снапшоты для меня это такой способ сделать менеджмент bare metal удобным, в стиле виртуалок почти. Заниматься всякой многоэтажной камасутрой с супер-решениями хз зачем, черти-чьими технологиями хз где и трехэтажными наслоениями костылей - не мое, мне удобно когда все-в-одном в майнлайне, я доверяю этим господам, ряду команд из, а не кому попало. Бонусом я так то data recovery немного балуюсь. Btrfs я уже понимаю достаточно для того чтобы в пиковой ситуации иметь шансы, особенно с их офлайн читалкой прямо в штатных тулсах, да и btrfs'ники - полезные и эффективные господа оказались, когда я баги встретил. Интересно этот опыт с Кентом сравнить будет. ... кстати Кент время зря не терял и пока окно приема открыто, он только что забомбил большой "довесок", который догоняет bcachefs в кернеле до master. Как-то так выглядят сверхновые^W переход на интеграцию с майнлайном, видимо, комит c9d01179e185f72b20af7e37aa4308f4c7ca7eeb
	Ответить | Правка | К родителю #479 | Наверх | Cообщить модератору

	495. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 08-Ноя-23, 23:12
	> Ext4 ... полный журнал тормозной как черти что > придумали NOCOW От новых файловых систем всякого хотят. Кому-то без data journal норм, а с потерей новых фич в nodatacow - не норм. Ладно сжатие отваливается, но ведь и data checksumming тоже. Осталось добавить в btrfs шифрование и тоже его отрубить для nodatacow. > Заниматься всякой многоэтажной камасутрой с супер-решениями хз зачем, черти-чьими технологиями > хз где и трехэтажными наслоениями костылей - не мое, мне удобно Шифрования в btrfs нет. Придётся наслаивать. RAID5/6 в btrfs "как бы нет". Снова наслаивать. Cryptsetup предлагает добавить контрольные суммы для всего (добавить dm-integrity уровнем ниже dm-crypt). Тут уже задумаешься, нужно ли сверху наслаивать именно btrfs, а не что попроще, если одна из её фич так легко замещается*, а красиво, шоб всё в одном как в ZFS, всё равно не получается. И глядя на ZFS начинаешь сильнее ценить гибкость, потому что слишком многое там делается через "Если к вам пришли гости, а у вас ничего нет, пошлите человека в погреб, пусть принесёт фунт масла, два фунта ветчины, дюжину яиц, фунт икры, красной или чёрной, и приготовьте лёгкие закуски"... то есть "пошлите человека в погреб, пусть принесёт стопку HDD, чтобы собрать ещё один массив и таким образом отменить дедупликацию, сделать дефрагментацию или ещё какую мелочь". Уж что-что, а невероятную гибкость MergerFS+SnapRAID даёт**. Ещё журнал ext4 и контрольные суммы dm-integrity выносятся на отдельное устройство побыстрее. Вроде костыли, но зато какие - можно пальцем показывать на SPECIAL vdev в ZFS. Чем менее популярна ФС, тем меньше инструментов для восстановления данных, тоже такое. * но будет сложнее искать, какой файл задел битый сектор ** это звучало бы убедительнее, если бы я сам ими пользовался
	Ответить | Правка | Наверх | Cообщить модератору

	501. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Ноя-23, 15:50
	> От новых файловых систем всякого хотят. Кому-то без data journal норм, И без прочих чексум, хренли. EXT4 вообще плевать хотел на участь юзеровских данных и ничкому нишиша не гарантирует. Даже с RAIDами блин, там как я понимаю вообще нет плана если диск в RAID отдаст левак в секторе. Это - то как работает этажерка костылей и наслоений. Просто побьет данные втихаря, вы даже и не узнаете. До тех пор пока оно не потребуется конечно, тогда узнаете, но к тому моменту сколько там времени пройдет, может у вас и бэкапы все уже убитые с этим давно, все ж файлы в каждом бэкапе проверять жрут ли их реально программы - сами понимаете. Меня больше всего смущает что вон те хотельщики с такими ФС смеют что-то предъявлять на тему целостности данных. Им бы определиться чтоли с хотелками. Они что, хотят глюкать на откровенно сыпящемся оборудовании, пусть данные бьет, но совсем в ноль не сыпется, дескать? Или чего? Вот это - и правда странное желание ряда "экспертов" как по мне. Как по мне таких "экспертов" лучше не слушать, данные целее будут. А у них самое ценное что есть это сэйвы в гамезе какой поди да торенты которые перекачать можно. > а с потерей новых фич в nodatacow - не норм. > Ладно сжатие отваливается, но ведь и data checksumming тоже. Осталось добавить в btrfs > шифрование и тоже его отрубить для nodatacow. Ну так на EXT4 вообще чексум нету. И ничо - эксперты жрут. А nodatacow это такой режим для БД и прочих "fs-like" сценариев типа CoW дисков виртуалок, желавших делать большую часть того что ФС делала самостоятельно. Включая и журнал, и что там еще. Это вот такой себе режим "как в EXT4". Если кто хотел фичесет EXT4 и чтобы работало так как оно, он ЭТО и получает. На что жалобы? И почему EXT4 это же самое не предъявляется, интересно? :) >> хз где и трехэтажными наслоениями костылей - не мое, мне удобно > Шифрования в btrfs нет. Придётся наслаивать. Во первых оно нужно не везде и не всегда. Во вторых вот именно его как раз не очень сложно наслоить. Но так между делом fscrypt для btrfs по-моему даже уже где-то летает в виде патчей. > RAID5/6 в btrfs "как бы нет". Снова наслаивать. RAID56 это такая штука что стоит дважды подумать - а хочется ли это вообще. Особенно RAID5 и/или в "классическом" виде с write hole, когда потом еще и понять трудно - а что вообще побилось. Да и менеджмент ЭТОГО с наслоениями - булшит полный, "храните 100500 идентичных девайсов на складе". Очень удобно и практично. А btrfs может почти любую схему на "произвольном числе девайсов" делать. Там аллокация простраства куда более разумно делается чем блочный трешак с выравниванием на эн чушек равного размера и никак иначе. Это дает свои проблемы, зато менеджмент ЭТОГО - вообще совсем иная история. И попробовав однажды вбивать координаты в бортовой компьютер гипердрайва уже совсем не хочется назад на механические тяги. Вообще совсем никак. Это совсем иной уровень технологий и управления системами. > Cryptsetup предлагает добавить контрольные суммы для всего (добавить dm-integrity уровнем > ниже dm-crypt). Тут уже задумаешься, нужно ли сверху наслаивать именно btrfs, Ну как бы btrfs при несовпадении чексум в RAID1 или даже DUP (мало ли, бэдсектор вылез) - просто утащит данные из 2 копии. Восстановив в фоне порушеный кус. Наружу софту это вообще не видно. А у вас на такой случай какой хитрый план? Особенно с крипто, где отклонения от идеала запросто ведут к массовым потерям данных. Вон та механика как себя поведет если разные зеркала разные данные отдали? А то реальные сторажи зачастую вместо кончины начинают просто отдавать какой-то левак. С избыточностью и чексумами понятно что, можно понять кто нам г отгрузил. И дальше пофиксить, а если это часто - то и заменить девайс. А вон там этот сценарий - как? > а не что попроще, если одна из её фич так легко замещается*, а красиво, шоб > всё в одном как в ZFS, всё равно не получается. Мне ZFS не надо: его нет в майнлайне, да и с его дизайном он только для энтерпрайзных файлопомоек и имеет смысл. Меня имхо больше всего интересует как раз то что озвучил Кент: стыковка general purpose и продвинутых технологий. И всякие нестандартные сценарии. А вот файлопомойки мне если и интересны - то только до кучи. > HDD, чтобы собрать ещё один массив и таким образом отменить дедупликацию, > сделать дефрагментацию или ещё какую мелочь". Уж что-что, а невероятную гибкость > MergerFS+SnapRAID даёт**. С вон теми оговорками - видите ли я привык к тому что btrfs не только "находит" это, но еще и SELF HEAL делает! Так что пара бэдов с трухой или нечитаемых - вообще не проблема. Если избыточность была, конечно, потому что чудес на которые фаны EXT4 уповают - не бывает. Если избыточности нет, то и предсказуемого flawless recovery - тоже. А вон там уже можно потрепыхаться и оно таки стоит определенной возни, если одноплатники не дохнут от 1 бэда, ноут не разваливается внезапно в хлам, и вообще. > Ещё журнал ext4 и контрольные суммы dm-integrity выносятся на отдельное > устройство побыстрее. К сожалению вот это все делает менеджмент кошмаром. И допускает что это устройство - было. Как я уже сказал - я не про энтерпрайзные хранилки, меня больше смежные, гибридные и странные кейсы в этом контексте интересуют. > Вроде костыли, но зато какие - можно пальцем показывать на SPECIAL vdev в ZFS. Кому надо - тот пусть и показывает. Это буду не я, ибо я уже понял где я такой менеджмент файлух видал благодаря Крису Мйэсону показавшему что можно и сильно получше чем это все. Кент, вроде, азы создания звездолетов - вот - усвоил. Это и делает его дизайн интересным мне. > Чем менее популярна ФС, тем меньше инструментов для восстановления данных, тоже такое. У btrfs прямо в штатных тулсах офлайн вычитывалка с альтернативным парсером. И возможностью опробовать разные точки входа в иерархию, cow же не сносит все и сразу, так что можно здорово потрепыхаться. Круче любых r-studio, тирамис и проч. А еще открытое, бесплатное, и с адекватными девами воооон там которые даже при серьезном настрое - расскажут и помогут. Конечно если это не совсем чайник, у них нет ресурсов азы давать. Но если я пришел и точно знаю что мне надо - я это получаю. И довольно быстро, как показали эксперименты. >  * но будет сложнее искать, какой файл задел битый сектор > ** это звучало бы убедительнее, если бы я сам ими пользовался Ну вот с такими оговорками... я вот жру пирожки которые рекламирую. И поводом для рекламы является тот факт что мне это нравится :). * * Сабж, конечно, я юзать еще чисто технически в эксплуатационном виде не могу, там мне нравится дизайн и мышление его архитекта, а также общая упертость оного, когда он гнет свою линию несмотря на все траблы. Будущее должно принадлежать таким людям, тогда в нем будет прикольно жить. А когда апстрим рефлинки 15 лет делает из CoW дизайна, и ни 1 бага на майнлайн с левым модулем не вкатишь - зачем мне такой дизайн, право? Я часть тех процессов - по своим причинам. Мне это надо.
	Ответить | Правка | Наверх | Cообщить модератору

	506. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 11-Ноя-23, 04:50
	> И без прочих чексум, хренли. EXT4 вообще плевать хотел на участь юзеровских > данных и ничкому нишиша не гарантирует. А с этим живут по таким причинам: - Без ECC-оперативки данные всё равно могут побиться в памяти. Data checksumming заделает дырочку в надёжности хранения, но у пользователей не-ECC-оперативки останется дырища рядом. - Диски жёсткие и твердотельные имеют ECC. Его хватает, чтобы сказать "тут bad block", а не молча вернуть прочитанный из нужного места мусор. Использовать софтовый data checksumming - значит не доверять end-to-end protection внутри диска (если он есть) или заменять его, расширять его на остальные звенья (SATA-контроллер). То есть это мера против потенциального отсутствия ECC в прочих видах памяти (где лежит/исполняется прошивка, где различные буферы/кэши), против ошибок и недоработок в прошивке, вызывающих в том числе phantom writes, misdirected reads/writes. Впрочем, если SSD перестарался с попытками коррекции и вместо ошибки выдал ложноположительный результат - это и недоработка в прошивке, и молчаливое возвращение прочитанного мусора... Тут кто первым надел халат, тот и доктор. 15 лет назад одни надели халат и похоронили RAID5. Из-за одного загадочного числа в спеках жёстких дисков - URE/UBER (RAID6 дали отсрочку). Не сбылся их прогноз о дисках, которые сложно прочитать целиком без единой ошибки (12+ ТБ, URE=10^-14), халат отняли. Другие халат не снимают, потому что у них ext4/XFS или винда без ReFS или макось. И работает. И тихое повреждение данных кажется слишком мифологизированным. Мол, data checksumming необходим там, где обитают хранилки с 520/528 байтами на сектор, но не везде. Ты халат надел, а базу данных и виртуалки допустил положить в nodatacow. Приравнял к торрентам и сохранениям в играх в аспекте контрольных сумм. Пожертвовать контрольными-суммами-для-данных ради скорости? Вот так остальные файловые системы и работают. > Даже с RAIDами блин, там как я понимаю вообще > нет плана если диск в RAID отдаст левак в секторе. Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности при чтении (а не только при ручном запуске проверки). Как я понимаю, эта же проблема будет в btrfs+nodatacow и её не будет* с dm-integrity, о котором писал ниже. * защита от misdirected reads/writes должна требовать дополнительной настройки. > Меня больше всего смущает что вон те хотельщики с такими ФС смеют > что-то предъявлять на тему целостности данных. > Им бы определиться чтоли с хотелками. Почему бы и не хотеть, у всех свои приоритеты. Некоторые вообще считают, что люди вокруг не используют ZFS, потому что им не важны их данные. Тоже отказывают в иной расстановке приоритетов и отмахнутся от твоих слов про "не general purpose", достанут очередной свежий баг в btrfs и станут размахивать им: https://bugzilla.redhat.com/show_bug.cgi?id=2169947. Чем холоднее данные, тем больше вариантов открывается, вплоть до par2. > И почему EXT4 это же самое не предъявляется, интересно? :) Так речь о хотелках по новым ФС, как некоторые фичи накостыливаются-наслаивается к старым ФС - понятно. Дарю убийственный аргумент: "нечего тут на опеннете рассуждать, иди и сделай свою правильную ФС, делом займись". > Ну как бы btrfs при несовпадении чексум в RAID1 или даже DUP > (мало ли, бэдсектор вылез) - просто утащит данные из 2 копии. > Восстановив в фоне порушеный кус. Наружу софту это вообще не видно. > А у вас на такой случай какой хитрый план? Если он рутинно вылез, то диск сам о нём скажет, чексумму от ошибки не посчитаешь. Если прочитался мусор без  ошибок, то загадочное тихое повреждение данных не стоит бэдсектором называть. > md: read-error will instead cause md to attempt a recovery by overwriting the bad block. i.e. it will find the correct data from elsewhere, write it over the block that failed, and then try to read it back again. > dm-integrity: dm-integrity target can be used to detect silent data corruption on the disk or in the I/O path. По-хорошему, все сетапы надо проверить через внедрение ошибок. Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?), zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup. PS: в предпредыдущем комменте отступы сломал, там везде "цитата - ответ": > [Если что-то такое попытаться LVM и проч с сравнимыми возможностями -] получится вообще кошмар У близости к земле бывают свои плюсы [- там, где посконные "LVM и проч", там и MergerFS со SnapRAID].
	Ответить | Правка | Наверх | Cообщить модератору

	513. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 12-Ноя-23, 23:04
	> А с этим живут по таким причинам: Забыли еще пару: отсутствующие знания, а то и склонность заменять знания измышлизмами. Впрочем хуже от этого в основном носителю такой точки зрения, покуда они ее не распостраняют. > - Без ECC-оперативки данные всё равно могут побиться в памяти. На практике btrfs при таком обычно орет "csum error" в логи и если юзерь не совсем баклан... из того что на виду, отловился глючный проц и пару плашек оперативки как раз. Неплохой валидатор работы оборудования получился. А то что EXT4 и прочие NTFS молчат в тряпочку - так это до поры. Когда метаданные совсем в труху разносит - юзеры таки познакомятся с датареком. Я несколько таких NTFSов выковыривал, после этого конечно оперативу меняли, но там уже труха на диске. Самое ценное конечно достать обычно удается, с той или иной степенью урона, но такой том только под реформат потом: он глючный что капец и может в любой момент обвалиться опять. > - Диски жёсткие и твердотельные имеют ECC. Его хватает, чтобы сказать "тут > bad block", а не молча вернуть прочитанный из нужного места мусор. Это может себе вообразить только тот кто никогда не интересовался как это работает и видимо не имеет особого опыта эксплуатации компьютерных систем. Во первых что там сделает немеряный фирмвароблоб - целиком на его усмотрение. Реакция фирмвар на подобные вещи весьма разнообразна. Во вторых FEC может с некоей (небольшой, но не нулевой) вероятностью посчитать рандомную труху за что-то валилдное. Это редко, но с ростом плотности устройств, числа секторов и погоней за емкостью и ценой за счет общей хлипкости... Поэтому на практике я видал как девайсы выгружают из секторов явный левак, не удосужившись сообщить IO error. И у тех додиков на такой случай плана нет. У многих райдов, кстати, тоже. Btrfs то при наличии чексум - вопит csum failed, БЕРЕТ БЛОК С ДРУГОЙ КОПИИ (точно зная что хочет и какой там чексум), чинит битую копию, заодно и кривой сектор ремапнуть получится. Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать, спасибо если не вбив девайс в failsafe mode, после чего юзер уж точно к датареку пойдет. И один сектор, который фирмвари ремапнуть раз плюнуть, может эскалировать в убер-проблему, фатальную и дорогую. Потому что сами вы уже оттуда ничего не вытащите скорее всего. > Использовать софтовый data checksumming - значит не доверять end-to-end protection внутри > диска (если он есть) или заменять его, расширять его на остальные > звенья (SATA-контроллер). Это как раз отличная идея, чисто с точки зрения теорвера. Если вероятность лажи чексумы ФС 1/N и девайса 1/M то вероятность что они ОБЕ одновременно лажанут - уже 1/(N*M) что куда как прикольнее. А девайсы выгружающие треш в секторах без репортов IO Error я лично видел. Btrfs то на это вопит csum failed и чинит, чего б ему не. У меня даже есть пара особо сыпучих флех - посмотреть, проиграю я когда теорверу с схемой DUP на заведомо хреновом носителе или нет :). Реально - на сыпучей флехе становится можно таскать файлы ценой ополовинивания емкости, таки не мрет по простому. > ошибок и недоработок в прошивке, вызывающих в том числе phantom writes, > misdirected reads/writes. Де факто это end to end проверка работы железа. И это очень хорошо. Дада, и 1 глючный шнурок тоже под внимание попал за "csum failed". А какой-нибудь ext4 тихо схарчил бы такие пакости. > Впрочем, если SSD перестарался с попытками коррекции и вместо > ошибки выдал ложноположительный результат - это и недоработка в прошивке, Если вместо того чтобы умничать на форумах сходить качнуть лекции CS где расписаны типовые алгоритмы и их свойства, можно узнать что чудес не бывает и есть некая вероятность что алгоритм примет труху за чистую монету. И чексум может сойтись на левых данных. Конкретика конечно зависит от деталей, типа ширины чексумы. FEC вообще не чексум, он в этом качестве "до кучи" подрабатывает и имеет довольно компромиссные свойства, но не тратить же места еще и на чексумы, убавив емкость на лэйбе девайса?! Отдел маркетинга вас не поймет. > и молчаливое возвращение прочитанного мусора... Я пару раз даже на HDD такое видел, а для флешастых девайсов это "довольно типовой" faulure mode я б сказал. И статистика конечно же набралась потому что я знакомым btrfs нарекламил. Ну мы вместе и узнали о свойствах оборудования. И о чем не пишет отдел маркетинга. > сбылся их прогноз о дисках, которые сложно прочитать целиком без единой > ошибки (12+ ТБ, URE=10^-14), халат отняли. На самом деле для небольших инсталяхах IMHO RAID5 можно и попытаться. Но только понимая ограничения этого всего. Вообще делать большие или пролвинутые сетапы совсем не понимая тематику - чревато. > Другие халат не снимают, потому что у них ext4/XFS или винда без > ReFS или макось. И работает. И тихое повреждение данных кажется слишком > мифологизированным. Я паре таких мифологов потом с их NTFSа выколупывал добро. Когда винды в бсод при маунте нтфс начинают улетать - так то да, даже жирафу заметно что гамно какое-то :). В этом месте линуксоид под боком срубает свой EPIC WIN. Хотя-бы за счет альтернативного парсера который в синий скрин ну вот не уходит. > Мол, data checksumming необходим там, где обитают хранилки с 520/528 > байтами на сектор, но не везде. Я btrfs в довольно большом числе довольно разных сетапов юзаю, от SD и eMMC до нескольких многодисковых штук (RAID1 в основном) и ну вот не считаю чексумы чем-то лишним. > Ты халат надел, а базу данных и виртуалки допустил положить в nodatacow. Если я это сделал - у меня был какой-то запасной план на этот случай. Я не одиваю халат чтобы своей некомпетентностью пациентов гробить. > Приравнял к торрентам и сохранениям в играх в аспекте контрольных сумм. > Пожертвовать контрольными-суммами-для-данных ради скорости? Вот так остальные файловые > системы и работают. Ну как бы если кому плевать на свои данные я так то не против, но когда они при этом начинают высовываться и что-то про (не)надежность ФС лечить - это не находит моего понимания. > Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности > при чтении (а не только при ручном запуске проверки). Ну а вот BTRFS заметив сбой чексумы берет из второй копии и чинит. Выглядит как-то так: [82374.200674] BTRFS info (device sdg): scrub: started on devid 1 [82471.511063] BTRFS error (device sdg): fixed up error at logical 3180593152 on dev /dev/sdg physical 5336465408 [82491.759994] BTRFS error (device sdg): fixed up error at logical 2634088448 on dev /dev/sdg physical 5863702528 Это катитт и с DUP на 1 девайсе, и с RAID1 на разных. Не обязательно scrub пинать, обычное чтение тоже котируется. Это я для иллюстрации как сие работает на заведомо-сыпучей флехе scrub пнул чтобы увидеть сбой чексум и его парирование за обозримое время. > Как я понимаю, эта же проблема будет в btrfs+nodatacow и её не > будет* с dm-integrity, о котором писал ниже. Никто не заставляет юзать nodatacow. Сценарии разные бывают. У меня даже местами виртуалки с btrfs на btrfs норм живут. Не то чтобы это рекомендуется для нагруженных сценариев, но если понимать лимиты технологий, с ними можно жить. > * защита от misdirected reads/writes должна требовать дополнительной настройки. К сожалению во всем этом мусоре - нормальный менеджмент не завезли. В btrfs DUP на однодевайсном конфиге 1 командой делается. Прозрачно. На ходу. Без дестроя. Теперь донавесьте 2 копии на 1 девайсе с авто-фиксом факапов вашим способом. Ну или почем мой ноут или те выводки одноплатников не могут попытаться парировать единичный бэд, например? У меня вот могут - и это оказалось полезным улучшением свойств файлух как по мне. > твоих слов про "не general purpose", достанут очередной свежий баг в > btrfs и станут размахивать им: https://bugzilla.redhat.com/show_bug.cgi?id=2169947. Надо же какая новость, в софте баги бывают. Проблема в том что багов бывает в самом разном софте. И если кто утверждает что btrfs в этом уникален - значит он целенаправленно втирает очки. А так да, рассылки блочников и файлушников и проч лучше на ночь не читать, спокойно спать не сможете. Но говоря за себя - в моих конфигах это просто работает. Какие-то проблемы я огребал только с -rc ядрами, заодно узнав что brtfs'ники очень крутые, компетентные и оперативные ребята которые горой за качество своей вундервафли. Сообща оттрекали и загасили все что мешало мне жить. Опенсорс - это вот так. А желаюшие быть консумерами и получить ынтырпрайз грейд экспериенс именно его и получат. И пусть потом не плакают, а хотя-бы и занося чемодан денег или выписывая баги в какое там спортлото. > Чем холоднее данные, тем больше вариантов открывается, вплоть до par2. Оно как бы да. Но у всяких штук типа снапшотов есть плюсы в том что они создаются шустро, и поводом к их откату обычно является факап на совсем ином уровне. А бэкапы никто не отменял. Просто это достаточно долгая операция с своей канителью и невкусным временем рекавери. > Так речь о хотелках по новым ФС, как некоторые фичи накостыливаются-наслаивается к > старым ФС - понятно. Дарю убийственный аргумент: "нечего тут на опеннете > рассуждать, иди и сделай свою правильную ФС, делом займись". А таки разработчики ФС зачастую открыты к разумным пожеланиям. Особенно если они не сильно сложно натягиваются на эннфй дизайн. А иногла даже и сложно. Ну вон в zfs 10 лет поотмазывались но все же смогли сову, на глобус, тьфу, рефлинки то-есть на "типа cow". Позор ситуации в том что XFS который изначально не cow и то раньше это смог. Думаю прозрачно намекает почему Кент копипастил с btrfs дизайн, а не с того нечто. Оно ж даже экстенты полноценные не умеет и затыкает тормоз-дизайн гигазами оперативы. >> А у вас на такой случай какой хитрый план? > Если он рутинно вылез, то диск сам о нём скажет, Вооооон выше пример фикса на именно подленькой сыпучей флехе, которая как раз и не утруждает себя сообщением IO error, вместо этого выгружая труху. А вот btrfs подляну видит и даже чинит. И вполне себе может жить с этим - если избыточность есть. > чексумму от ошибки не посчитаешь. Если прочитался мусор без  ошибок, то загадочное > тихое повреждение данных не стоит бэдсектором называть. Btrfs в случае IO error сразу идет за другой копией и чинит из нее. И какая разница по csum failed это инициировано или по io error. На результат не влияет. > По-хорошему, все сетапы надо проверить через внедрение ошибок. У меня есть даже небольшая коллекция особо мерзеньких девайсов. В основном благодаря btrfs и его чексумам. Вот заодно и посмотрю как штука Кента отнесется к этому самому. Мне ж не нужна сферическая файлуха для идеального вакуума. > Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?), > zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup. И пусть себе есть. Где-то там. Попользовавшись btrfs я для себя решил что хочу видеть системный менеджмент вот так. Просто, логично, прозрачно, с динамическим перераспределением ресурсов под задачи и возможностью реконфигурации малой кровью. А те долбаные этажерки - пусть их похи всякие используют, вместе с другими экспертами. И очень круто что господа типа Кента понимают где такому менеджменту систем вообще и ФС в частности на самом деле место. На помойке! И скучать по всему этому брейнфаку мало кто будет, имхо. А интеграция ФС и девайсов дает нефиговые новые возможности, которое вон то либо не может, либо реализует так что лучше б и не позорилось. Типа какихнить снапшотов в LVM. Нахрен мне такие снапшоты после того как я btrfs попробовал. И у Кента они по идее должны быть не хуже. Но это еще предстоит проверить.
	Ответить | Правка | Наверх | Cообщить модератору

	514. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 13-Ноя-23, 11:52
	> На практике btrfs при таком обычно орет "csum error" в логи и > если юзерь не совсем баклан... из того что на виду, отловился > глючный проц и пару плашек оперативки как раз. Неплохой валидатор работы > оборудования получился. Эмм, в оперативную память кладут и другие вещи, помимо данных для btrfs scrub. И они побьются заодно. Только контрольной суммы у них не будет. Но перед записью на диск появится, подсчитанная от уже побитых данных. Случай с глючной оперативкой (которую можно выявить и иначе) достаточно очевиден, а халат нужен в разговоре про космически-лучевые soft error'ы. > Это может себе вообразить только тот кто никогда не интересовался как это > работает и видимо не имеет особого опыта эксплуатации компьютерных систем. Поведай, зачем тогда изобрели RAID-массивы. В них (без доп. data checksumming'а) не было бы смысла, если бы диск обычно умирал "тихо". Хотя и так ясно, что изобретатели не интересовались, как это работает и не имели особого опыта. На этом держатся все системы без контрольных сумм для данных (без T10-PI, ZFS, btrfs, ReFS, dm-integrity што там ещё). Слова я выбирал, категоричности избегал, дальше мысль раскрыл, исключения описал. > Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать Но что сможет сделать btrfs без избыточности? ext4-без-массива-под-ней здесь всё-таки как соломенное чучело для спора. > Если вместо того чтобы умничать на форумах сходить качнуть лекции CS Можно и патенты Hynix с его miscorrection metric'ами и miscorrection threshold'ами. Перестараться - это, наверное, некорректное упрощение, но всё-таки у SSD есть возможности следить за своим здоровьем, свалиться в fail-safe пораньше. > Я пару раз даже на HDD такое видел Вот это интересно. А про SSD - в ресурсном тесте 3dnews вроде три экземпляра умирали подобным образом и это разочаровывает, исход с тихим повреждением не должен становиться нормой. > На самом деле для небольших инсталяхах IMHO RAID5 можно и попытаться. Но только понимая ограничения этого всего. Мой посыл был только на тему халатов. В 2007 появилась нашумевшая статья* о том, что RAID5 через два года придёт конец из-за URE=10^-14. Остальные риски для автора не имели значения. Не важно, умрёт ли диск во время ребилда, когда даже обычный исправный диск нельзя прочитать без нескольких неисправимых ошибок (бэд-блоков). И эти мысли укоренились. Говаривали даже, что RAID0 надёжнее RAID5 - математически доказано - всё равно во время ребилда** ошибки похоронят массив на ~10+ ТБ, а дисков в RAID0 меньше. Получилось интересное помешательство. Часть людей поверила в рассказ про RAID5 и URE, не задумываясь о том, что реальный URE гораздо ниже. Не задумываясь, что каждый первый scrub якобы должен исправлять по ошибке на дисках типа Toshiba N300 16TB. Что без избыточности (RAID/DUP) такие диски должны быть не бесполезны, а даже опасны. Что их SMART должен плодоносить ошибками. * https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/ ** В остальное время бэд-блоки спят. Автор не учёл, что по его теории во время обычной работы должно происходить постоянное исправление бэдов, невозможное в RAID0. > Ну как бы если кому плевать на свои данные я так то > не против, но когда они при этом начинают высовываться и что-то > про (не)надежность ФС лечить - это не находит моего понимания. Говоришь как тот адепт ZFS. Ветка почти началась с коммента про скорость (второй в ветке, не мой). Дальше говорил о цене фич, о пофайловом сжатии и снапшотах, которые бы добавлялись без компромиссов ("Парето-оптимально"), о шифровании, о чексуммах-для-данных-на-уровне-ФС как приятном бонусе. > > Не находил упоминаний такого софта/железа, которое бы занималось сверкой зеркал/чётности > > при чтении (а не только при ручном запуске проверки). > Ну а вот BTRFS заметив сбой чексумы... Ну так не спорю. Только подтверждаю, что не видел такого. > > Есть dm-dust (бэды, исправляемые перезаписью) и есть error (неисправляемые?), > > zero (использовать как мгновенное тихое повреждение?) в таблице в dmsetup. > И пусть себе есть. Где-то там. Это полезные этажерки, не обижай их. Это эмуляторы особо мерзеньких девайсов.
	Ответить | Правка | Наверх | Cообщить модератору

	516. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (516), 13-Ноя-23, 18:21
	> Эмм, в оперативную память кладут и другие вещи, помимо данных для btrfs > scrub. И они побьются заодно. Ну как бы если у вас оперативка сыпется, конфиг всяко чинить надо и что-то уже могло быть побито. Так что реальное достижение - в основном хайлайт проблем железа. И это фича. > Только контрольной суммы у них не будет. Но перед записью на диск появится, > подсчитанная от уже побитых данных. Теоретические измышлизмы это прекрасно. А вон то - смотрение как это на практике работало. Это было надежнее чем выслушивать опеннетных экспертов, и я по факту видел - вон то. О чем и спел. > Случай с глючной оперативкой (которую можно выявить и иначе) достаточно > очевиден, а халат нужен в разговоре про космически-лучевые soft error'ы. В конечном итоге btrfs там где я его выидел выловил вот проц, пару планок рамы, шнурок и даже чипсет. А какие у вас на все эти случаи планы были кроме теоретических разглагольствований я не понял. Мне вон тот план когда глюкавые компоненты отлавливаются - больше понравился. > Поведай, зачем тогда изобрели RAID-массивы. В них (без доп. data checksumming'а) не > было бы смысла, если бы диск обычно умирал "тихо". В них допущение что диск мрет катастрофично и сразу. По мере роста плотности и скоростей, усугубленных желанием юзерей все и сразу и за копейки, это стало все менее похоже на правду. И таки в обычном RAID на этот случай плана нет. Без чексум будет разрушение данных. ...это дает дизайнам с чексумами преимущество. Если я вижу кейсы где это срабатывает и чинит, своими глазами, о чем вы тут вещаете? > Хотя и так ясно, что изобретатели не интересовались, как это работает и не > имели особого опыта. Когда все начиналось плотности были другие и соотношения - тоже. О том что со временем реалии могут несколько измениться - эксперты, видимо, не в курсе. > На этом держатся все системы без контрольных сумм для данных (без T10-PI, > ZFS, btrfs, ReFS, dm-integrity што там ещё). Они так то довольно специфично держатся. Редко но метко караптя данные - и поскольку чексум нет, как вы это узнаете то если оно изредка? А, ну вот когда что-то осыпется - тогда и :). Только опять же - а откуда вы узнаете кто вас подвел, DMA переписавший что-то в раме или хард вернувший труху? Опосля - уже не видно. А если вот конкретно тут на чтении с конкретного девайса чексум не сошелся - я таки знаю что девайс вернул труху. И могу посмотреть был ли формально IO error заодно. Что я и практикую. > Слова я выбирал, категоричности избегал, дальше мысль раскрыл, исключения описал. А я тут описываю по большей части то что видел лично. Своими глазами. А еще есть следствие из законов Мерфи. "Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили". В случае добра без чексумм это просто квинтэссенция инженерной мудрости. А что до категоричности - если я смотрю на явление своими глазами и мне тут кто-то лечит что не, это не проблема - я несколько не ОК с этим. Если теория не описывает картинку которую я вижу, это хреновая теория, которая должна быть списана в утиль. Тут нет места для компромисса. Теория или стыкуется с практикой, или нет. Для нестыковки хватит 1 конкретного примера. Который я и привел. Вполне себе девайс выдающий левак без IO error. Мой тестовый кролик теперь, ибо весьма подленькая штука отловленная случайно. >> Хлам типа EXT4 вместо этого скорее сбойный сектор будет до упора насиловать > Но что сможет сделать btrfs без избыточности? Он так то метаданные по дефолту DUP раскладывает на 1-дисковых конфигах. Вот как раз из соображений выживаемости и датарекавери. Для данных это ессно надо мануально врубать потому что ополовинит место на девайсе и скорость записи. Но в ряде конфиг с этим можно жить. А сделать аналог этой фичи как-то еще - ну не то что совсем нельзя, но такой гимор и side effects что этим никто заниматься не будет. А тут 1 команду вбить и готово. > ext4-без-массива-под-ней здесь всё-таки как соломенное чучело для спора. А с массивом под ней - соломенное чучело переезжает в менеджмент всей этой пакости. Кода все сложно, хреново, не гибко, плохо поддается динамической реконфигурации. А узнать что именно /dev/sdf выгрузил труху даже не изволив в IO error - да удачи. А чтоб еще это прозрачно парировать в фоне без моего участия...  хм, у меня на основе этой технологии выводки одноплатников, допустим, есть. А вы хоть раз в жизни такой сетап собирали вообще, чтобы рассказать мне как это на практике работать будет? > Можно и патенты Hynix с его miscorrection metric'ами и miscorrection threshold'ами. Лекции CS полезнее - там алгоритмы как они есть, без приукрас. С честной оценкой свойств. А производителей флеша - более одного, технологий тоже. Вон то наблюдение чисто статистическое, я есть в некоторых местах где юзеры с упомянутой траблой иногда рисуются. И у меня есть несколько сыпучек ведущих себя вот именно так. Btrfs пополнил мою коллекцию странной фигни. > Перестараться - это, наверное, некорректное упрощение, но всё-таки у SSD есть возможности > следить за своим здоровьем, свалиться в fail-safe пораньше. На практике как я вижу все это работает не очень хорошо и являет собой полную лотерею. А разложить bcache на ssd это вообще известный способ закончить с разнесенной в хлам файлухой. Но поскольку это дает нефиговую оптимизацию IO - колятся, пищат, но кактус грызут. Глядя на это Кент и интегрировал сабжа с этим на уровне ФС. Так оно имхо сможет менее горбато на факапы SSD реагировать. С чексумами, избыточностью и явным знанием что и где это имеет шансы работать гораздо лучше. > три экземпляра умирали подобным образом и это разочаровывает, исход с тихим > повреждением не должен становиться нормой. Я лично на такие приколы натыкался. Этого достаточно чтобы считать failure mode имеющим место быть. Раскидать btrfs там и тут очень способствовало обнаружению подобных сюрпризов. А как вы это без чексум по простому отловите, интересно? > В 2007 появилась нашумевшая статья* о том, что RAID5 через два года > придёт конец из-за URE=10^-14. Остальные риски для автора не имели значения. Ну как бы некий пойнт автор имел, но как обычно в таких штуках страшилки бывают несколько преувеличены. Однако не учитывать подобные проблемы как и шанс что за время ребилда помрет +1 девайс тоже глупо. Есть некие соотношения, риски, варианты что делать с этим. Если RAID это такой вариант в духе снапшотов, что если что и из бэкапа восстановимся, но намного лучше если прокатит без этого - то и RAID5 некая опция. > Получилось интересное помешательство. В вопросах storage вообще нездоровое количество маркетингового булшита и предрассудковю Поэтому я прежде всего верю своим глазам. Отсюда же и довольно бескомпромиссная реакция на "csum failed без IO Error". Видел такое -> бывает -> маркетинг и теории идут в пень, без компромиссов и дискуссий. И я уже не скажу что не знал что так бывает. Знал и должен учитывать эти данные в принятии решений. > Часть людей поверила в рассказ про RAID5 и URE, > не задумываясь о том, что реальный URE гораздо ниже. Ну это тоже раз на раз не приходится. Воооооон та сыпучка с которой пример - куда злее. Если ее записать, кинуть недельку поваляться и проч - scrub найдет с дюжину рандомных осыпонов. И это факт. Который я могу повертеть в руках. И я не могу сказать что так не бывает, получив столь вопиющий факт в руки. Другое дело что и тут можно проблему классифицировать. Это вероятнее на флешовых устройствах, чем дешевле и low end тем вероятнее такой расклад. Но вообще FEC может быть пробит. Вероятность этого далеко не ноль. На самом деле я просто подружился с FEC до уровня "имлементера" по своим причинам и проинформировал себя о реальных свойствах алго - а не измышлизмах. > типа Toshiba N300 16TB. Что без избыточности (RAID/DUP) такие диски должны > быть не бесполезны, а даже опасны. Что их SMART должен плодоносить ошибками. А таки btrfs по дефолту вернули DUP на SSD. Догадаетесь почему? Повышает выживаемость файлух у юзерей. По крайней мере не дает метаданные урыть - а данные, ну, да, это плохо, но масштаб урона при сносе метаданных куда как. > теории во время обычной работы должно происходить постоянное исправление бэдов, невозможное > в RAID0. Сам стораж вообще не может починить "UNC" - а как? Но если файлуха забьет на эту копию, возьмет из другой, а эту деаллоцирует или перезапишет, проблемный сектор таки более не нужен и получит запись в него - и вот тут уже фирмварь сможет посмтреть читается ли это, и если нет то сделать этому ремап. Без потерь данных. >> про (не)надежность ФС лечить - это не находит моего понимания. > Говоришь как тот адепт ZFS. Ветка почти началась с коммента про скорость > (второй в ветке, не мой). Дальше говорил о цене фич, Ну как бы адепты ZFS были первыми кто это осознал. Просто их звездолет на паровой тяге и гипердрайв с их стимпанк технологиями очень уж сыкотно выглядит. Но даже так они поняли ряд тех вещей которые понял я. > о пофайловом сжатии и снапшотах, которые бы добавлялись без > компромиссов ("Парето-оптимально"), о шифровании, о чексуммах-для-данных- > на-уровне-ФС как приятном бонусе. Можно рассматривать гипердрайв как приятный бонус. Но если я при перспективе расплющиться о твердь смог проскочить через планету и рематеризоваться на другой стороне орбиты одним куском, вбив в последнюю секунду параметры в компьютер, а лох на хвосте так не умел, окей, а вот это уже его проблемы! Главное что это - не у меня. > Ну так не спорю. Только подтверждаю, что не видел такого. Вероятность этого заисит от числа инстансов btrfs, активности их эксплуатации, внимания к системным логам, характера сторажей и много чего еще. Смею заверить что я не уникум, видал немало юзерей с таким добром, чаще всего SSD так прикалывается. > Это полезные этажерки, не обижай их. Это эмуляторы особо мерзеньких девайсов. У меня есть и просто "особо мерзенькие девайсы" :). И кстати если мы про это... * [new tag]                   v6.7-rc1   -> v6.7-rc1 Ну, кто хочет поработать тестовым пилотом? Крейсер в первом приближении свинчен и ждет в доке. Настало время плюхнуться в кресло капитана хотя-бы манекену - и посмотреть что эта штука может. Удачных приключений в гиперпространстве, и добро пожаловать в будущее. Которое создается сегодня :)
	Ответить | Правка | К родителю #514 | Наверх | Cообщить модератору

	520. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (317), 14-Ноя-23, 02:52
	> Теоретические измышлизмы это прекрасно. А вон то - смотрение как это на > практике работало. Это было надежнее чем выслушивать опеннетных экспертов, и я > по факту видел - вон то. О чем и спел. Верну контекст: после отсеивания изначально проблемной памяти можно жить и примерно одинаково страдать от единичных космических лучей что с btrfs, что без btrfs. Тут теорвер btrfs не поможет, единичное повреждение в non-ECC RAM скорее всего заденет не его данные. > В конечном итоге btrfs там где я его выидел выловил вот проц, > пару планок рамы, шнурок и даже чипсет. А какие у вас > на все эти случаи планы были кроме теоретических разглагольствований я не > понял. Но они очевидны, дождаться первых проблем и: память - memtest, SATA-кабель - проверка 0xC7 CRC Error Count в SMART'е, процессор и чипсет - страдать, менять всё с запасом. Ну и организационный момент, конечно - пассивное ожидание kernel panic более фатально, ожидание настроенного уведомления о плохом SMART'е и проблемном scrub'е менее фатально. Если хочется ещё раз провозгласить, что это менее удобно, то я опережу: "это менее удобно". > В них допущение что диск мрет катастрофично и сразу. По мере роста > плотности и скоростей, усугубленных желанием юзерей все и сразу и за > копейки, это стало все менее похоже на правду. Всё-таки там допущение, что диск сообщит об ошибке, не обязательно своей смертью. Не такое уж плохое допущение, ибо скоростей на HDD и так нет, надёжность требуется и юзверям, унификация корпоративных и домашних HDD есть, рост плотности в 10^9 раз за историю HDD остальным аспектам надёжности заметным образом не повредил, поэтому пусть и обнаружению ошибок не повредит. С SSD хуже, да, но там как минимум Samsung'у надо оправдывать ожидания (на 3dnews тихим повреждением отличились Silicon Motion и Phison) и - пожелание в /dev/null - тихое повреждение на SSD не должно становиться нормой. > Если я вижу кейсы где это срабатывает и чинит, своими глазами, о чем вы тут вещаете? О здравом смысле. При высокой частоте тихих ошибок классические RAID-массивы стали бы бесполезными, даже до домохозяек доносили бы мысль через анекдот "печатаю 1200 ударов в минуту, но такая ерунда получается" и они бы смутно помнили, что QNAP почему-то нельзя покупать*. А раз классические RAID-массивы не бесполезны, то ECC обычно хватает и лишний пафос не нужен, чтобы сказать "да, такие делают, в них есть не-ко-то-рый смысл, но я рекомендовать не могу". Оговорки о пользе контрольных сумм были ("из нужного места" => исключение misdirected read/writes, "вызывающих в том числе misdirected read/writes"), а всё хочется видеть, будто я говорю об их бесполезности. И у нас разговор в одном русле идёт: - Есть жизнь и без btrfs/ZFS - Да разве это жизнь!? - Живём как-то. - Да вы не знаете, что такое жизнь! - Но мы живы, вот это вот device mapper, тут par2, а это... - Вы существуете. * Why does QNAP NAS not use the Btrfs file system? https://www.qnap.com/solution/qnap-ext4/en/ > А что до категоричности - если я смотрю... Да-да, то есть нет. Лучше так: - Вы таки утверждаете, что ECC на диске всегда хватает для обнаружения ошибки? - Не всегда, да и проблема не ограничивается miscorrection'ами. > > Ну так не спорю. Только подтверждаю, что не видел такого. > Вероятность этого заисит от числа инстансов btrfs... Аргхм, не видел другого - реализаций RAID, жертвующих скоростью ради чтения всех зеркал/чётности и сверки при каждом обращении к данным. Вот FUSE на основе Рида-Соломона видел, а такое не видел.
	Ответить | Правка | К родителю #516 | Наверх | Cообщить модератору

162. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
Сообщение от Kuromi (ok), 31-Окт-23, 17:29
А вот это интересная новость и правда. Будет очень любопытно пощупать.
Ответить | Правка | Наверх | Cообщить модератору

	212. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (212), 01-Ноя-23, 03:04
	Дома оно нафиг не надо вне серверной среды.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+4 +/–
	Сообщение от Аноним (4), 01-Ноя-23, 06:59
	Выходит, что чел 10 лет бесплатно разрабатывал ФС, чтобы корпорасты могли ее использовать. Чем не куколд?
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:03
	> Выходит, что чел 10 лет бесплатно разрабатывал ФС, чтобы корпорасты могли ее > использовать. Чем не куколд? Тут у одного какого-то Аноним(4) конкретно подгорает что линуксоидам завезли +1 мощную интересную файлуху. Бывает, фигле.
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Анонин (?), 01-Ноя-23, 14:19
	Чел 10 лет занимал тем, что ему нравилось как хобби, а ему за это еще какие-то денежки с патреона капали. А тебе завидно небось?
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	275. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
	Сообщение от OpenEcho (?), 01-Ноя-23, 14:29
	> Чел 10 лет занимал тем, что ему нравилось как хобби, а ему за это еще какие-то денежки с патреона капали. Вообще-то последние 6 лет они спонсировались компанией (которая только в сентябре пошла в экономию)
	Ответить | Правка | Наверх | Cообщить модератору

	276. Скрыто модератором	+/–
	Сообщение от Аноним (4), 01-Ноя-23, 14:50
	Жаль тех, у кого хобби - это пердолинг. И я еще могу понять анастезиолога Кона Коливаса, к примеру, но на работе и дома за компом торчать - это вверх зaдротства.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	283. Скрыто модератором	+/–
	Сообщение от Аноним (283), 01-Ноя-23, 16:11
	> Жаль тех, у кого хобби - это пердолинг. И я еще могу > понять анастезиолога Кона Коливаса, к примеру, но на работе и дома > за компом торчать - это вверх зaдротства. Это ещё что! Кто-то так вообще свои причинные места к асфальту в публичных местах прибивает.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 01-Ноя-23, 17:32
	> Чел 10 лет занимал тем, что ему нравилось как хобби, а ему > за это еще какие-то денежки с патреона капали. я сомневаюсь что стоять на коленках и лизать задницы божкам в lkml - это хобби. А он на это угробил больше года. Ну и денежки, как и следовало ожидать, капали вовсе не с патреона, а сперва - в виде зарплаты в фирмешке, которая в конце-концов заметила что хобби этого чувака мешает закрывать таски вовремя, а потом в виде регулярных взносов еще каких-то ло... обормотов с лишними деньгами, но поскольку они таки оборомоты - деньги у них кончились. А fs еще даже не начиналась, и афтырь уже плачет что жрать ему совсем нечего (а там, оказывается, он еще и очень невовремя подписался второго кормить, поскольку в одиночку нифига не успевал одновременно доделывать и гнаться за stable nonsense). И вот все у вас - так. P.S. вот разница с Шишкиным - что у него во-первых нет такого хобби, на коленях перед миллиардером стоять (а хобби играться с файловыми системами - есть), во-вторых он гуляет на свои. Которые зарабатывает тяжким (вряд ли) трудом на желтоликого господина и менять его не собирается.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	423. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:54
	> И вот все у вас - так. > P.S. вот разница с Шишкиным - что у него во-первых нет такого > хобби, на коленях перед миллиардером стоять (а хобби играться с файловыми > системами - есть), во-вторых он гуляет на свои. Которые зарабатывает тяжким > (вряд ли) трудом на желтоликого господина и менять его не собирается. Ну так и пользуйся продукцией шишкина если для тебя это лучше работает! :) А, у тебя пределом мечтаний виндочка с нтфсом? Ну, кому и кобыла - невеста.
	Ответить | Правка | Наверх | Cообщить модератору

187. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
Сообщение от kusb (?), 31-Окт-23, 20:30
Вот TCP/IP это стек там есть уровни, каждый из которых не очень знает о предыдущих. А файловую систему могут так сделать? Тогда шифрование и какие-то виртуальные особенности были бы просто такими независимыми слоями каждый из которых можно комбинировать с другим.
Ответить | Правка | Наверх | Cообщить модератору

	220. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 03:56
	> Вот TCP/IP это стек там есть уровни, каждый из которых не очень > знает о предыдущих. И на память об этом у нас есть QUIC и HTTP/3 который сейчас как раз дедулю на пенсию и выпишет. По примерно там же причинам - неспособность нормально работать в реальных сетапах имеющих место быть, и малоустранимые проблемы flow control.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
	Сообщение от Аноним (301), 01-Ноя-23, 19:15
	О, раз ты знаешь, как подключить udp congestion control? На tcp вон их тележка. Применять можно по критериям ип-порт откуда и куда. Как в quic с этим дело? Ты же файн сетапер ексайтинг.
	Ответить | Правка | Наверх | Cообщить модератору

	419. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:37
	> О, раз ты знаешь, как подключить udp congestion control? На tcp вон > их тележка. Применять можно по критериям ип-порт откуда и куда. Как > в quic с этим дело? Ты же файн сетапер ексайтинг. А вот там его гугл и подключит так как ему будет удобно - прямо в коде браузера и либ. А ваши кривые лапки там вообще неуместны, имхо. Сколько с TCP congestion flow не сношайся, а нормально работать когда сотовая сеть пропадает в низинке - ну разве что BBR имеет какие-то шансы, и то 50/50. А учитывая что это 2-сторонняя игра, надо чтобы оно на 2 сторонах линка было. Убедить на это какойнить майкрософт не очень получится, особенно чтобы не через 10 лет, ну и в результате юзеры кипишуют и предъявляют гуглу и ютубу за лаги, хотя это не на их стороне. Хороший стимул поработать над "убийцей кубиков" и прочего ископаемого крапа так то.
	Ответить | Правка | Наверх | Cообщить модератору

207. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+1 +/–
Сообщение от jt3k (ok), 01-Ноя-23, 02:06
Звучит супер, будто бы фьюжэн драйв от аппле дветыши десятых годов
Ответить | Правка | Наверх | Cообщить модератору

	211. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от Аноним (212), 01-Ноя-23, 03:03
	С разморозкой. Фьюжн драйв ставили  в аймаки почти до 2020 года.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:02
	> Звучит супер, будто бы фьюжэн драйв от аппле дветыши десятых годов Даже попродвинутее - с учетом избыточности и запрошенной схемы аллокации и знанием что и где место использует. В общем идея весьма даже интересная.
	Ответить | Правка | К родителю #207 | Наверх | Cообщить модератору

223. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+2 +/–
Сообщение от Макс (??), 01-Ноя-23, 05:09
Я давно перешёл на BTRFS. У меня 2 SSD (по 1ТБ) в RAID0 для скорости, под ОС и рабочие файлы. И 2 HDD (по 12ТБ), где половина от каждого диска в RAID1 для всего ценного и вторая половина в RAID0 для торрентов, временных виртуалок и т.п. Мне эта ОС очень интересна. ОС и рабочие файлы разместил бы на HDD в RAID1, а SSD как кэш. Как будет доступно, буду изучать.
Ответить | Правка | Наверх | Cообщить модератору

	253. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (253), 01-Ноя-23, 09:29
	Ты частенько забываешь перед сном скопировать файлы из одной папки в другую. Сперва выработай эту привычку, а потом уже остальное.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 01-Ноя-23, 10:00
	> Ты частенько забываешь перед сном скопировать файлы из одной папки в другую. > Сперва выработай эту привычку, а потом уже остальное. Линуксоиды интересующиеся продвинутыми технологиями обычно в состоянии скриптануть повторябщиеся операции...
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от _kp (ok), 01-Ноя-23, 12:04
	Могут. Только скрипт не может узнать когда же я спать лягу. ;) А так, очевидное решение, без всяких ФС,это держать рабочие файлы на ssd, а на hdd репозитории(и изменения попадут на hdd при фиксации), там же бэкапы, "файл помойки", фото, музыку и видео. А обсуждаемая ФС - это больше серверное решение для предоставления доступа к файлам большому количеству пользователей, а не ради пары жестких дисков.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от OpenEcho (?), 01-Ноя-23, 14:20
	> Только скрипт не может узнать когда же я спать лягу. ;) А ZFS снэпшатам пофиг, спит пациент или нет
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 06:39
	серверные решения в виде одного сервера нынче немодны ну вот совсем. Т.е. это получится решение для совсем уж унылых васянов-самоучек без мотора, в подвале. Каковым на первый и второй взгляды на самом-то деле и выходит. (и да, s2d умеет в layered. Правда, лучше запастись бэкапом. Забавно, но моднявый ceph - не умеет? крашмап у него един на веки веков, а какой-то встроенной промежуточной системы нет)
	Ответить | Правка | К родителю #268 | Наверх | Cообщить модератору

	420. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:47
	> Могут. Только скрипт не может узнать когда же я спать лягу. ;) Можно таки сделать детект idle пользака. Как вариант пулять вместе с скринлокером, или по его наличию например. > А так, очевидное решение, без всяких ФС,это держать рабочие файлы на ssd, > а на hdd репозитории(и изменения попадут на hdd при фиксации), там > же бэкапы, "файл помойки", фото, музыку и видео. Есть 1 нюансик: одно дело если микроменеджмент спихан на машину и совсем другое если на меня. Вот btrfs прекрасен тем что им рулить намного прикольнее и ненапряжнее. И сабж следует многим идеям оттуда, большая часть этого и для него верна. Зачем мне система с сложным, долбучим, канительным менеджментом засоряющим мой мозг? Компьютеры должны решать проблемы а не создавать их. > А обсуждаемая ФС - это больше серверное решение для предоставления доступа к > файлам большому количеству пользователей, а не ради пары жестких дисков. Кент прямым текстом сказал что он хочет быть универсальным решением. Btrfs тоже довольно универсальная штука, я успешно юзал ее от многодисковых хранилок до мелких одноплатников и даже роутеров-мыльниц.
	Ответить | Правка | К родителю #268 | Наверх | Cообщить модератору

272. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
Сообщение от OpenEcho (?), 01-Ноя-23, 14:17
Интересная ситуация, компания спонсировавшая проект последние 6 лет отвалилась, но проект при этом включен в кор ветку линукса https://www.patreon.com/posts/your-irregular-89670830
Ответить | Правка | Наверх | Cообщить модератору

	289. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+3 +/–
	Сообщение от пох. (?), 01-Ноя-23, 17:12
	хахаха! The company that's been funding bcachefs for the past 6 years has, unfortunately, been hit by a business downturn - they've been affected by the strikes in the media production industry. As such, I'm now having to look for new funding. вот такие мы независимые и шва6одные художники. Если в ближайшее время не найдется кого-то кому зачем-то и НАСТОЛЬКО нужна недоделанная фс чтоб платить зарплату сразу двум разработчикам - ее ждет судьба в лучшем случае - btrfs. Вечный недоделок с вечными глюками. Ну а в наиболее вероятном - просто полетит в помойку из-за отсутствия желающих (и могущих) поддерживать бесконечную гонку за механическим зайцем спонсируемым корпорациями.
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Макс (??), 02-Ноя-23, 06:01
	Ну и замечательно. Если она действительно кому-то нужна, то спонсоры найдутся. Для Гугла это копейки, а экономия может быть существенная, если найдётся применение. Как говорится — рынок порешает.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от пох. (?), 02-Ноя-23, 06:33
	Не, чувак, это ТАК не работает. Мне вот много чего нужно, но не хватит бабла всех спонсировать, а за некоторые виды спонсорства еще и 25 лет могут впаять. А гуглу оно вот точно не надо, неужели ты думаешь что он свои зетабайты складывает на локальные fs? И делиться своими поделками гугл не любит - потому что как раз там не работают любители годами на коленях стоять и за шта6ильными нонсенсами вечно гнаться.
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 02-Ноя-23, 14:37
	Для гугла она не нужна, там своих специализированных ФС хватает. А эта вполне была бы хороша для обычного десктопа в связке с HDD + SSD для ускорения
	Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

	376. "Код Bcachefs принят в основной состав ядра Linux 6.7"	–1 +/–
	Сообщение от пох. (?), 02-Ноя-23, 16:13
	> Для гугла она не нужна, там своих специализированных ФС хватает. А эта > вполне была бы хороша для обычного десктопа в связке с HDD > + SSD для ускорения чтоб навернулись все данные сразу. Угу. Отличное ускорение - раз, и в помойку.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 02-Ноя-23, 18:11
	Здесь можно использовать SSD только как кеш с обязательным сохранением данных на надёжном носителе.  Т.е. пишешь всегда на HDD + докатывается на SSD, читать можно только с SSD что даёт ускорение. Можно включить контрольнрые суммы. Все данные здесь могут навернуться разве что из-за нестабильности кода, пототому пока что нужно ждать обкатки если не хочется сюрпризов.
	Ответить | Правка | Наверх | Cообщить модератору

	421. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 03-Ноя-23, 14:50
	>> вполне была бы хороша для обычного десктопа в связке с HDD >> + SSD для ускорения > чтоб навернулись все данные сразу. Угу. > Отличное ускорение - раз, и в помойку. Там ващет избыточность на этот случай есть. А вот в более классических вариантах с чем-то типа bcache оно норовит вызвать "запроектные" аварии в файлухах подпертых SSD вот так. Что как бы грабли.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

	336. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Макс (??), 02-Ноя-23, 06:04
	Очевидно, что кто-то спонсировал. Всем надо кушать.
	Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

484. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от bOOster (ok), 07-Ноя-23, 07:36
Как только читаю, для сложной ФС - "демонстрирует скорость работы, близкую к Ext4 и XFS" тут же вспоминаю проблемы с уязвимостями процессоров, и падение производительности при их решении...
Ответить | Правка | Наверх | Cообщить модератору

488. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от Аноним (488), 08-Ноя-23, 11:28
Пробовал Bcache, особых плюсов не увидел, но при внезапном отключении питания проблемы обеспечены.
Ответить | Правка | Наверх | Cообщить модератору

	500. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
	Сообщение от Аноним (-), 10-Ноя-23, 15:14
	> Пробовал Bcache, особых плюсов не увидел, но при внезапном отключении питания проблемы > обеспечены. Плюсы - в производительности того что получится. Ессно только после прогрева кешей. Но да, может вызвать нехилые запроектные разрушения в любой ФС если кеш дуба дал. Один из аргументов за bcachefs - лучший контроль над живость кеша vs избыточность (схема хранения). Когда кеш блочный, взаимодействия с ФС довольно так себе получаются.
	Ответить | Правка | Наверх | Cообщить модератору

523. "Код Bcachefs принят в основной состав ядра Linux 6.7"	+/–
Сообщение от _kp (ok), 18-Мрт-24, 20:14
Фальстарт. 14 дней недотерпели. А уже на bcachefs.org написали - "особое внимание уделяется надежности и надежности"
Ответить | Правка | Наверх | Cообщить модератору

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

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