LINUX.ORG.RU
Ответ на: комментарий от sdio

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

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

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

Chaser_Andrey ★★★★★
() автор топика

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

darkshvein ☆☆
()
Ответ на: комментарий от sdio

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

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

Chaser_Andrey ★★★★★
() автор топика
Ответ на: Плохо читал от GotF

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pavval ★★★★★
()

tmpfs

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

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

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

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

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

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

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

JustGuest
()
Ответ на: комментарий от GotF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

facepalm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

megabaks ★★★★
()

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

snoopcat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.