The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Оценка методов противостояния потере данных в ФС при крахе с..., opennews (??), 15-Дек-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


39. "Оценка методов противостояния потере данных в ФС при крахе с..."  +1 +/
Сообщение от Crazy Alex (ok), 15-Дек-15, 16:02 
То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуаций, а разработчики софта, который требует большего, об этом обычно знают и стараются учитывать. Обычно можно и наоборот сделать - почитать мануал на БД или подобное и синхронизацию отключить к чертям, если в носителе и ФС уверен.

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

Ответить | Правка | Наверх | Cообщить модератору

46. "Оценка методов противостояния потере данных в ФС при крахе с..."  –1 +/
Сообщение от коляша (ok), 15-Дек-15, 16:25 
> То есть пользователи выбирают опции, которые дают им достаточный уроыень надёжности для большинства ситуаций

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Нимано (?), 15-Дек-15, 17:08 
>А разработчики софта решили нaсрать на выбор пользователя потому что принимают его за идиота.

Угу, мечта разработчика софта: поддерживать пару дюжин комбинаций ФС  и опций.

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

А если почитать оригинал, то вообще все может стать с ног на голову:

The manpage literally refers to rumor. This is the level of documentation we have. If we look back at our example where we had to add an fsync between the write(/dir/log, “2, 3, foo”) and pwrite(/dir/orig, 2, “bar”) to prevent reordering, I don’t think the necessity of the fsync is obvious from the description in the manpage. If you look at the hardware memory ordering “manpage” above, it specifically defines the ordering semantics, and it certainly doesn’t rely on rumor.

Ответить | Правка | Наверх | Cообщить модератору

76. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 15-Дек-15, 21:32 
>  I don’t think the necessity of the fsync is obvious from the description in the manpage.

Вообще говоря это очевидно.

Ответить | Правка | Наверх | Cообщить модератору

162. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Crazy Alex (ok), 17-Дек-15, 02:45 
А разработчики знают, что их случай - не из этого большинства, и принимают соответствующие меры.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

75. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от Аноним (-), 15-Дек-15, 21:16 
> Напоминаю - стандартный случай записи в файл на никсах - это "записать
> обновлённые данные в новый файл, потом переименовать его в старый".

Угу, и это не работает для символических ссылок, для жёстких ссылок, для файлов с ACL и расширенными атрибутами, для больших файлов (не оптимально). Как то не очень хорошо.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

79. "Оценка методов противостояния потере данных в ФС при крахе с..."  +/
Сообщение от angra (ok), 15-Дек-15, 22:24 
> Угу, и это не работает для символических ссылок, для жёстких ссылок

Оно и не должно для них работать. Особенно для вторых.

> для файлов с ACL и расширенными атрибутами

Зависит от софта. Он с тем же успехом может не учитывать и обычные права.

> для больших файлов (не оптимально).

Зависит от структуры файла. Но там где она позволяет и не применяется этот метод.


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру