восстанавливать файлы на фс конечно лучше

Чтоб сломать нафиг журналируемую и айнодовую ФС — надо очень постараться, без вишмастера не обойтись. А fsck около получаса работал, системный раздел 50 гигов всего.

я бы oom киллера дождался

Чтобы реально было дождаться ООМ, надо сидеть с низким оверкоммитом, мне это не подходит. Да и разве он грохает процессы в состоянии D? ну кокнет всё жирное, кроме процессов APT, — дальше-то что? Это ж форк-бомбе сродни, засрёт только всё, упрётся в лимит ФС на DUP-файлы и на том накроется медным тазом в самый неподходящий момент, оставив кучу битого неразобранного говна, ещё и помешав каким-нибудь важным процессам записать данные (я не раз терял настройки юзерспейсных программ из-за переполнения ФС, а APT под рутом работает и может даже резерв заюзать, что вообще чревато), уж лучше это предотвратить.

А про архивы, образы, удалённые ФС Линус думал? Или это тоже «игрушки»?

нет, программа. конкретно демон /usr/bin/ntfs-3g. садись, два

Ну так и называй его сразу <демон ntfs|ntfs-3g>, не вводи честной народ в заблуждение.

А ссылки типа объявлять не надо?

а бывают ссылки на NULL? Я что-то не встречал, обычно ссылка только на уже СУЩЕСТВУЮЩИЙ объект. Не?

Чтоб сломать нафиг журналируемую и айнодовую ФС — надо очень постараться, без вишмастера не обойтись.

какой же ты наивный…

А про архивы, образы, удалённые ФС Линус думал? Или это тоже «игрушки»?

у него и спроси. А лучше прочитай оригинальный пост, там всё написано. Или тебе перевести на русский?

Потому что это ntfs-проблемы, ext-разделы примонтированные из под винды так не выпендриваются.

очевидно, что неполной совместимостью.

на уже СУЩЕСТВУЮЩИЙ

А если объекта уже нет, а ссылка осталась?

Ну и как её сломать, м? В головном айноде хранится почти вся инфа о файле и ссылки на следующие узлы вплоть до концевых узлов, я не представляю, что можно сделать с ФС без похеривания всего содержимого диска подряд, чтобы сломать файлы до невосстанавливаемости. Можно случайно принять какие-нибудь данные (хоть из raw-образа раздела, хоть просто случайно совпавшие) за головной айнод, но это единичные случаи. Те, куда запись шла — пострадают, да, но их относительно мало и на них есть журнал.

А если объекта уже нет, а ссылка осталась?

в C++ будет UB

в «нормальных ЯП» такого не бывает. GC не убьёт объект, пока есть ссылка на него.

чтобы сломать файлы до невосстанавливаемости

да очень просто:

1. открываешь новый файл FILE, начинаешь в него писать

2. ВНЕЗАПНО прерываешь запись (например вырубая питания и т.п.)

3. включаешь, оно видит, что-то не так, начинает восстанавливать

4. видит, что с FILE что-то не так, и возвращает FILE к последнему консистентному состоянию. Т.к. файл новый, то это «пустой файл размера 0».

Если уже есть FILE, то ФС в п1 его «удаляет» из дерева ФС, хотя он и остаётся на диске. Но т.к. он считается «удалённым», то fsck его в действительности удаляет.

А лучше прочитай оригинальный пост, там всё написано

И это я ещё искать должен?

fuse хорош, если экспортируемая вещь -- что-нибудь типа некоего
малоиспользуемого интерфейса к принципиально медленному устройству. Но
для чего-то типа вашей корневой ФС? Не, ну нафиг.

Чем опасен NTFS раздел?

1. С правами будет жопа.

2. Если есть винда в дуалбуте и она умеет в какой-то свой виндовый суспенд (фастбут или что-то типа того), то ntfs-3g может не смонтировать раздел, с какими-то сообщениями типа «завершите работу в винде нормально».

3. Ну и ntfs-3g тормозной.

// тред не читал

В обоих случаях драйверопроблемы: родной виндовый драйвер NTFS на символы ругайцо, а драйвер для ext (какой из, кстати?) этот конфликт разруливает — ещё и конфликт регистров разруливает, небось? В виндовом драйвере вся эта байда осталась, по сути, из-за мнимой совместимости с MS-DOS, которой в NT всё равно нет и при обращении досовских и 9x-шных программ к не-FAT-ФС GORODQ~1 KOST?LI. Зачем эти костыли торчат для других программ — непонятно, но удобно; можно, например, в cmd (да и при указании путей в гуйцах) юзать досовские имена и не морочиться с регистром и длинными именами (ибо если в cmd хоть какое-то автодополнение есть, то в гуйцах его нет и приходится или писать многабукаф, или мышевозить по файловому диалогу). ИСЧХ, родные линуксовые дрова для fat и vfat юзать имена с досонеугодными символами не дают, а вот ntfs-3g...

нормальных ЯП
GC

Всё ясно.

Я ж написал --

куда запись шла — пострадают

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

Т. е. мобила с USB 3.0 или WebDAV по хорошему каналу «принципиально медленные»

да. Потому что виденные мною мобилы жутко тупят, а что значит USB3.0 на них — я не знаю. Наверное фаза луны или инициалы жены маинменеджера.

davfs2 я юзаю с yandex.disk, а это говнооблако само по себе жутко тупое, причём от канала это не зависит. Хорошо хоть десктоп 24/7/365 молотит, т.ч. обычно оно успешно сливается (по ночам, в час по чайной ложке).

а редкоиспользуемая файлопомойка уже типа корневой ФС?

знаешь, если я воткнул USB-HDD, то мне как-то не комильфо ждать 20..30 часов, пока оно туда сольётся. Или если сольётся наполовину, и встанет. Или 12309.

«нормальных ЯП» GC

Всё ясно.

кавычки тут для красоты, да?

А остальным что будет?

ничего. Если идёт запись в каталог, уедут в lost+found/.

но открытые на запись файлы == самые нужные. Закрытые уже есть в бекапах.

одним опасен - лоровцы заклюют

виденные мною мобилы жутко тупят
yandex.disk

Это всё конкретные реализации.

Или 12309

От внешнего винта? охщи. Кстати, можно ли задать минимальный резерв памяти под дисковые кэши? у меня даже после выпила дискового свопа система при заполнении памяти встаёт раком.

открытые на запись файлы == самые нужные

Это что нужно делать, чтобы всё постоянно пересохранялось на диск? Если бы весь софт так постоянно делал, SSD дохли бы за считанные месяцы.

Закрытые уже есть в бекапах

Я бэкапы делаю на другую машину раз в две недели, когда домой езжу.

Если бы это было опасно, то в галерее было бы пусто, у всех ШГ же.

ntfsfix решает проблемы

Это всё конкретные реализации.

а зачем ещё нужно FUSE?

Или 12309

От внешнего винта?

с NTFS? Да легко!

Кстати, можно ли задать минимальный резерв памяти под дисковые кэши? у меня даже после выпила дискового свопа система при заполнении памяти встаёт раком.

Кнут лет 50 назад доказал, что _любая_ система встанет раком при заполнении памяти. Как это часто бывает, теоретические выкладки до сих пор в силе.

Это что нужно делать, чтобы всё постоянно пересохранялось

не всё конечно, а пара-тройка файлов. ВНЕЗАПНО, именно с ними я сейчас работаю, и у меня нет на них актуального бекапа.

Я бэкапы делаю на другую машину раз в две недели

а я каждый час. Если есть интернет(а он есть почти всегда), то в облако и на другую машину.

ну удали из своей венды драйвер ntfs. без программы(=драйвера) нет никакой фс, лол

даже после выпила дискового свопа система при заполнении памяти встаёт раком

отключение свопа только ухудшает ситуацию

Если случится глюк придется снимать веник и вешать на машину с вин. Потом естественно chkdsk. А так хреново, но можно жить.

задать минимальный резерв памяти под дисковые кэши

держи мои плацебо настройки, если станет хуже, пиши в спортлото

echo       0 >/proc/sys/vm/admin_reserve_kbytes
echo 1048576 >/proc/sys/vm/dirty_background_bytes
echo 2097152 >/proc/sys/vm/dirty_bytes
echo    2048 >/proc/sys/vm/min_free_kbytes
echo       1 >/proc/sys/vm/swappiness
echo  100000 >/proc/sys/vm/vfs_cache_pressure

а зачем ещё нужно FUSE?

А какое отношение FUSE имеет к конкретным FUSE-драйверам?

_любая_ система встанет раком при заполнении памяти

Винда ж на этой конфигурации (и предыдущей аналогичной) не встаёт.

ВНЕЗАПНО, именно с ними я сейчас работаю

Нормальный рабочий софт время от времени сам бэкапит текущие файлы.

а он есть почти всегда

Что не даёт повода забивать канал заливками всяких многомегабайтных файлов.

в облако

Ещё чего.

Ну с HDD на 5400 RPM и бразосом вместо проца ещё спорно, что хуже — своп или zRam.

Раз тема еще живет, добавлю от себя. Оказалось, что в NTFS не работают линуксовые разрешения, нельзя просто сделать chmod для файла.

лол, вот это открытие. ну, будем знать

А схреналь они должны работать?

Нормальный рабочий софт время от времени сам бэкапит текущие файлы.

НИКОГДА не надейся на автоматику.

Что не даёт повода забивать канал заливками всяких многомегабайтных файлов.

там этот ваш ya.disk в час по чайной ложке льёт.

Оказалось, что в NTFS не работают линуксовые разрешения, нельзя просто сделать chmod для файла.

а на каталог уже можно, да?

Да, есть опция persistent, что-ли (не уверен) при монтировании.

НИКОГДА не надейся на автоматику

Если предохраняться — зачем тогда ныть о надёжности ФС?

там этот ваш ya.disk в час по чайной ложке льёт

Далеко не всякий канал шире этой «чайной ложки».

Если жесткий диск в рид-онли вообще не опасно.

Если используется ntfs-3g, не опасен, можно использовать. Только юниксовые права (chmod/chown) не совсем совместимы с родным NTFS ACL, но если таки нужно, см.

ntfs-3g.usermap

Чем опасен NTFS раздел?

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

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

Test Suite

Если хочешь удостоверится что ФС работает правильно то у разработчика Ntfs-3g есть специальный тест файловой системы http://www.tuxera.com/community/open-source-posix/ .

Open Source: POSIX Test Suite
Works with FreeBSD, Solaris, and Linux with UFS, ZFS, ext3, XFS and the NTFS-3G file systems

она расшифрует эти данные и отправит их куда следует.

Нет, сразу позовет кого-следует, сама определит, налоговую или сантехника.

пару лет был такой раздел, достался с диском и там файлы всякие были, вроде работало. Потом спустя пару лет решил переместить все файлы из ntfs на ext4 - вылезли какие-то странные ошибки и с кодировкой(!) хотя вроде как все отображалось и открывалось нормально, после этого, т.к. в основном на лине, то решил все и держать на ext4 окончательно

Если же попадаются случаи работы с ntfs, то стараюсь в рижиме рид-онли на них что-то делать...

Еще помню было дело каталог Dropbox на ntfs для Win7 и Lin сделал что бы был одинаковый на одной машине, то же какие-то странности повылазили вплоть до смены прав (chmod -x на исполняемые файлы), что было очень неприятно