The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Создатель Btrfs считает, что данная ФС достигла стабильного ..., opennews (??), 28-Окт-14, (0) [смотреть все]

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


9. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +9 +/–
Сообщение от Аноним (-), 28-Окт-14, 22:59 
Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять файлы на ФС с отмазой "нема места". Читаются файлы при этом прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.

Использовал btrfs на протяжении двух лет в качестве основной fs на arch linux дома и на работе. Умирала на разных системах. Использовал только на SSD, subvolumes не использовал, прозрачное сжатие не включал.

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

10. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Shtirliz72 (ok), 28-Окт-14, 23:01 
На OpenSUSE 13.1 вот уже как год с btrfs полёт стабильный. Отваливается только богопротивный GRUB, но редко.
Ответить | Правка | Наверх | Cообщить модератору

17. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –2 +/–
Сообщение от Vkni (ok), 29-Окт-14, 00:04 
> На OpenSUSE 13.1 вот уже как год с btrfs полёт стабильный. Отваливается
> только богопротивный GRUB, но редко.

Это мазохизм.

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

37. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –1 +/–
Сообщение от Аноним (-), 29-Окт-14, 03:15 
> Это мазохизм.

А в убунте не отваливается. Делаем выводы...

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

138. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Vkni (ok), 30-Окт-14, 06:22 
По опыту общения с Бубунтой скажу, что там просто другие методы истязаний. Вместо наручников связывают ремнём. :-)
Ответить | Правка | Наверх | Cообщить модератору

87. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Shtirliz72 (ok), 29-Окт-14, 18:43 
> Это мазохизм.

Да нет. Всё равно Linux запускается по дефолту. А переустановить GRUB - 2 секунды. Учитывая, что происходит это раз в два месяца, то особо не волнует.

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

95. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Аноним (-), 29-Окт-14, 19:22 
>> Это мазохизм.
> Да нет. Всё равно Linux запускается по дефолту. А переустановить GRUB -
> 2 секунды. Учитывая, что происходит это раз в два месяца, то
> особо не волнует.

Так что именно отваливается? Загрузчик или меню загрузчика?
Если только меню - подозреваю, что баг в разметке диска. Кто-то затирает дополнительную область данных grub (она расположена обычно между MBR и первым разделом, как на GPT - не знаю).

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

18. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от anon1223455667 (?), 29-Окт-14, 00:07 
А вот у меня с указанными симптомами ломалась на OpenSUSE 13.1.
Похоже на эту проблему: https://bugzilla.kernel.org/show_bug.cgi?id=76481
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

11. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –6 +/–
Сообщение от Led (ok), 28-Окт-14, 23:02 
> btrfs иногда умирает
> Использовал btrfs на протяжении двух лет в качестве основной fs на arch

Причина - в arch

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

12. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +2 +/–
Сообщение от Аноним (-), 28-Окт-14, 23:03 
>> btrfs иногда умирает
>> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> Причина - в arch

Пай-мальчик с наложенными патчами на мозг.

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

38. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –1 +/–
Сообщение от Аноним (-), 29-Окт-14, 03:19 
> Причина - в arch

Весьма зависит. Для бтр стоит использовать новые ядра. Желательно последний релиз с кернелорга.

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

40. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –1 +/–
Сообщение от Аноним (-), 29-Окт-14, 05:57 
Вот тебе и новые ядра.
https://bugs.archlinux.org/task/42563?project=1&order=dateop...
Ответить | Правка | Наверх | Cообщить модератору

112. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-14, 00:03 
> Вот тебе и новые ядра.

Дак там и написано - починено в 3.18-rc2. Он что, не свежий? ;)

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

179. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Аноним (-), 19-Янв-15, 16:18 
Проблема была в 3.17.1, пофикшена в 3.17.2 Не вижу ничего криминального.
Ответить | Правка | Наверх | Cообщить модератору

21. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +2 +/–
Сообщение от Xasd (ok), 29-Окт-14, 00:25 
> Использовал btrfs на протяжении двух лет в качестве основной fs на arch linux дома и на работе. Умирала на разных системах.

использовал (и использую) btrfs на разных компьютерах -- несколько лет подрят.

работаю с очень большим количеством мелких файлов (в день примерно создаю по 60000 файлов).

btrfs ни разу не умирала. файлы тоже не портила.

идинственное на что могу пожаловаться: раньше (в первые годы когда начал пользовать btrfs) оно работала не сильно быстро. но сейчас (в последние месяцы) -- скорость btrfs на HDD стала явно выше чем раньше.

но а на компьютере в котором SSD -- btrfs вообще работает замечательно. (хотя на SSD так подозреваю что любая файловая система работает замечательно :))

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

122. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Аноним (-), 30-Окт-14, 02:00 
> работаю с очень большим количеством мелких файлов (в день примерно создаю по
> 60000 файлов).

Ради интереса сделал торентокачалку с btrfs. Бывало все. Слетало питание, машина ребуталась на всем скаку, etc. Не сдохло до сих пор.

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

46. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +2 +/–
Сообщение от ноним (ok), 29-Окт-14, 08:07 
> Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей
> сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять
> файлы на ФС с отмазой "нема места". Читаются файлы при этом
> прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.

Эта "проблема" давно известна. У вас просто размер метаданных вылез за все мыслемые пределы - решается через подключенную влешку с расширением filesystem на нее, последующим balance и изъятием последней.

> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> linux дома и на работе. Умирала на разных системах. Использовал только
> на SSD, subvolumes не использовал, прозрачное сжатие не включал.

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

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

77. "Создатель Btrfs считает, что данная ФС достигла..."  –3 +/–
Сообщение от arisu (ok), 29-Окт-14, 13:32 
> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
> нее, последующим balance и изъятием последней.

решается намного проще, и навсегда: выкидыванием бтра в мусорку.

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

78. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от ноним (ok), 29-Окт-14, 13:57 
>> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
>> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
>> нее, последующим balance и изъятием последней.
> решается намного проще, и навсегда: выкидыванием бтра в мусорку.

Ох ты ж! Ретрограды с поломанным шифтом потянулись на свет! )

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

79. "Создатель Btrfs считает, что данная ФС достигла..."  –3 +/–
Сообщение от arisu (ok), 29-Окт-14, 14:03 
да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых и задорных дури много, вот они по граблям и прыгают. бешеной собаке семь вёрст не крюк.
Ответить | Правка | Наверх | Cообщить модератору

81. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от ноним (ok), 29-Окт-14, 14:12 
> да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых
> и задорных дури много, вот они по граблям и прыгают. бешеной
> собаке семь вёрст не крюк.

Ежели ничего не меняется, то по большей части нечему и ломаться. А "молодые и задорные" двигают вперед это ядро и эту ОС.

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

82. "Создатель Btrfs считает, что данная ФС достигла..."  –3 +/–
Сообщение от arisu (ok), 29-Окт-14, 14:19 
угу. системдецы пишут и вяленды. потому что для молодости и задора места хватило, а для ума — нет.

впрочем, немолодые идиоты там тоже есть: тот же пакард, например.

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

97. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от Fracta1L (ok), 29-Окт-14, 20:25 
Один только arisu стоит в белом пальто, красивый и с ФГМ.
Ответить | Правка | Наверх | Cообщить модератору

163. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от toremail (??), 31-Окт-14, 11:12 
> Один только arisu стоит в белом пальто, красивый и с ФГМ.

И чем то неуловимо  напоминает новодворскую ...

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

98. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от Fracta1L (ok), 29-Окт-14, 20:36 
Вспомнилось, кстати:

- Вы мудры.
- Нет, это великое заблуждение - о мудрости стариков. Старики не мудры. Они только осторожны.
- Быть может, это и есть мудрость.
- Это очень непривлекательная мудрость.

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

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

123. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от Аноним (-), 30-Окт-14, 02:02 
"Насыщает не время проведенное в столовой, а количество съеденных беляшей".
Ответить | Правка | Наверх | Cообщить модератору

162. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от toremail (??), 31-Окт-14, 11:10 
> угу. системдецы пишут и вяленды. потому что для молодости и задора места
> хватило, а для ума — нет.
> впрочем, немолодые идиоты там тоже есть: тот же пакард, например.

И вас с добрым утром.

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

85. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от edwin3demail (ok), 29-Окт-14, 15:06 
>> да, мы такие, ретрограды. любим, когда всё нормально работает. это у молодых
>> и задорных дури много, вот они по граблям и прыгают. бешеной
>> собаке семь вёрст не крюк.
> Ежели ничего не меняется, то по большей части нечему и ломаться. А
> "молодые и задорные" двигают вперед это ядро и эту ОС.

Понимаете, тут Важен баланс.
С одной стороны при разработке новых систем получается новый опыт, специалисты, код, который будет использован в иных местах и т.д.
И это прекрасно, независимо от того, стал ли продукт успешным.

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

И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".

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

93. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Аноним (-), 29-Окт-14, 19:14 
> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".

Как показывает практика, вред от старых маразматиков "не-трожь-здесь-так-заведено" обычно с лихвой перевешивает пользу.

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

99. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от edwin3demail (ok), 29-Окт-14, 20:47 
>> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".
> Как показывает практика, вред от старых маразматиков

Практика говорите ? Чья ? Ваша на основании отдельного случая ? Точно также я могу сказать - часто вред от "дерзких и молодых" такой, что никаким старикам не снился.
И могу подпереть фактами.
И вообще мы отвлеклись от темы, вернемся к ней.
Мы обсуждаем фактическое состояние кодовой базы ФС для внедрения в продакшен.
Так вот, суть в том, что простите, требования "надежности", которые были оглашены - не блажь.
Увы, но если копнуть, то ФС этому требованию не удовлетворяет.    

P.S.
Для саморазвития - отличная болгарская сказка "Почему старикам почёт" - http://www.niworld.ru/Skazki/Skazki_slavian/bolgar/starikam_...

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

115. "Создатель Btrfs считает, что данная ФС достигла..."  –2 +/–
Сообщение от Аноним (-), 30-Окт-14, 00:10 
> И могу подпереть фактами.

Факт простой: если бы всех все устраивало - мы бы обменивались папирусами через конных курьеров и развлекались наскальной живописью. Вот такой вот "вред" от этих, двигающих технологии вперед.

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

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

144. "Создатель Btrfs считает, что данная ФС достигла..."  –3 +/–
Сообщение от edwin3demail (ok), 30-Окт-14, 10:08 
>> И могу подпереть фактами.
> Факт простой: если бы всех все устраивало - мы бы обменивались папирусами
> через конных курьеров и развлекались наскальной живописью. Вот такой вот "вред"
> от этих, двигающих технологии вперед.

Вы занимаетесь шулерством, подменяя понятия.
Вы, как часто бывает, вместо того, чтобы понять о чем говориться, начали смешивать понятия и приписывать оппоненту то, чего он не говорил и даже не думал.
С какой радости молодость == продвижение прогресса прогресса ?

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

Только к молодости/старости это отношения иметь не будет вообще никакого.
Кроме того, говоря о прогрессе как явлении, я уже выше писал свою позицию про "разумный баланс".

> А вас мы
> будем помнить только как научный курьез и помеху.

Уважаемый, давайте прекращать пустопорожнее словоблудие.
Мы обсуждаем конкретную тему - создатель Btrfs считает, что система готова для прода.
На наши замечания, что есть проблемы реального характера и надо их устранять, такие как Вы начинаете бросаться обвинениями в "ретроградстве" а потом вещать "как научный курьез и помеху".
Может Вы прислушаетесь к гласу разума ?

      

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

147. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Аноним (-), 30-Окт-14, 13:31 
> Мы обсуждаем конкретную тему - создатель Btrfs считает, что система готова для прода.

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

> Может Вы прислушаетесь к гласу разума ?

Ок, и он говорит мне: идите в пень, зануда. На таких как вы жалко тратить время. У вас там как, DOS 1.0 и FAT 12 уже достаточно стабильны, или еще не совсем? (вопрос риторический)

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

148. "Создатель Btrfs считает, что данная ФС достигла..."  –2 +/–
Сообщение от edwin3demail (ok), 30-Окт-14, 13:53 
>> Может Вы прислушаетесь к гласу разума ?
> Ок, и он говорит мне: идите в пень, зануда. На таких как
> вы жалко тратить время.

Потратьте не на меня, а на изучения того, как работает ZFS, и как это работает.
Потом поставьте рядом наш предмет обсуждения и сравните.
Может быть тогда Вы поймете степень своего заблуждения.

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

170. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Аноним (-), 01-Ноя-14, 07:01 
> Потратьте не на меня, а на изучения того, как работает ZFS,

Особенно посмотрите в сорцы и алгоритмы. И увидите в ZFS некое кривое недоразумение с кучей вполне ожидаемых технических проблем.

> Потом поставьте рядом наш предмет обсуждения и сравните.

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

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

173. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 01-Ноя-14, 13:04 
>> Потратьте не на меня, а на изучения того, как работает ZFS,
> Особенно посмотрите в сорцы и алгоритмы.

И вы можете процитировать работы, в которых опубликованы "алгоритмы btrfs"?

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

164. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от toremail (??), 31-Окт-14, 11:15 
>> И вот чтобы не впадать в эти крайности и стоит послушать "ретроградов".
> Как показывает практика, вред от старых маразматиков "не-трожь-здесь-так-заведено" обычно
> с лихвой перевешивает пользу.

"Работает - не трогай, а хорошо работает тем более ..." - не зря придумано ...

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

113. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-14, 00:04 
> да, мы такие, ретрограды. любим, когда всё нормально работает.

Вот и кондыбай отсюда на своей бричке.

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

114. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 30-Окт-14, 00:06 
>> да, мы такие, ретрограды. любим, когда всё нормально работает.
> Вот и кондыбай отсюда на своей бричке.

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

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

118. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Аноним (-), 30-Окт-14, 01:50 
> бтр, видимо, «боинг». собраный таджиками, потому что летает хреново и периодически
> падает на землю.

XFS не умеет снапшоты. И с метаданными работает медленно. И разный RAID разным файлам он не сделает. И журналирует только метаданные, а на участь данных - плевать хотел. Раньше вообще "на всякий" протирал файлы нулями в спорных случаях. А т.к. журналинг только метаданных - таких случаев есть. А боинги у нас нормально летают. Хоть для этого и требуется определенный уровень компетенции.

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

120. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 30-Окт-14, 01:55 
>> бтр, видимо, «боинг». собраный таджиками, потому что летает хреново и периодически
>> падает на землю.
> XFS не умеет снапшоты.

и не собирался уметь: он это оставляет volume manager'у. LVM отлично умеет с XFS взаимодействовать в этом плане.

> И с метаданными работает медленно.

что значит «медленно»? по сравнению с чем? нет, бтр не предлагать, оно нифига не стабильное ещё. вот как стабилизируется — тогда и посмотрим.

> И разный RAID разным файлам он не сделает.

что это и зачем оно надо?

> И журналирует только метаданные, а на участь данных - плевать хотел.

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

> Раньше вообще «на всякий» протирал файлы нулями в спорных случаях.

не встречал. а у jfs встречал, кстати.

> А боинги у нас нормально летают. Хоть для этого
> и требуется определенный уровень компетенции.

и любовь к экстриму.

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

124. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-14, 02:44 
> и не собирался уметь: он это оставляет volume manager'у. LVM отлично умеет
> с XFS взаимодействовать в этом плане.

За глаза я считаю затею делать снапшоты на блочном уровне тухлой идеей - это тормозно, оверхед адский. И гибкость чугунной гири в комплекте. Себе это оставь, а я хочу чтобы все это работало по человечески. Я уже наелся снапшотирования виртуалок на блочном уровне в их диске-в-файле, достаточно для того чтобы не желать такое же непотребство на файлухе хоста. Если в виртуалках это трудноустранимое зло (не вижу как это красиво и без костылей для VM можно обтяпать по другому, разве что системдец допилят и вируалка сама будет себя снапшотировать получив команду на свой системдец от parent-системдеца), которое зачастую и кладет I/O, получить такое же гэ еще и на железяке? Нет уж, иди в пень. Ты как замшелый ретроград снапшотами поди просто не пользуешься совсем и именно тебе поэтому пофиг как оно работает. Как мой телепатор, сработал? :) Ну а мне надо нормально работающие снапшоты, а не этот LVM на отъ...сь, извини. Сам снапшотируй XFS LVM, имхо. А как по мне так это попытка приделать деревянному биплану крыло с изменяемой геометрией. Как-то летать, конечно, будет. А зачем мне "как-то"? Мне надо best of the best.

> что значит «медленно»? по сравнению с чем?

Да хоть с экст4 элементарным. Да и бтр. И вообще много кем. Продуть xfs в плане работы с кучей мелочи когда ворочание метаданных сравнимо или превышает ворочание данных сможет разве что какой-нибудь FAT. В новых ядрах немного подтянули, но все-равно мне не нравится. У меня есть тома в XFS, они только под большие файлы. Ибо с метаданными XFS тупит.

> нет, бтр не предлагать, оно нифига не стабильное ещё.

Эксперименты показали что в целом он вполне себе работает. Да там бывают баги. И невкусные. Но они бывают и в ext4. И в xfs. И много где еще. Если список коммитов в ядро почитать. Оно не чемпион по скорости. Хотя это тоже обсуждаемо. Покажи еще кого-нибудь кто делает full журналирование данных+метаданных и сделает это быстрее. А то журналить только метаданные - это читерство и ценой оного - потенциально неконсистентные данные. Я конечно понимаю что половинка старого файла и половина нового - это круто, только большинство файлов при этом нечитабельны. Мухлеж с журналингом только метаданных мне не нравится.

> вот как стабилизируется — тогда и посмотрим.

Как по мне так это от уровней требований зависит.

> что это и зачем оно надо?

А затем что мне не очевидно что у меня все файлы с одинаковой ценностью. И мне возможность заказать файлухе как мне размещать файло видится большим шагом вперед над классическими дубовыми схемами raid ориентированными на сферический мир в вакууме, где у файлов одинаковая ценность, у дисков одинаковый объем, а уж переиграть конфигурацию и вовсе никогда не хочется. Ибо разбирать большой райд - удовольствие ниже среднего.

> всегда было интересно, чем «журналирование просто данных» отличается от «записываем
> данные на диск», и как это должно работать вообще.

В случае классики типа xfs/ext4/... - тем что файлуху не парит вопрос консистентности данных. Если перезаписывался файл и тут вдруг крах - метаданные конечно будут логически корректны, но вот запись дошла до середины файла. И крах. И чего? У меня половина нового и половина старого файла. Информации для отката или доведения операции до конца нет, ибо на то и журналирование только метаданных. И чего с таким файлом делать? В случае CoW это не будет проблемой, ибо старое состояние файла не разрушается, а новое - или уж допишется, и далее апдейтом метаданных получится новый вид, или уж продолбается и при откате после краха на прошлый чекпойнт - файл останется "как было". EXT4 умеет полный журналинг но на классике это тормозно. XFS так не умеет совсем, to the best of our knowledge. А файлы как живые по метаданным, но черти с чем внутри - как-то не прикольно.

> не встречал. а у jfs встречал, кстати.

Более-менее замочили в районе 2.6.28, когда всех окончательно задолбало. Однако все остальное по части журналинга только метаданных - в силе, см. выше - это очень лайт версия журналирования, проблема которой в том что для данных НЕТ никакого undo или intention лога вообще. И запросто выйдет смесь старых и новых данных.

> и любовь к экстриму.

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

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

132. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от arisu (ok), 30-Окт-14, 03:12 
> За глаза я считаю затею делать снапшоты на блочном уровне тухлой идеей

это да, лучше каждый свой велосипед будет придумывать.

> Ты как замшелый ретроград снапшотами поди просто не пользуешься
> совсем и именно тебе поэтому пофиг как оно работает.

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

> А как по мне так это попытка приделать деревянному биплану крыло
> с изменяемой геометрией. Как-то летать, конечно, будет. А зачем мне "как-то"?
> Мне надо best of the best.

оно и видно, да. crc32 в качестве хэш-функции — это бэст, не поспоришь. общий бэкграунд авторов в CS показывает очень наглядно.

>> что значит «медленно»? по сравнению с чем?
> Да хоть с экст4 элементарным.

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

> Продуть xfs в плане работы с кучей мелочи

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

>> нет, бтр не предлагать, оно нифига не стабильное ещё.
> Эксперименты показали что в целом он вполне себе работает.

спасибо, когда у меня появятся ненужные файлы… нет, и даже их я не буду на бтр класть, я их просто сотру: они ненужные. я и к ext4 насторожено отношусь, а она более вылизана, чем бтр.

> кого-нибудь кто делает full журналирование данных+метаданных и сделает это быстрее.

а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать это путём создания нового и атомарного rename. а если файл большой — то это, обычно, какая-нибудь БД, и пусть журналом сама БД и занимается: она лучше знает, как со своими файлами работать.

ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно призвано не твои файлы спасать, а FS: чтобы FS после крэша была в консистентном состоянии. это, кстати, не только твоя беда: очень много людей отчего-то считают, что журналирование должно их файлы спасать. это не так; спасение файлов — задача программы, которая с этими файлами работает. а задача FS — не вставать раком, если вдруг что.

>> вот как стабилизируется — тогда и посмотрим.
> Как по мне так это от уровней требований зависит.

требование простое: не терять мои файлы. пока что raiser3, jfs и xfs с этим справляются. судя по интернетам, бтр справляется не всегда. будем подождать.

>> что это и зачем оно надо?
> А затем что мне не очевидно что у меня все файлы с
> одинаковой ценностью. И мне возможность заказать файлухе как мне размещать файло
> видится большим шагом вперед над классическими дубовыми схемами raid ориентированными
> на сферический мир в вакууме, где у файлов одинаковая ценность, у
> дисков одинаковый объем, а уж переиграть конфигурацию и вовсе никогда не
> хочется. Ибо разбирать большой райд - удовольствие ниже среднего.

пиши разные файлы на разные рэйды. объединяй оверлейной FS. в чём проблемы-то? опять ты инструменты не туда и не так.

>> всегда было интересно, чем «журналирование просто данных» отличается от «записываем
>> данные на диск», и как это должно работать вообще.
> В случае классики типа xfs/ext4/... - тем что файлуху не парит вопрос
> консистентности данных.

и это правильно. см. выше.

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

пока что я наблюдаю, как вы весело бегаете кругами, периодически собирая свой развалившийся на части мегаболид. а потом ещё: «ой! тут пассажир был! где пассажир? никто пассажира не видел?!»

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

p.s. претензии, если что, не к тому, что болид разваливается, а к тому, что это выдают за «стабильное состояние, готовое к повседневному применению». нет, не готово пока.

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

136. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от Аноним (-), 30-Окт-14, 04:13 
> это да, лучше каждый свой велосипед будет придумывать.

Ты внезапно полюбил машины для бритья, делающие всем одинаковую форму лица? Это что-то новое :). Да, я не против нового вела, если он ездит лучше старых.

> и ты таки угадал: я в них не вижу особого смысла.

Вот видишь, я получаю +1 к скиллу телепатии ;). Зато смысл вижу я - БЫСТРОЕ приведение системы и/или данных в вид "как было" за какие-то секунды. Очень здорово исправлять даже серьезные продолбы или последствия экспериментов за единицы секунд.

> нет у меня привычки сначала приводить систему в состояние жoпы,

А я хочу возможность постановки unsafe системных экспериментов с возможностью быстренько сгонять в прошлое на машине времени и отменить эксперимент, если результат не понравился. Да и промахи при работе с файлами можно переиграть. Я человек и поэтому иногда могу делать ошибочные действия. Редко, но достаточно для желания возможности undo.

> а потом радостно откатываться на старый снапшот. мне и LVM хватает.

Кому и брички - выше крыши. Я что, спорю?

> оно и видно, да. crc32 в качестве хэш-функции — это бэст,

Я считаю это небольшим продолбом. В том плане что специально себе простреливать пятки я не намерен, а проблемой это будет разве что когда злонамеренная ремота может файлы с 100% контролируемыми именами вгружать. Оно как бы да, но это нишевая ситуация. А имея доступ к файловым операциям я как бы любую ФС ушатать могу, тюкнув по болючим местам. Worst case у всех хуже average. Это данность.

> общий бэкграунд авторов в CS показывает очень наглядно.

Пользуйся миниксом от одного из светил CS, я не против. А инженерные решения для реального мира балансируют так чтобы нормально работало и умело то что надо. Из какого гуано и палок и что там слеплено очень отдельный вопрос, интересный паре эстетов на планете.

> ты ещё с прямой записью сравни, ага — где сразу через DMA
> на диск фигачит в известные области.

EXT4 - вполне сравнимый по общим идеям в логике работы. Деревья, эктенты, журнал только метаданных. Вполне сравнимые экспонаты. Ну да, ext4 несколько более лайтовый и упрощенный а xfs более навернутый, но имхо это разные перепевки похожих наборов идей.

> а зачем ты xfs так используешь? не надо. у тебя вообще большинство
> проблем от того, что ты инструменты не по назначению используешь.

Читать учись. Я ж сказал что для больших файлов юзается. Для мелочи это сакс. Регулярно проверяю чисто из научного интереса. Сакс. Менее сакс чем было, но все-таки. Файлуха для любителей нелинейного монтажа и т.п. - SGI и есть SGI :).

> я и к ext4 насторожено отношусь,

Хз, он дефолтный в куче дистров и массовых воплей нет. Была парочка жирных багов, но - нишевых и на них маловероятно нарваться при обычных применениях. А в целом судя по изменениям оно не только стабильное, но и это вероятно по состоянию на сейчас один из наиболее протестированных кодов ФС вообще.

> а она более вылизана, чем бтр.

Это совпадает с моими наблюдениями над коммитами, но см. выше. И мое мнение валидно для here and now - 3.17+. Я не археолог, в винтажных ядрах пусть другие колупаются.

> а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать
> это путём создания нового и атомарного rename.

Это всего лишь гнусный костыль по поводу у..щных свойств файлухи. Ясен пень, большинство програмеров забывает это вкостылить.

> а если файл большой — то это, обычно, какая-нибудь БД,

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

> и занимается: она лучше знает, как со своими файлами работать.

Скажу БТРу chattr +C на файл базы и он для нее и журналов станет обычной подложкой. Гибкость файлухи под разные сценарии - это хорошо.

> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
> призвано не твои файлы спасать, а FS: чтобы FS после крэша
> была в консистентном состоянии.

Буллшит. По нормальному журнал делает логику все или ничего. И я получаю или новое состояние или старое. Это логично. Но оказалось что писать данные на диск дважды - тормозно, поэтому применяют такой tradeoff целостности данных на скорость. Я не приветствую такие инженерные подходы и поэтому считаю CoW epic win'ом, хоть это и несет свои проблемы.

> не так; спасение файлов — задача программы, которая с этими файлами
> работает. а задача FS — не вставать раком, если вдруг что.

Я считаю иначе и предпочел бы это видеть свойством файлухи а не программ. Построить 1 файлуху - реально. А всех програмеров планеты - не очень. Поэтому я за делегирование этого на уровень файлухи, и ниипет. Так оно реально будет работать. А строить всех програмеров на костылирование у...щных ФС - это без меня. Я считаб неспособность ФС обеспечить честную транзакционность техническим дефектом.

> требование простое: не терять мои файлы. пока что raiser3, jfs и xfs
> с этим справляются. судя по интернетам, бтр справляется не всегда. будем
> подождать.

Ну это все как бы логично. А с моей колокольни я вижу что btrfs'ная алгоритмика может справиться с рядом проблем на которые все традиционно клали с прибором. Меня это утомило и очень хорошо что Мэйсон решил показать этим "я так привык" как такое на самом деле надо было делать.

> пиши разные файлы на разные рэйды. объединяй оверлейной FS. в чём проблемы-то?

В том что опять же фигово с гибкостью и геморно в управлении. У btrfs это красивее сделано. Есть девайсы, есть заказ разложить вон то вон так. А btrfs юзая свободное место этих девайсов может запрос разрулить. Убедительный и храбрый шаг вперед, мистер Мэйсон. Намного более умный подход к управлению томами и местом на них, имхо.

> опять ты инструменты не туда и не так.

Как я уже сказал - я труба шатал изгибаться буквой зю под кривые инструменты и постоянно обрубать мои нужды под их у...щность.

> и это правильно. см. выше.

А я хочу иное поведение ФС, мне не нравится журналинг только метаданных и я с удовольствием с такими халтурными технологиями распрощаюсь.

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

Ммм? И чего я собирал по частям? Кстати там еще и годный тул для неразрушающего восстановления есть. Это вообще круть и аналогом является разве что пара коммерческих прог для виндовых ФС. А тут такое штатный тул ФС. Вот это да, крутотень. А остальные просто забили на проблематику и их ответ - "используйте photorec" :).

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

Да пожалуйста, кому хуже то?

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

137. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 30-Окт-14, 06:00 
> Вот видишь, я получаю +1 к скиллу телепатии ;). Зато смысл вижу
> я - БЫСТРОЕ приведение системы и/или данных в вид "как было"
> за какие-то секунды. Очень здорово исправлять даже серьезные продолбы или последствия
> экспериментов за единицы секунд.
>> нет у меня привычки сначала приводить систему в состояние жoпы,
> А я хочу возможность постановки unsafe системных экспериментов с возможностью быстренько
> сгонять в прошлое на машине времени и отменить эксперимент, если результат
> не понравился.

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

> Да и промахи при работе с файлами можно переиграть.

как-то ещё со времён ДОСа привык трижды думать и делать копию, а потом уже насиловать файл. всё равно по закону подлости как раз то, что я нечаянно угробил, в снапшот попадёт или старое, или никакое.

>> оно и видно, да. crc32 в качестве хэш-функции — это бэст,
> Я считаю это небольшим продолбом. В том плане что специально себе простреливать
> пятки я не намерен, а проблемой это будет разве что когда
> злонамеренная ремота может файлы с 100% контролируемыми именами вгружать. Оно как
> бы да, но это нишевая ситуация. А имея доступ к файловым
> операциям я как бы любую ФС ушатать могу, тюкнув по болючим
> местам. Worst case у всех хуже average. Это данность.

а это всё потому, что ты тоже имеешь хреновый CS background. я уже говорил, что всё дело в другом: в том, что эта идея вообще голову посетила. у человека с нормальным базовым багажом знаний такой идеи не могло появиться в принципе. вообще. то есть, со знаниями по таким вот простым структурам данных у авторов бтр большие проблемы. а раз даже с тем, чему учат всех cs-студентов там проблемы, то я боюсь предположить, как обстоят дела с более продвинутыми алгоритмами и структурами данных. читать весь их говнокод перед использованием я не готов.

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


>> общий бэкграунд авторов в CS показывает очень наглядно.
> Пользуйся миниксом от одного из светил CS, я не против. А инженерные
> решения для реального мира балансируют так чтобы нормально работало и умело
> то что надо. Из какого гуано и палок и что там
> слеплено очень отдельный вопрос, интересный паре эстетов на планете.

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

> Ну да, ext4 несколько более
> лайтовый и упрощенный а xfs более навернутый, но имхо это разные
> перепевки похожих наборов идей.

мотороллер и R1 тоже «разные перепевки похожих наборов идей». ну да, мотороллер несколько более лайтовый, чо.

>> а зачем? есть такая хорошая практика: если надо перезаписать файл, то делать
>> это путём создания нового и атомарного rename.
> Это всего лишь гнусный костыль по поводу у..щных свойств файлухи. Ясен пень,
> большинство програмеров забывает это вкостылить.

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

>> а если файл большой — то это, обычно, какая-нибудь БД,
> Очередное левое допущение. Если ты еще не понял - меня не прет
> обрубать мои задачи под умения первобытных инструментов.

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

>> и занимается: она лучше знает, как со своими файлами работать.
> Скажу БТРу chattr +C на файл базы и он для нее и
> журналов станет обычной подложкой. Гибкость файлухи под разные сценарии - это
> хорошо.

а ещё лучше — разные инструменты для разных задач. тут вон какой-то гений и /boot на бтр держит, если я верно прочитал.

>> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
>> призвано не твои файлы спасать, а FS: чтобы FS после крэша
>> была в консистентном состоянии.
> Буллшит. По нормальному журнал делает логику все или ничего.

я и говорю: хреново понимаешь.

>> не так; спасение файлов — задача программы, которая с этими файлами
>> работает. а задача FS — не вставать раком, если вдруг что.
> Я считаю иначе и предпочел бы это видеть свойством файлухи а не
> программ.

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

вообще, современные тенденции делать из FS чёртичто ни к чему хорошему не приведут.

> Я считаб неспособность ФС
> обеспечить честную транзакционность техническим дефектом.

да на здоровье. а я вот считаю, что это — ни разу не задача FS.

>> требование простое: не терять мои файлы. пока что raiser3, jfs и xfs
>> с этим справляются. судя по интернетам, бтр справляется не всегда. будем
>> подождать.
> В том что опять же фигово с гибкостью и геморно в управлении.
> У btrfs это красивее сделано. Есть девайсы, есть заказ разложить вон
> то вон так. А btrfs юзая свободное место этих девайсов может
> запрос разрулить. Убедительный и храбрый шаг вперед, мистер Мэйсон. Намного более
> умный подход к управлению томами и местом на них, имхо.

и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного монстрика. я такую идеологию не разделяю.

> А я хочу иное поведение ФС, мне не нравится журналинг только метаданных
> и я с удовольствием с такими халтурными технологиями распрощаюсь.

возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут тебе «честные журналы» на любой FS и у любой софтины. это называется «composition». это юниксвэй, аднака. у меня, например, таким образом все программы отлично понимают 9P, хотя авторы некоторых из этих программ, наверняка, даже не в курсе, что такое 9P.

>> безумству храбрых, конечно, и всё такое. но я лучше пока что на
>> «бричке» доеду.
> Да пожалуйста, кому хуже то?

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

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

140. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от ноним (ok), 30-Окт-14, 09:08 
> у меня для этого всего есть няшные виртуальные машины. я ещё не
> окончательно долбанулся, чтобы рисковать рабочей системой. там и снапшоты есть, кстати.

Только есть такая малюсенькая разница между снапшотами ВМ и снапшотами ФС.

>> Да и промахи при работе с файлами можно переиграть.
> как-то ещё со времён ДОСа привык трижды думать и делать копию, а
> потом уже насиловать файл. всё равно по закону подлости как раз
> то, что я нечаянно угробил, в снапшот попадёт или старое, или
> никакое.

Чаще надо делать снапшоты. А если на каждый чих "трижды думать и делать копию" - то и производительность труда будет соответствующей.


> а это всё потому, что ты тоже имеешь хреновый CS background. я
> уже говорил, что всё дело в другом: в том, что эта
> идея вообще голову посетила. у человека с нормальным базовым багажом знаний
> такой идеи не могло появиться в принципе. вообще. то есть, со
> знаниями по таким вот простым структурам данных у авторов бтр большие
> проблемы. а раз даже с тем, чему учат всех cs-студентов там
> проблемы, то я боюсь предположить, как обстоят дела с более продвинутыми
> алгоритмами и структурами данных. читать весь их говнокод перед использованием я
> не готов.

А по делу можете что-нибудь сказать? Или вы больше по сферическим коням в вакууме специализируетесь?

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

От вас помощи никто и не ждет )

> это не «инженерное решение», а таджикский самопал. crc32 — она даже не
> самая быстрая для хэширования, прикинь. не говоря уже о том, что
> она для хэширования не подходит. просто таджикский программист не в курсе,
> ему без разницы на это всё, трясти надо.

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

>> Ну да, ext4 несколько более
>> лайтовый и упрощенный а xfs более навернутый, но имхо это разные
>> перепевки похожих наборов идей.
> а не надо использовать говнософт. файлы, кстати, тоже костыль. тебе вон к
> завалишину, у его «фантома» файлов нет. правда, «фантома» тоже нет,
> тащемта, но это мелочи.

Что-то поносом попахивает...

> «первобытные инструменты» — это те, которые с файлами работают. что такое
> этот «файл», зачем он нужен вообще? однако ж под файлы ты
> спокойно «прогибаешься». ты уж или трусы, или крестик, а то смешно
> выглядит.

Туда-же.

> а ещё лучше — разные инструменты для разных задач. тут вон какой-то
> гений и /boot на бтр держит, если я верно прочитал.

Держу весь корень в одной btrfs filesystem на разных subvolume - в чем "гениальность"?

>>> ты вообще хреново понимаешь, что такое журналирование и зачем оно надо. оно
>>> призвано не твои файлы спасать, а FS: чтобы FS после крэша
>>> была в консистентном состоянии.
>> Буллшит. По нормальному журнал делает логику все или ничего.
> я и говорю: хреново понимаешь.

Расскажете? Или гои недостойны, как обычно? )

>>> не так; спасение файлов — задача программы, которая с этими файлами
>>> работает. а задача FS — не вставать раком, если вдруг что.
>> Я считаю иначе и предпочел бы это видеть свойством файлухи а не
>> программ.
> а я — нет. код FS должен быть простым. чем проще код,
> тем меньше там багов. вот и всё. кому надо — может
> использовать в своей программе библиотеки для журналируемой работы с файлами, их
> есть. кому не надо — может не использовать. а FS остаётся
> простой.

FAT - ваш выбор, ну или на край UFS.

> вообще, современные тенденции делать из FS чёртичто ни к чему хорошему не
> приведут.

Ну что же вы так скромно. "современные тенденции ни к чему хорошему не приведут" - так будет лучше )

>> Я считаб неспособность ФС
>> обеспечить честную транзакционность техническим дефектом.
> да на здоровье. а я вот считаю, что это — ни разу
> не задача FS.

Считайте дальше )

> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
> монстрика. я такую идеологию не разделяю.

Юниксвей уже даже Линусу не уперся - что вы забыли на этом ядре?

> возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут
> тебе «честные журналы» на любой FS и у любой софтины. это
> называется «composition». это юниксвэй, аднака. у меня, например, таким образом
> все программы отлично понимают 9P, хотя авторы некоторых из этих программ,
> наверняка, даже не в курсе, что такое 9P.

Кому сейчас нужен Plan9 акромя исследовательского интереса?

> (пожимает плечами) точно не мне. у меня все довольны, брат жив, батя
> грит малацца.

Слова девяти из дести слакварьщиков.

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

141. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от arisu (ok), 30-Окт-14, 09:19 
изыди, дурачина, не с тобой беседа была.
Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

142. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от ноним (ok), 30-Окт-14, 09:36 
> изыди, дурачина, не с тобой беседа была.

ЧИТД )

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

143. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от arisu (ok), 30-Окт-14, 09:48 
нет, не требовалось. ты уже давно доказал, что дурак.
Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

145. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 30-Окт-14, 12:37 
> Чаще надо делать снапшоты. А если на каждый чих "трижды думать и
> делать копию" - то и производительность труда будет соответствующей.

Угу, думать вообще вредно.

>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>> монстрика. я такую идеологию не разделяю.
> Юниксвей уже даже Линусу не уперся

С чего вы взяли?

> Кому сейчас нужен Plan9 акромя исследовательского интереса?

Читали басню дедушки Крылова про свинью и дуб?  

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

149. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от ноним (ok), 30-Окт-14, 13:58 
>> Чаще надо делать снапшоты. А если на каждый чих "трижды думать и
>> делать копию" - то и производительность труда будет соответствующей.
> Угу, думать вообще вредно.

Угу, а думать о вещах, о которых должен "думать" компьютер - это как раз-таки цель всего IT, так получается?

>>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>>> монстрика. я такую идеологию не разделяю.
>> Юниксвей уже даже Линусу не уперся
> С чего вы взяли?

http://www.itwire.com/business-it-news/open-source/65402-tor...

Linus Torvalds: So I think many of the "original ideals" of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.

There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.

>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
> Читали басню дедушки Крылова про свинью и дуб?

Читал. Тока вышеперечисленное больше смахивает на басню про оптический прибор и примата.

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

150. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 30-Окт-14, 14:31 
> Угу, а думать о вещах, о которых должен "думать" компьютер

К сожалению, падаван, компьютер не способен "думать", даже в кавычках.  В т.ч. и в данном конкретном примере.  Как минимум, требуется подумать на тему - как, где и когда что-то сохранить.  Плюс, как потом быстро найти это сохраненное.

>>>> и совершенно не юниксвэйный при этом: вместо комбинации инструментов строим очередного
>>>> монстрика. я такую идеологию не разделяю.
>>> Юниксвей уже даже Линусу не уперся
>> С чего вы взяли?
> http://www.itwire.com/business-it-news/open-source/65402-tor...

И причем тут "юниксвей"?  Если там что и обсуждается - так разве "do one thing and do it well".  Между тем, это только один из принципов.  "Не пиши на C без крайней нужды, придурок" - другой, не менее важный.

> There's still value in understanding the traditional UNIX "do one thing and
> do it well" model where many workflows can be done as
> a pipeline of simple tools each adding their own value, but
> let's face it, it's not how complex systems really work

Я бы сказал, что Git - вполне себе контрпример этому троллингу от Линуса.

Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model" - что символизирует всю "глубину" этого мнения.

>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>> Читали басню дедушки Крылова про свинью и дуб?
> Читал.

Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?

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

153. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от ноним (ok), 30-Окт-14, 17:23 
>> Угу, а думать о вещах, о которых должен "думать" компьютер
> К сожалению, падаван, компьютер не способен "думать", даже в кавычках.  В
> т.ч. и в данном конкретном примере.  Как минимум, требуется подумать
> на тему - как, где и когда что-то сохранить.  Плюс,
> как потом быстро найти это сохраненное.

Конечно прошу прощеня, но к вам в падаваны даже за деньги бы не пошел ) А "подумать на тему - как, где и когда что-то сохранить" e.t.c решается один раз, в отлиичие от исходного "как-то ещё со времён ДОСа привык трижды думать и делать копию, а потом уже насиловать файл", не находите?

>[оверквотинг удален]
>>> С чего вы взяли?
>> http://www.itwire.com/business-it-news/open-source/65402-tor...
> И причем тут "юниксвей"?  Если там что и обсуждается - так
> разве "do one thing and do it well".  Между тем,
> это только один из принципов.  "Не пиши на C без
> крайней нужды, придурок" - другой, не менее важный.
>> There's still value in understanding the traditional UNIX "do one thing and
>> do it well" model where many workflows can be done as
>> a pipeline of simple tools each adding their own value, but
>> let's face it, it's not how complex systems really work

См. выше. "а ещё лучше — разные инструменты для разных задач." - это прямое противопоставление с "...the traditional UNIX "do one thing and do it well" model ... their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time." Ну или английский подучите как-нибудь )

> Я бы сказал, что Git - вполне себе контрпример этому троллингу от
> Линуса.

Без комментариев )) Хотя... Почему git pull, merge, mv e.t.c - это не отдельные утилиты, а?

> Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model"
> - что символизирует всю "глубину" этого мнения.

"Глубине" мнения Линуса, конечно-же никогда не сравняться с вашими глуюинами )

>>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>>> Читали басню дедушки Крылова про свинью и дуб?
>> Читал.
> Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?

Если честно, нихера не напоминает ) Напоминает arisu, который плюет в колодец из которого пьёт ( ну или по крайней мере делает вид )

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

154. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 30-Окт-14, 19:33 
> А "подумать на тему - как, где и
> когда что-то сохранить" e.t.c решается один раз

Ах, если б (  "Решатель" из ТП хостера, я угадал?

> См. выше. "а ещё лучше — разные инструменты для разных задач." -
> это прямое противопоставление с "...the traditional UNIX "do one thing and
> do it well" model

В каком месте тут что чему противопоставляется?

> ... their own value, but let's face
> it, it's not how complex systems really work, and it's not
> how major applications have been working or been designed for a
> long time." Ну или английский подучите как-нибудь )

Вам надо перевести?  Так прямо бы и попросили.

>> Я бы сказал, что Git - вполне себе контрпример этому троллингу от
>> Линуса.
> Без комментариев )) Хотя... Почему git pull, merge, mv e.t.c - это
> не отдельные утилиты, а?

А почему должны?

>> Впрочем, он уже упомянул Emacs как traditional counter-example этой "simple UNIX model"
>> - что символизирует всю "глубину" этого мнения.
> "Глубине" мнения Линуса, конечно-же никогда не сравняться с вашими глуюинами )

Да, это не моя.  Почитайте что-ли книжку ESR на досуге, там подробно обсасывается и этот миф о "traditional counter-example".

>>>>> Кому сейчас нужен Plan9 акромя исследовательского интереса?
>>>> Читали басню дедушки Крылова про свинью и дуб?
>>> Читал.
>> Нужно пояснить чем ваше выссказывание про Plan9 напоминает ту хрюшку?
> Если честно, нихера не напоминает )

Ну а как же.  Сидит, умник, поплевывает свысока на исследователей - "конгресс, немцы какие-то" (ц).  Тут 100500-ю FS надо писать, причем срочно.  Эвана - студент-недоучка "создал Linux" (тм), значит могем?!  А то структуры данных, алгоритмы - "голова пухнет" (ц).

Правда если вспомнить, что студент-то - начал с того что кривоватенько передрал POSIX...

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

156. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от arisu (ok), 30-Окт-14, 22:48 
> e.t.c

triplefacepalm

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

146. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 30-Окт-14, 12:39 
> возьми библиотеку журналируемой работы с файлами и засунь в LD_PRELOAD. и будут
> тебе «честные журналы» на любой FS и у любой софтины. это
> называется «composition».

Это еще называется - мэээдленна.


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

155. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от arisu (ok), 30-Окт-14, 22:47 
> Это еще называется - мэээдленна.

а чего медленного-то? как напишешь — так и будет.

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

159. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 31-Окт-14, 10:46 
> как напишешь — так и будет.

People who think that userspace filesystems are realistic for anything but toys are just misguided. (ц)

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

165. "Создатель Btrfs считает, что данная ФС достигла..."  –1 +/–
Сообщение от arisu (ok), 31-Окт-14, 11:17 
>> как напишешь — так и будет.
> People who think that userspace filesystems are realistic for anything but toys
> are just misguided. (ц)

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

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

166. "Создатель Btrfs считает, что данная ФС достигла..."  +1 +/–
Сообщение от Аноним (-), 31-Окт-14, 13:27 
>>> как напишешь — так и будет.
>> People who think that userspace filesystems are realistic for anything but toys
>> are just misguided. (ц)
> йопта… а создатели БД-то и не знают! у них, фактически, навороченая userspace
> FS. идиоты. пойду, расскажу, что без ядерного модуля они в бирюльки
> играются.

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

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

167. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 31-Окт-14, 13:42 
воспитанников интерната для умственно отсталых я в обсуждение не приглашал.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

168. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 31-Окт-14, 15:02 
>>> как напишешь — так и будет.
>> People who think that userspace filesystems are realistic for anything but toys
>> are just misguided. (ц)
> йопта… а создатели БД-то и не знают! у них, фактически, навороченая userspace FS.

Они-то как раз - знают, потому у них и нет этой самой "навороченной FS".

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

169. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 31-Окт-14, 15:06 
> Они-то как раз - знают, потому у них и нет этой самой
> "навороченной FS".

breaking news, аднака.

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

174. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 01-Ноя-14, 13:11 
Мне не интересно соревноваться с вами в духе специальной олимпиады.  Если вы не понимаете откуда здесь оверхед - просто рассмотрите что происходит при записи данных в такой "FS" vs файл на обычной журналируемой FS.
Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

175. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от arisu (ok), 01-Ноя-14, 13:14 
> Мне не интересно соревноваться с вами в духе специальной олимпиады.

а получается отлично, тем не менее.

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

171. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Vkni (ok), 01-Ноя-14, 08:07 
> Они-то как раз - знают, потому у них и нет этой самой
> "навороченной FS".

Файловая система - это простая иерархическая база данных. "Ключ" - это имя файла, "значение" - содержимое файла. Возможны, разумеется, всякие извращения вроде нескольких ключей, связанных с одним значением (hard-link), нескольких значений для одного ключа (потоки NTFS) и т.д.

Но с высоты птичьего полёта файловые системы - это простые базы данных, встроенные в ОС. Кстати, если подумать, становится ясно, какое же это извращение - реестр Windows ;-).

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

172. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от myhand (ok), 01-Ноя-14, 13:00 
>> Они-то как раз - знают, потому у них и нет этой самой
>> "навороченной FS".
> Файловая система - это простая иерархическая база данных.

Угу.  А все компьютерные языки - не имеют существенных отличий от брайнфака.  Полнота по Тьюрингу, нех.

> Но с высоты птичьего полёта

На известной высоте полета, все люди - обИзьяны.

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

176. "Создатель Btrfs считает, что данная ФС достигла..."  +/–
Сообщение от Vkni (ok), 01-Ноя-14, 14:39 
>> Файловая система - это простая иерархическая база данных.
> Угу.  А все компьютерные языки - не имеют существенных отличий от
> брайнфака.  Полнота по Тьюрингу, нех.

Вы слишком долго программировали на БФ. Аналогом "файловая система - это простая иерархическая база данных" является "брейнфак - это не очень удобный язык программирования".

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

105. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +1 +/–
Сообщение от Vkni (ok), 29-Окт-14, 22:33 
> Эта "проблема" давно известна. У вас просто размер метаданных вылез за все
> мыслемые пределы - решается через подключенную влешку с расширением filesystem на
> нее, последующим balance и изъятием последней.

Весело у вас.

> У меня все в точности наоборот, за исключением того что я тоже
> использую дома, а в продакшн - пока только под бэкапы.

А зачем?

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

48. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +1 +/–
Сообщение от Alen (??), 29-Окт-14, 08:51 
Пробовал для теста использовать btr со сжатием под раздел с портами в генту.
Прожила около 4 месяцев потом умерла. Использование под такой раздел райзера и ext4
ни когда проблем не вызывало. Кроме того бросалось в глаза сильное проседание по скорости.
Пока для себя считаю btr не готовым, и разумеется ни каких продакшенов.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

65. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Fracta1L (ok), 29-Окт-14, 12:13 
Использую Btrfs со сжатием и под дерево портежа, и под /usr/src, и под систему вообще. Всё работает быстро и стабильно вот уже почти год. Наверное, кое-кому стоит вытащить руки из задницы.
Ответить | Правка | Наверх | Cообщить модератору

76. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от ананим (?), 29-Окт-14, 13:18 
Подтверждаю.
Медленнее, чем на ехт4, но работает стабильно уже >2 лет (гланое не делать даунгрэйд ядра/утилит. Хотя,.. я не пробовал. Но есть убеждённость, что не стоит)
Ответить | Правка | Наверх | Cообщить модератору

58. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от btrfs user (?), 29-Окт-14, 11:06 
а всего то надо было перемонтировать без space_cache.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

86. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  –1 +/–
Сообщение от анон (?), 29-Окт-14, 18:28 
Использовал на 3Тб хдд. Умерла аналогичным образом. А после попытки fsck перестала монтироваться. Спас почти все файлы при помощь restore. Опасаюсь пользоваться в дальнейшем.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

92. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Андрей (??), 29-Окт-14, 19:12 
Вероятно, вы не знаете особенности SSD. discard не забыли включить? Более 60% занимать не рекомендуется. Возможно она в паре с контроллером просто защищали вас от «непоправимого»...
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

100. "Создатель Btrfs считает, что данная ФС достигла стабильного ..."  +/–
Сообщение от Аноним (-), 29-Окт-14, 21:43 
> Из моего опыта, всё-таки, btrfs иногда умирает. У меня умирала в общей
> сложности раза четыре. Всегда с одинаковыми симптомами: внезапно перестаёт создавать/редактировать/удалять
> файлы на ФС с отмазой "нема места". Читаются файлы при этом
> прекрасно. Никаких методов адекватной реанимации я в своё время не нашёл.

Ты это, как работает CoW вообще представляешь, не?

> Использовал btrfs на протяжении двух лет в качестве основной fs на arch
> linux дома и на работе. Умирала на разных системах. Использовал только
> на SSD, subvolumes не использовал, прозрачное сжатие не включал.

Ты это. Маны бы покурил там. Концепции. Чтобы лучше просекать, что ты, собственно говоря, используешь.

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

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

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




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

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