На Intel?

Не, я про файлуху спрашивал. А так надо вначале доломать как-то этот кудахтер. Он меня бесит.

и zfs

К сожалению, XFS себя так до сих пор ведёт. Смирись с тем, что в Линуксе, как бы это печально ни звучало, нормальных ФС нет, а те, что есть, в ядро не приняты до сих пор.

Intel+ext4. Брат жив.

Но это же уровень Windows 95 так файл прокакать. Рассказали бы мне - не поверил.

Увы.

А ты вообще уверен, что тут ФС виновата? Надо смотреть чем и как ты писал этот файлик. Правильный способ записи в существующий файл должен выглядеть так:

• Создаётся новый файл на том же устройстве.
• В этот новый файл пишутся новые данные.
• Новый файл закрывается.
• Новый файл атомарно перемещается на имя уже существующего старого файла.

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

Ты где был, когда ФС выбирал? Про это знает почти любой линуксоид лет 15 как.

Неуловимый джо

а те, что есть, в ядро не приняты до сих пор

Эти ФС такие замечательные только потому, что их никто не видел и никто не использует 8).

А ты вообще уверен, что тут ФС виновата?

Нет, наверное.

Надо смотреть чем и как ты писал этот файлик.

gpg-ом я его писал, используя https://github.com/jamessan/vim-gnupg. gpg по идее не должен быть совсем рукожопами написан, плагин для вима я тоже весь предварительно изучил и меня увиденное устроило.

Xfs в рхеле по дефолту.

За меня Red Hat выбрал. Мне некогда трахаться с выбором, я живу активной полноц^W а хотя проехали.

Это вообще нормально почти в 2017 файл на крэще обнулять?

Лет 10, как с этим на XFS перестал сталкиваться. Скорее всего, это что-то единичное. Типа, как у меня на ext4 несколько раз файлы просто пропадали.

gpg-ом я его писал, используя https://github.com/jamessan/vim-gnupg. gpg по идее не должен быть совсем рукожопами написан, плагин для вима я тоже весь предварительно изучил и меня увиденное устроило.

Надо смотреть как именно это всё реализовано.

Не в тему: проблема не в AMD, а в плохой материнке.

Да gpg (внешний процесс) просто с ключами вызывает. А ваша идея в том что мне vim файлик угробил, а не xfs, правильно?

Естественно, если после открытия на запись и перед записью случится что-то плохое, то старые данные будут утеряны, а новые ещё не будут записаны.

А журналирование и транзакции для чего?

Типа, как у меня на ext4 несколько раз файлы просто пропадали

во, удваиваю. Думал это у меня что-то с железом.

А журналирование и транзакции для чего?

А что журналирование? Если юзерспейсный код сам «обнулил» файл (вызовом open() с O_TRUNC), то это «обнуление» запишется в журнал и потом успешно отреплеится. И это будет совершенно верное поведение, так как проблема не в ФС, а в логике работы приложения.

после таких приколов и посмотрел в сторону xfs, да потом и перешел

Интересно, когда у меня после креша системы во время апдейта половина либ в /usr/lib нулевого размера — это тоже не проблема ФС? Куда баг репортить, девелоперам tar'a?

Линуксе, как бы это печально ни звучало, нормальных ФС нет

Лови Ext4! NTFS на винде так же не блещет. Ext4 довольно стабильна, те кто от нее ушел ССЗБ и знают что делают т.е. готовы нести все тяготы и невзгоды от своих экспериментов.

после креша системы во время апдейта половина либ в /usr/lib нулевого размера

А чего ты вообще хотел «после креша системы во время апдейта»? Ну хорошо, могло быть «половина либ старых, половина либ новых». Сильно лучше?

А вообще да, баг репортить авторам ПМ. Идеальный ПМ сначала просчитывает транзакцию и пишет в файл, потом fsync, потом всё распаковывает с суффиксами на ту же ФС, опять fsync, а потом пачкой unlink()+rename() (в идеале renameat2(RENAME_EXCHANGE), но его завезли совсем недавно и мало кто умеет). Последний шаг при необходимости повторяется после перезагрузки из initramfs по записанному в файл плану транзакции.

никогда больше не буду покупать AMD, и компьютер постоянно барахлит

У меня жир с монитора потёк.

Не гони. XFS зануляет «недоделанные» блоки (заполняет нулями), но никогда не truncate'их

XFS зануляет «недоделанные» блоки (заполняет нулями)

Зачем? Чтобы уж наверняка не прочиталось?

Идеальный ПМ сначала [...]

Это yum что-ли? Тогда понятно почему так тормозит.

У меня жир с монитора потёк.

Это у вас пластик расплавился.

Это у вас пластик расплавился.

Пластик жеж не из жира делають.

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

тут много над этим смеялись пока один местный клоун не увидел в своем файле на ext4 содержимое из давно стертых файлов.

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

пока

Ну пока.

Чини себя.

Окружающее железо обычно является показателем своего хозяина. Если хозяин болен, то и железо не в порядке.

А ежели доктор сыт, оно и больному легче. Ага.

я думаю, это вим с плагином шифровальщиком. Он наверняка в памяти держит зашифрованный буфер, а скидывает в последний момент. Но при этом открывает с файл с truncate. Надо бы strace натравить, да поглядеть, какие там open() происходят

да. для безопасности.

4.2

Зачем strace, там копеечный плагин, я его просто прочитал. На чтение буфера дёргается gpg --decrypt, на запись буфера gpg --encrypt с указанием реципиентов. Расшифрованные данные передаются через временный файл. Есть настройка передавать через пайпы.

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

причём здесь ядро? причём здесь амудэ? опции в фстаб какие?

Я и не разлогинивался. UPS не нужен, у меня сам компьютер кривой и выключается, вот.

Не гони. XFS зануляет «недоделанные» блоки (заполняет нулями), но никогда не truncate'их

круто она их зануляет, пачками кластеров, что ли?

defaults раз два! (так и написано)

/dev/mapper/cl-home /home xfs defaults 1 2

причём здесь ядро?

Я так думаю в шапочном ядре более лудший XFS, чем в ванильном. Чтобы это выяснить я даже сходил в магвазин за пивом квасом и рыбой, но ещё не открыл.

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

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

Нет, я не знаю, как это делает yum/dnf, и не намекал на то, что это идеальный ПМ.

Я так думаю в шапочном ядре более лудший XFS, чем в ванильном.

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

На самом деле ваш случай известное поведение xfs и многих других фс. Во время записи на диск ваш файлик не дописался и произошел откат транзакции (у xfs буфер записи не сбрасывается регулярно как у ext4)

Здесь подробнее http://www.linuxcenter.ru/lib/articles/system/jfs.phtml?style=print

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

еще одно доказательство что xfs доверять нельзя.
соболезную.

Купи новый, у меня тоже были подобные проблемы с материнкой. Ну или купи новую мать, если твой еще относительно не старый.

доказательство что xfs доверять нельзя

мда... как плохо, что детям нынче не преподают логику.