[нытик-тред] пропало 6Gb музыки

короче интернеты быстрые, скачаю занаво

ещё какие-нибудь предположения для избежания подобного, кроме journal-опции(помимо перехода на др. фс)?

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

блин, я бы кого-нибудь убил, если б мой workspace от eclipse потерялся бы )))
тема как бы про это ;)

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

Заюзай ZFS любым способом, но заюзай или всё время будешь пользоваться торрентами для перекачивания удалённых или битых файлов. :) Ну, или хотя бы JFS для критичных к удалению данным.

блин, я бы кого-нибудь убил, если б мой workspace от eclipse потерялся бы )))

ZFS создана той же конторой, что и Java. Eclipse создана IBM и передана сообществу, как и неубиваемая JFS.

> неубиваемая JFS

Вполне себе убиваемая. /etc целиком только так улетала в никуда.

R-Studio есть для Linux и поддерживает ext4. Воспользуйся им.

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

Вывести ReiserFS (не путать с убогим Reiser4) из строя и потерять на нём данные это нонсенс. А на ext4 — это вполне обычное поведение, особенно если оперативки много

> >В ZFS гарантируется консистентность файловой системы и данных при любых пертурбациях напряжения питания носителей, не выводящих их из строя, поскольку CoW.

4.2

Это все аргументы, на которые способны пятизведочные тролли?

> Если сбой заденет предыдущую копию данных, то ничто не поможет, даже CoW. А сбой случаен, и он может это сделать.

Вот только в случае с линуксятными фс ты об этом даже не узнаешь.

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

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

> я где-то читал, что оно менее стабильное

Подтверждаю собственным опытом 2 раза терял корень на рейзере

Рейзер, было подобное. Нетбук внезапно сел.

>> неубиваемая JFS

4.2.

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

Ну, data=journal придумано как раз для этого, ибо через журнал при этом идут не только метаданные, но и данные. Понятно, что серебряной пули нет, но эта мера даёт неплохие гарантии.

Это я понимаю всё, но говорю к тому, что 100% гарантии нет.

>Ext{3|4} в режиме journal гарантирует.

У девелоперов в lkml было иное мнение.

Внезапно: на перезаписываемом носителе этого не может гарантировать никто.

>наверняка был режим ordered.

2.6.38

Таки writeback.

>> У девелоперов в lkml было иное мнение.

Можно ссылку?

>> Таки writeback.

Интересно, чем руководствовались разработчики, меняя умолчание на writeback? %)

Быстрый гугл мне не помог, sorry.

http://lkml.org/lkml/2009/4/6/331

Ясно, спасибо.

> Вывести ReiserFS (не путать с убогим Reiser4)

Сам ты убогий. В Reiser4 и суперблок тиражируется в отличие от reiserfs, и все недостатки reiserfsck учтены.

Ололо, он стоит столько денег что ух.

15 дней триала

Ext{3|4} в режиме journal гарантирует.

В режиме journal они гарантируют сохранность данных о структуре fs и только.

>> В режиме journal они гарантируют сохранность данных о структуре fs и только.

Сохранность данных о структуре — ordered.

переполз на reiserFS
теперь буду делать бэкапы

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

Интересные методы борьбы с 12309, однако. Это точно теперь дефолт? Переспрашиваю потому, что после чтения раздела «Data Mode» этого документа мой мозг отказывается в это верить.

>Это точно теперь дефолт?

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