LINUX.ORG.RU
Форум — Talks  

Ext4 такая ext4


0

3

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

★★★★

Последнее исправление: aptyp (всего исправлений: 1)
← Ваш путь в терминале
Теперь не отвертитесь →
 ← 1 2 3 4 5 6 7 8
Ответ на: комментарий от Lavos

Вырубился из-за того, что зарядка кончилась. Другие фс не юзал, но то, что файлы стали пустыми, удивило. Сама то система нормально загрузилась и всё работает, fsck диск проверило, что-то там исправило.

aptyp ★★★★
() автор топика
Ответ на: комментарий от Deleted

А с хрена ли такое поведение? Никакие файлы (которые внезапно стали пустыми) не были открыты, только в этой же директории бинарник был запущен, вот и всё.

aptyp ★★★★
() автор топика
Ответ на: комментарий от Homura_Akemi

Да. Надо будет всё-таки настроить уведомление)

aptyp ★★★★
() автор топика
Ответ на: комментарий от Homura_Akemi 
arthur@localhost:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=212617,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=393712k,mode=755)
/dev/disk/by-uuid/2df64c86-d83f-4dba-800d-699a1b3bb259 on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1577320k)
/dev/sda2 on /home type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

Для /home рекомендую прописать в fstab «data=journal». Производительность снизится, надёжность повысится. Также советую не играться со всякими vm.dirty_writeback_centisecs и commit=100500, если есть вероятность внезапного отключения.

Homura_Akemi ★
()

гитовские файлы тоже покорёжило, как и один документ libreoffice

Это больше напоминает сбой диска, нежели ФС.

Homura_Akemi ★
()

Сохранность данных тебе не может гарантировать ни одна ФС. Гарантируется только целостность самой ФС, что не одно и то же.

post-factum ★★★★★
()
Ответ на: комментарий от nu11

ну и кто тебе гарантировал целостность данных?

вопрос в том почему они резко стали пустыми если в них, по намёкам ТС, записи не было.

true_admin ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Хрена с два это дефолт.

близко к дефолту. Главное опции журналирования.

true_admin ★★★★★
()
Ответ на: комментарий от post-factum

ТС в реальном времени следит за содержимым всех структур ФС?

не надо следить за всеми структурами. И не надо сводить беседу к «сам дурак». Речь сейчас о том что влияет на сохранность данных и почему.

true_admin ★★★★★
()
Ответ на: комментарий от post-factum

Сохранность данных тебе не может гарантировать ни одна ФС.

В определенных пределах - должна бы гарантировать, иначе от «целостности самой ФС» толку столько же, сколько от козла молока.

Manhunt ★★★★★
()
Ответ на: комментарий от daemonpnz

Нет, используемые мною ФС не деградируют со временем без причин :)))

Homura_Akemi ★
()
Ответ на: комментарий от Manhunt

С data=journal в определённых пределах гарантирует, но такое умолчание слишком сурово для большинства. Возможно, nodellaloc окажется приемлемым компромиссом между ordered и journal, но опять же не задаром.

Homura_Akemi ★
()
Ответ на: комментарий от Homura_Akemi

Я полюбил эту ФС как раз за эту опцию :) Сколько радостных часов я провел созерцая ребилд на еле живом венике.

Jetty ★★★★★
()
Ответ на: комментарий от daemonpnz

Использовал во времена 2.4. Какой только феерии я не наблюдал на reiserfs. Было всё, начиная от неудаляемых файлов и заканчивая директрий ls в которых приводил в kernel panic.

Reset ★★★★★
()
Ответ на: комментарий от pekmop1024

С тех пор, когда нтфс стала самой устойчивой фс к внезапным блэкаутам.

QNX6FS смотрит на неё, как на корявую пионерскую поделку.

kranky ★★★★★
()

вырубился внезапно ноутбук

Это какой же надо обладать кармой, чтобы так облажаться. Заряд батарейки что, никак не виден?

red_eyed_peguin ★
()
Ответ на: комментарий от post-factum

Не должна, потому что это задача бекапов, например.

Сама по себе ФС легко приводится в консистентное состояние командой mkfs. Это самый быстрый и надёжный способ, если тебя мало волнует сохранность данных; то есть нет причин заморачиваться с сохранностью ФС и со всеми этими журналами.

А если сохранность данных все-таки волнует, то очень естественно ожидать от ФС следующего:
1. Как минимум, должны без искажений сохраниться файлы, в которые «достаточно давно» (например, с момента последнего отмонтирования) не было записи.
2. В том числе, если в директории создавались-удалялись какие-то файлы, то это должно не повлиять на сохранность остальных расположенных в этой же директории файлов.
3. Если делался rename, то результирующий файл либо должен сохраниться старым (как если бы никакого rename даже начаться не успело), либо должен сохраниться новым без искажений — даже если в этот новый файл непосредственно перед rename производилась запись.
4. Какие-то еще гарантии нужны для того, чтобы на ФС можно было разместить данные ACID СУБД. Тут я не в курсе, что конкретно требуется.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 3)

man vm.dirty_background_ratio

(/proc/sys/vm/dirty_background_ratio)

soomrack ★★★★★
()
Ответ на: комментарий от pekmop1024

Такое даже с нтфс бывает. От блэкаута спасет только ибп. :)

если ведро зависнет то не спасет

onon ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8
← Ваш путь в терминале
Talks
Теперь не отвертитесь →