Debian переходит к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру

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

Тут есть очевидная обратная сторона. Например мы сохраняем какой нибудь файл в каком нибудь редакторе и вынуждены сидеть и ждать пока он физически запшется. А ведь можно было бы продолжить работу так, как будто всё произошло мгновенно.

Так что dirty pages это плохо скорее для сервера и встраиваемой техники, а вот на десктопе лучше наконец то приучить пользователей не дёргать флешки.

third-party ПО

Все остальные классификации не особо осмысленны.

Почему термин не может одновременно означать и «selected element of the array», и присвоенный ему номер?

Полагаю, задумка там была такая.

Да не было там задумки. Просто программист поленился переходить с С на английский язык.

Есть список, каталог, реестр (англ. index) файлов.

index с английского это буквально «указатель имён», как в словарях или в конце книг. Реестр - registry. Каталог - directory. Список - list.

Почему термин не может одновременно означать и «selected element of the array», и присвоенный ему номер?

В теории может, но после того как волапюк с «индой» вошёл в моду, для номера стали использовать отдельный темрин - inode number. Чтобы собственно отличить номер от узла. Это, кстати, характерный пример развития лексики в этой нашей ITшечке - вместо исправления косяка рождается «масло маслянное» как самостоятельный термин.

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

На самом деле это одна из тех вещей, которые в винде сделаны правильно. Кэширование записи по-умолчанию отключено для внешних накопителей. И можно вручную контролировать для нужных дисков в известном окошке.

Линукс тоже прекрасно отличает внешние диски, и наверное подобное можно для себя провернуть скажем через udev rules, но я нигде не видел подобного из коробки.

Пытаться отучить пользователей дергать флешки довольно бесполезная затея

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

в зависимости от того как спаяна у нас кнопка 0/1 на блоке питания 🥸 мб мне ещё wi-fi и монитор на ночь не выдёргивать из розетки?)

отучить выключать компьютер выдёргиванием вилки из розетки.

Так они так и не отключают никогда. Они просто кнопку «питание» жмут на корпусе. И индустрии пришлось подстроится под их поведение. Мы больше не видим вот такого.

Error 1011

Что с тобой не так?

Это вообще не относится к обсуждаемому вопросу. Раньше компьютеры просто не умели отключать питание программно через ACPI, а потом научились.

Подстраиваться под абсолютно все тупые привычки пользователей совершенно незачем, ибо такие пользователи хотят лишь более быструю лошадь вторую винду.

При этом против реализации аналога опции монтирования flush для всех ФС ничего не имею. Однако это имеет и негативное влияние на скорость работы с накопителем, и если буферизация записи на небольшую флешку и правда особой выгоды не несёт, то какой-нибудь переносной SSD, непосредственно с которого пользователи могут работать весь день, замедлять принудительно синхронным вводом/выводом как-то не очень.

Кстати в сценарии подключения внешнего диска к лэптопу я бы вдвойне был параноидальным. Так как плохой контакт на разъеме юсб и банально случайное выдергивание во время движения там очень частое явление.

В любом случае, если кому-то нужно такое правило для udev, то вот:

ACTION=="add", SUBSYSTEM=="block", ATTR{removable}=="1", ATTR{queue/write_cache}="write through"

Только внимательно. Если например в биосе для дисков включен SATA Hotplug, то внутренние диски будут трактоваться как removable, и соответственно правило к ним применится тоже.

Это вообще не относится к обсуждаемому вопросу.

Ну, как не относится…

Раньше компьютеры просто не умели отключать питание программно через ACPI,

А люди^W пользователи всё равно жали на кнопку «питание».

а потом научились.

Почему научились-то?

У вас в /var/run и /run разрешена запись для всех пользователей?

Ыы не поверите, но один проф. электрик именно так светильники и подключил — фаза жёлто-зелёным, земля коричневым, синий болтается в воздухе. Это было лет 20 назад, и, думаю в той комнате они до сих пор так и подключены.

В случае ссд/tmpfs крайне сложный вопрос что есть разумная экономия.

Это уже решает каждый пользователь для себя. Не даром же профили браузеров выносят на тмпфс, например.

index с английского это буквально «указатель имён», как в словарях или в конце книг. Реестр - registry. Каталог - directory. Список - list.

index — a list of names or topics
Соответственно мы и имеем list of files (in directory).

index.html можно еще вспомнить. Короче, index тут прям это и значит. Чем больше думаю, тем больше мне все становится понятным и логичным.

То есть достаточно прописать в cron еженедельный запуск rkhunter и всё :)

Интересно. То есть уже на той первой машине в /usr были системные файлы в дополнение к user директориям.

С чего ты это взял? Пока место на первом диске не закончилось ничего системного в /usr не писали. То есть была вполне себе логичная иерархия файловой системы, пока не начали решать проблему нехватки места костылями. С тех пор UNIX оброс гораздо большей массой костылей. При этом второй и третий диски были точно такими же, как и первый и можно было бы сделать RAID. Но костыль оказался дешевле и сердитее.

В чужом скрите? Запускаем левую писанину и смотрим как она творит что то не то?

Ну ты сейчас буквально описал весь лялекс лол! Мы тут всем форумом уже почти 30 лет запускаем левую писанину и смотрим, как она творит что-то не то.

Хотя нет, это буквально описание всего мать его IT!

Потому что твоему могучему интелекту должно быть известно, что самый говённый ссд один хрен превосходит твой рейд как по линейным скоростям, так и по иопсам

Ичо? А зачем своп-то нужен?

А у тебя нет? Сходи-ка в /run/user/$(id -u)!

index — a list of names or topics

Не обрезай, не будь этим самым:

a list of names or topics that are referred to in a book, etc., usually arranged at the end of a book in alphabetical order

По-русски, это называется «указатель» (не в значении языка программирования, а в человеческом).

index.html можно еще вспомнить.

Можно. Это как раз оно по задумке - алфавитный указатель на все страницы в текущей директории.

Разумеется нет. У меня нет лишних каталогов. Но что за манера, отвечать вопросом на вопрос. В /run/user/$(id -u) тоже не разреншено писать всем подряд, это точка монтирования с правами mode=700.

Взаимодействие между процессами от разных UID?

Взаимодействие между процессами от разных UID?

Как ты себе это представляешь? Тут либо разные процессы изначально запускаются от разных UID, но это очень странная задача, в которой они должны обмениваться данными через файлы, когда есть сеть и сокеты. Либо они запускаются одним родителем, но тогда у родителя должны быть права root, и это всё вообще перестаёт быть проблемой.

Как ты себе это представляешь?

Я не он, но один процесс запускается от рута, форкается, меняет uid и работает от пользователя.

они должны обмениваться данными через файлы, когда есть сеть и сокеты.

Сокеты в нашем дорогом linux’е - обычно тоже файлы. А в BSD допускаю, что вообще без файла создать нельзя.

Я не он, но один процесс запускается от рута, форкается, меняет uid и работает от пользователя.

Ага. А где тут несколько разных UID?

Сокеты в нашем дорогом linux’е - обычно тоже файлы.

Нет.

А в BSD допускаю, что вообще без файла создать нельзя.

Кого волнует BSD сейчас? Но я верю, когда-нибудь и они смогут сделать abstract unix socket.

https://lists.freebsd.org/archives/freebsd-hackers/2021-December/000609.html

один процесс запускается от рута, форкается, меняет uid и работает от пользователя.

Ага. А где тут несколько разных UID?

Один - рута, другой - пользователя. Что не так?

Кого волнует BSD сейчас?

Авторов опенсурсного софта.

Ну и да, если сокет создать без файла - не будут, естественно, работать права доступа на файл.

один процесс запускается от рута, форкается, меняет uid и работает от пользователя.

Ага. А где тут несколько разных UID?

Один - рута, другой - пользователя. Что не так?

Вообще, для таких сценариев есть socketpair(). А ещё можно pipe() сделать пару раз. В публичный доступ надо класть сокет только чтобы к нему мог подключиться кто-то со стороны.

Авторов опенсурсного софта.

Их уже, судя по всему, FreeBSD давно не волнует как раз.

Процессы исходно запускаются от разных юзеров, допустим из-за iptables, маршрутизации или ещё чего. Один себе работает, создаёт pid-файл, какие-то (заранее известно какие) временные файлы. Другой (от другого UID) за этим присматривает, что тот процесс не умер, что он уже столько-то выполнил (по размеру файлов или ещё что). Если в /tmp, то там всё доступно, если в /run/user/ID, то там даже не посмотреть список файлов.

и сокеты

И для коннекта к unix-сокету нужен доступ к файлу.

Процессы исходно запускаются от разных юзеров, допустим из-за iptables, маршрутизации или ещё чего. Один себе работает, создаёт pid-файл, какие-то (заранее известно какие) временные файлы. Другой (от другого UID) за этим присматривает, что тот процесс не умер, что он уже столько-то выполнил (по размеру файлов или ещё что). Если в /tmp, то там всё доступно, если в /run/user/ID, то там даже не посмотреть список файлов.

Очень странный сценарий, которого я никогда не видел на практике. Но для такого в /run создаётся директория с владельцем root:somegroup и правами 775, а нужные юзеры добавляются в эту группу. Всё, проблема решена. Устраивать бардак в /tmp совсем не обязательно.

И для коннекта к unix-сокету нужен доступ к файлу.

Или нет.

Вообще, для таких сценариев есть

Для сценариев отец-родитель много чего есть, но цепочка форков может быть длинее и заковыристей. Наконец, процесс, подключающийся к сокету, может быть вообще из совсем другого проекта, чей код никто не будет трогать.

Их уже, судя по всему, FreeBSD давно не волнует как раз.

Ах, если бы.

Для сценариев отец-родитель много чего есть, но цепочка форков может быть длинее и заковыристей. Наконец, процесс, подключающийся к сокету, может быть вообще из совсем другого проекта, чей код никто не будет трогать.

Да-да, фантазия может быть безграничной. Я вот сейчас могу такое безумие придумать, что мама не горюй!

Да-да, фантазия может быть безграничной.

Реальность может быть куда более безграничной, чем фантазия. xrdp работает по описанной мною схеме - пара демонов, форки, сношаются через файлы сокета, к котрым подключаются после форка, создают свой сокет для pcscd-клиентов, которых пишут совсем не они.

Да ещё и в коде есть потуги работать на BSD и даже венде - в общем, полный комплект моих «фантазий».

Для такого проще уж вобще создать отдельный каталог где-то подальше от /run и /tmp, чтобы всякие обновления ничего не ломали. Но это при условии, что тебе вобще кто-то что-то будет создавать, а не — дали две учётки на сервере и работай.

Я знаю про abstract socket namespace, но зачем было писать:

софт делает сокеты и в /tmp. ... Но канонично для этого есть директории /var/run и /run

Сразу бы и писали, «долой сокет-файлы, все в абстрактные сокеты». Ибо сокет-файлы, что в /run/user/ID, что в /home/USER, одинаково доступны только для процессов этого юзера и не могут взаимодействовать с другими пользователями.

Но это при условии, что тебе вобще кто-то что-то будет создавать, а не — дали две учётки на сервере и работай.

Да-да, а ещё могут поставить взвод автоматчиков и заставить всё делать в /tmp. Тут без /tmp не обойтись!

Сразу бы и писали, «долой сокет-файлы, все в абстрактные сокеты». Ибо сокет-файлы, что в /run/user/ID, что в /home/USER, одинаково доступны только для процессов этого юзера и не могут взаимодействовать с другими пользователями.

Да нет, можно прямо на localhost прицепиться. Тоже сразу решает все проблемы.

Все же хочется видеть настоящий прогресс копирования во время копирования.

Но это всё таки гарантирует тормоза в работе! Буквально откатимся во времена ХР и Висты, а CoW-ФС вообще будут тупить почище 12309 если действие юзера упадёт на сборку мусора.

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

И поэтому работа с флешками в винде особо тормозная. Но дёргать флешку один хрен нельзя, винда сама приучает пользователей извлекать их правильно, но даже это всё в сумме не спасает от юзерских «я копировал, но файл не записался...», так что эта битва тоже проиграна.

З.Ы. Кстати, можно пойти компромисным путём. У файлменеджеров есть окошко операции копирования и вот конкретно для этого окошка можно после копирования сделать sync и чтобы оно не закрывалось пока он не выполнится. А весь другой софт пусть не тормозит.

ls -U это вывод в порядке как записано в директории, к инодам отношения не имеет.

Это никакая не «ссылка». Файл директории содержит табличку как тебе показал @noc101, где каждому имени файла сопоставлено целое число - индекс файла в табличке файлов.

Открой теперь толковый словарь для ИТ и узнай что такое ссылка. Одностороннее сопоставление имя -> индекс в данном контексте и есть ссылка в самом прямом смысле этого слова. Имя - вот оно тут, а полезная его нагрузка где-то в другом месте (в иноде), и мы на неё ссылаемся.

Так она и есть отдельная. У нас есть сам файл (инода) - с метаданными и содержимым, и есть, отдельно, одно или несколько имён, на него ведущих. Инода расположена в таблице инод, имена - в таблицах имён, которые называются директориями. При желании можно создать файл без имён или имя без файла, т.е. такое которое ведёт на пустую иноду (битую ссылку, fsck исправит).

Где inode, очевидно int, который индекс к node.

Нормальные люди так переменные не называют. Во-первых, прилагательное обычно идёт перед существительным: node_index, node_i, nodei. Во-вторых, если тебе всё-таки приспичило сунуть его после существительного, то сделай хотя бы что-нить типа iNode чтоб было видно где оно начинается.

Впрочем, авторы того драйвера фс были нормальными и так и сделали: прилагательное («i») в начале, существительное («node») - после.

Остаётся надеяться, что когда-нибудь в светлом будущем весь этот волапюк исчезнет, вслед за файловыми системами, где количество файлов может быть ограниченно каким-то случайным номером, и нельзя создать новый файл при свободном месте на файловой системе.

От inode number-ов то ты может и избавишься, а вот сами иноды никуда не денутся, если хочешь адекватную поддержку хардлинков.

wifi надо выдернуть раз и навсегда, а зачем трогать монитор я не знаю. Я свой отключаю только если его надо куда-то переставить куда провод не дотягивается (редко). Подсветку матрицы он сам отключает если нет видеосигнала, а видеосигнал гасится компом через полчаса неактивности.

А ноль не подключил?

Я вот так же проводку по квартире например проложил (только с нулём, конечно - его на синий). Про стандарты узнал потом и переделывать уже не стал. А логика тут вполне простая: земля и фаза на самое близкое к цветам, принятым в компьютерном питании, ну а ноль на тот что остался.

можно было бы сделать RAID. Но костыль оказался дешевле и сердитее.

А я в очередной раз сообщу, что RAID0 делать нельзя кроме совсем крайней нужды, и ручное раскидывание файлов по дискам лучше по всем параметрам (надёжность - всегда, скорость - в подавляющем большинстве случаев). Впрочем в те времена рейдов может быть и вообще не было.

Кого волнует BSD сейчас? Но я верю, когда-нибудь и они смогут сделать abstract unix socket.

Вот смотри, есть стандартный и гибкий инструмент unix socket, который автоматически учитывает unix-права доступа, chroot-ы и всяческие операции над файловой системой. Ты предлагаешь сломать весь этот функционал и, не осилив навести назад порядок с unix-правами, внедрить вместо него какую-то стороннюю обрезанную чушь (эти твои абстрактные сокеты). Плохо так делать.

Свопа нет вообще последние лет 10, так как имеющиеся машины имеют от 16 ГБ оперативы.

лол, на старой домашней системе 32ГБ памяти, 32ГБ свопа временами не хватало, увеличил до 128

Ну так эти nodes тоже ссылаются на блоки с данными.

О, так даже в Википедии все четко написано со ссылкой на слова Ритчи.

A 1978 paper by Ritchie and Ken Thompson bolsters the notion of «index» being the etymological origin of inodes. They wrote:[5]

[…] a directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for index number) of the file. When the file is accessed, its i-number is used as an index into a system table (the i-list) stored in a known part of the device on which the directory resides. The entry found thereby (the file's i-node) contains the description of the file.

Само число часто называют inode по той же причине, что и у нас говорят «список учеников» вместо правильного «список имен учеников», «дай мне Валеру» вместо «дай мне номер Валеры» и т. д. В просторечии мы постоянно «ссылку» на предмет называем именем этого самого предмета.

Ты меня не понял.

Запись в файле директории это не отдельная сущность, это запись в файле директории.

Ссылка это отдельная сущность

Типа есть Инода, Файл директории и Ссылка.

Но есть только Инода и Файл директории. А ссылки нет.

И что это даст?

Ты какую-то ерунду написал. С тем же успехом можно сказать что инода это не отдельная сущность, а только запись в таблице инод.