Альтернативы решения проблемы?

Комп находится в месте, где его могут перегружать хард-ресетом, этойт процесс неконтролируемый.

+Свет на ночь могут выключить.

Любая+журнал безопасного уровня. А вообще купи UPS если в твоем доме завелись злые сварщики.

>data=journal
ага, оно

readonly fs

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

//да, стабильного сетевого соединения тоже нет. Вот такие экстремальные условия.

journal_data When the filesystem is mounted with journalling enabled, all data (not just metadata) is committed into the journal prior to being written into the main filesystem.

journal_data_ordered When the filesystem is mounted with journalling enabled, all data is forced directly out to the main file system prior to its metadata being committed to the journal.

journal_data_writeback When the filesystem is mounted with journalling enabled, data may be written into the main filesystem after its metadata has been committed to the journal. This may increase throughput, however, it may allow old data to appear in files after a crash and journal recovery.

надо попробовать на досуге на диске для локальных бекапов...

>убить так, чтобы не фиксилось, не удалось
Хочешь научу? :3

>Альтернативы решения проблемы?

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

операция записи не завершается, пока не завершится с синком. Ты давишь «сохранить», и ждёшь, пока всё на диск не скинется. А без sync'а - работаешь дальше. Иные файлы у меня несколько минут удалялись - ибо сильно фрагментированны были. Но команда rm отработала мгновенно. Был-бы у мну sync - ждал-бы эти минуты...

Ну да, ты описал поведение sync. И? Все равно питание исчезнет в любой момент. И все равно в этот момент будут как данные, которые уже успели сброситься на диск, так и несохраненные данные. Все равно пролюбим часть свежих данных (да, бОльшую, но это не критично - ведь питание могло и на пару секунд раньше сбойнуть). Но при этом фс должна остатся целостной (ибо журнал). А насколько sync говняшит производительность говорить не приходится.

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

Система на LiveCD (флешка, это не убиваемо по определению), для данных - бекап на xfs (вроде она самая быстрая на запись)

Если так важны все данные до момента сбоя, то может стоит думать не про sync, а про резервирование?:)

tmpfs

Создать любую файловую систему, смонтировать в ro, смонтировать tmpfs в /new_root, скопировать туда при загрузке содержимое ro-файловой системы, switch_root в /new_root. Всё это пишется в initramfs.

>> xfs (вроде она самая быстрая на запись)

На мелких файлах сливает почти всем, и даже на крупных отстаёт от ext4.

> убить так, чтобы не фиксилось, не удалось.

Одно слово - рейзер.

>> на крупных отстаёт от ext4

Хотя отставание близко к погрешности, нужно более обстоятельное тестирование с bonnie++. Если не забуду, в выходные попробую.

ну можно и ручки выпрямить , а не только цитировать глупости:
http://www.ep.ph.bham.ac.uk/general/support/raid/raidperf11.html

>> Original version: 20081209. This update: 20090731

Не годится. С того момента в ext4 было много изменений.

>Если так важны все данные до момента сбоя, то может стоит думать не про sync, а про резервирование?:)

а резервирование может и не сработать. Кроме sync мне неизвестно надёжного и переносимого способа узнать, записан файл, или ещё нет. Как резервирование узнает, нужно-ли резервировать? ну будет оно писать в два «файла», которые на самом деле не файлы, а память, и которые исчезнут после ресета.

У меня локальный бекап хранится на размонтированном разделе, который почти всегда не примонтирован. И бекап считается успешным, только тогда и если диск размонтировался. Команда umount тоже делает sync.

>ну можно и ручки выпрямить , а не только цитировать глупости: http://www.ep.ph.bham.ac.uk/general/support/raid/raidperf11.html

Original version: 20081209. This update: 20090731.

ну да, я заметил это за пару месяцев использования ext4 на корне системы в Debian. Снес и поставил Debian на рейзер - nautilus в разы быстрее открывает /usr/bin. И отклик выше.
Пущай там азиат в google пилит ext4 свою, ей еще далеко до «мертвой» xfs ))

а резервирование может и не сработать. Кроме sync мне неизвестно надёжного и переносимого способа узнать, записан файл, или ещё нет.

это sync надежный? Про буферы HDD не забыл?

Как резервирование узнает, нужно-ли резервировать? ну будет оно писать в два «файла», которые на самом деле не файлы, а память, и которые исчезнут после ресета.

Я имел ввиду резервирование в смысле дублирования систем (раз уж у нас нет гарантии, что с какой-то одной внезапно произойдет хня и она обрушится). Если очень важные данные, то надо не syncом защищатся от их потери. А иначе и sync не особо нужен.

>Снес и поставил Debian на рейзер - nautilus в разы быстрее открывает /usr/bin

facepalm

а я-то думал: «и что они в райзере нашли?»

вон оно как...

>это sync надежный? Про буферы HDD не забыл?

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

Если очень важные данные, то надо не syncом защищатся от их потери. А иначе и sync не особо нужен.

ну знаете-ли! конечно одним syncом ничего не добиться! но и без него тоже ничего не получится. Пишу-же: «для локальных бекапов». Подразумевается, что есть и удалённые.

>> ей еще далеко до «мертвой» xfs

Дооо, слить в полтора с лишним раза на rewrite — это отличный результат: ext4 — 77790 K/s, xfs — 46802 K/s.

xfs настраиваемая и стабильна, а закидоны «пацанвы на мопедах» меня мало колышут.

>xfs настраиваемая

а что там настраивать-то?

смотри доки по xfsprogs

>> а что там настраивать-то?

http://everything2.com/title/Filesystem+performance+tweaking+with+XFS+on+Linux

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

>> смотри доки по xfsprogs

А что так размыто? Давай конкретные примеры :)

>Правда, особого эффекта это не даёт, но можно смягчить проблему

Ясно. А можно решить командой mkfs.ext4.

можно подумать, что это тебе помешает в следующий раз «обьективно» обсирать xfs.

А можно решить командой mkfs.ext4.

Я так и сделал :) На $HOME XFS была вполне ничего, возможно, перейду на неё снова, но как backup target это просто беда — пока копировались кучи мелких файлов типа ~/.thumbnails или ~/.icons можно было успеть выпить чаю (само по себе это терпимо, но искажает оценку времени копирования в разы, что не есть хорошо).

>но как backup target это просто беда — пока копировались кучи мелких файлов типа ~/.thumbnails или ~/.icons можно было успеть выпить чаю (само по себе это терпимо, но искажает оценку времени копирования в разы, что не есть хорошо).

долгий бекап - не есть хорошо, ибо приходится принимать кучу разных мер, что-бы бекап был не противоречив :-(

> отвечал - впрочем ты не поверишь же...

И долго отвечал? Перед тем, как выгнали?
Я _не_верю_, что с таким отношением человеку можно дать ответственность за что-либо сложнее телефона Nokia 1280, да и то. Либо ты так толсто троллишь.

малыш - я тебе даже объяснять не хочу
я отвечал и за секретные докУменты
впрочем тебе не понять

reiserfs v3.6
треднечитал™

reiserfs.