1.1, Аноним (-), 20:55, 02/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Крис также отметил что на 14 февраля намечен крайний срок выпуска программы btrfs.fsck, способной исправлять ошибки на Btrfs-разделах.
Вроде ж это автоматом делается при монтировании?
| |
|
2.2, Аноним (-), 21:04, 02/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не умеет еще исправлять ошибки.
Пока что только может их находить.
| |
|
3.13, fyjybvec (?), 00:53, 03/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
По словам разработчиков, сейчас некоторые ошибки испоравляются молча и налету.
| |
|
4.30, Аноним (-), 13:52, 03/02/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way это. А потом сюрприз при открытии важного файла - чексуммы не бьются и кирдык, да? Спасибо, нет пути.
| |
|
5.34, Аноним (-), 13:57, 03/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да исправление ошибок вообще не юниксвейно. Их надо делать, а не исправлять.
Если их исправлять - придет Патрик и покарает (ничуть не бредовее вашего "чексуммы не бьются").
| |
5.40, Аноним (-), 14:43, 03/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Как-то не нравится лично мне молчаливое исправление неведомо каких ошибок. Не UNIX-way
> это. А потом сюрприз при открытии важного файла - чексуммы не
> бьются и кирдык, да? Спасибо, нет пути.
Мне кажется, с вашим уровнем знаний о работе файловых систем ("чексуммы не бьются и кирдык") несколько самонадеянно рассуждать о целесообразности решений и сущности unix-way в данной области.
Позвольте поинтересоваться, вы еще и "поттероподелия" в том же стиле критикуете?
| |
|
|
|
2.3, Аноним (-), 21:14, 02/02/2012 [^] [^^] [^^^] [ответить] | +3 +/– | Делается что Запуск fsck которого нет При монтировании журналирующая файло... большой текст свёрнут, показать | |
|
3.14, Bx (ok), 01:15, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Боюсь, с fsck не все так просто. Если на выходе fsck требуется получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных) со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть диском полчаса".
| |
|
4.16, Аноним (-), 03:07, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Боюсь, с fsck не все так просто. Если на выходе fsck требуется
> получить полностью целостную fs(не монтируемую, не просто с целостностью (мета)данных)
> со всеми ее фичами, то у btrfs есть "небольшие" сложности. Форматы
> хранения (мета)данных dup, raid1, raid10 в некоторых случаях могут потребовать ЗНАЧИТЕЛЬНОГО
> времени восстановления целостности, слабо коррелирующего c "может себе позволить потарахтеть
> диском полчаса".
Могут. Правда в случае именно метаданных - в нормальной ситуации они не должны занимать существенный процент тома. В случае данных... хм... в самом плохом случае - да, вероятно. А какая альтернатива предлагается? Слить данные, раздестроить пул и пересобрать его обратно? А это будет проще и быстрее? :)
| |
|
3.17, Аноним (-), 04:52, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Сноэпшот - да. Вариант быстрый.
>fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...
На самом деле fsck должен пройтись по основным структурам и по журналу. Зачем бежать по всем(!) структурам если есть журнал? Ну а по всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к мысли что это должен быть не fsck вовсе).
| |
|
|
5.45, Аноним (-), 17:43, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> У btrfs нет журнала.
В каком-то роде оно один сплошной журнал. Поэтому оно может просто и быстро отбросить неудачный хвост до момента последнего снапшота и сделать вид что его вообще не было. Поскольку запись не разрушающая, это ведет к ФС в логически корректном состоянии, где метаданные и данные синхронны и состояние ФС - то что было в момент снапшота. Просто, круто, работает.
| |
|
4.32, Аноним (-), 13:53, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Сноэпшот - да. Вариант быстрый.
>>fsck - намного более хардкорный вариант процедуры восстановления. Он по идее должен быть способен перебрать все метаданные ФС, детально проверить их корректность и соответствие данным, сделав полный проход по соответствующим структурам и удостоверившись...
> На самом деле fsck должен пройтись по основным структурам и по журналу.
> Зачем бежать по всем(!) структурам если есть журнал? Ну а по
> всему винту пусть бегает утилита восстановления с элементами ИИ (подвожу к
> мысли что это должен быть не fsck вовсе).
Журнал в JFS помогает гарантировать целостность в 100% случаев, не?
| |
|
5.46, Аноним (-), 17:53, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Во первых в современных ФС обычно журналят только метаданные, поскольку делать а... большой текст свёрнут, показать | |
|
|
|
|
|
2.12, me (??), 00:38, 03/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
в этот день к уложившимся в срок любовь начальства будет платонической, а к неуложившимся - плотской
| |
|
3.18, Аноним (-), 04:54, 03/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Внезапно рабский синдром. Вы в интернете - забудьте про начальство (тут только большой брат).
| |
|
4.39, Аноним (-), 14:40, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Внезапно рабский синдром.
Ах вот как теперь элита офисного планктона называет "ответственность".
| |
|
|
2.15, anonymous (??), 01:24, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Скорее как у них (а теперь и у нас) к дню выборов. Дедлайн для рапорта о свершениях лучезарной всерегулирующей невидимой руки рынка настояшего свободного общества.
| |
|
1.21, dalco (ok), 08:38, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно, никакущую скорость при работе с файлами-контейнерами виртуальных машин починили?
Когда-то проводил такой эксперимент - берем готовый файлик CentOS5.img (у меня там была минимальная конфа + настроенный postfix), скармливаем его qemu-kvm и засекаем время запуска.
Так вот, при прочих равных условиях, на ext4 сей образ подымался менее чем за 20 секунд (с учетом того, что 5ая центось достаточно неторопливо грузится). На том же самом разделе, но отформаченном в btrfs, загрузка того же образа занимала около 25 минут(!) и работать с той виртуальной машинкой после загрузки было достаточно сложно (ну ооочень неторопливая :) ).
P.S. Впрочем, справедливости ради хочу сказать, что ноут с какой-то там древней Федорой (14?) настроенный на полное использование btrfs (окромя /boot) просто работал и нужды в fsck в ходе работы не возникло. Правда хитрые фичи типа сжатия и снапшотов там не использовались.
| |
|
2.22, ананим (?), 11:54, 03/02/2012 [^] [^^] [^^^] [ответить] | +1 +/– | давно использую бтр, а с декабря перебросил на неё всё - 500гб винт на ноуте, сд... большой текст свёрнут, показать | |
|
3.23, dalco (ok), 12:22, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
А виртуалка в вашем случае одна крутится или много? У меня их до десятка одновременно может быть с одного раздела пущено (куча запросов на чтение/запись в параллель), начиная с центосей всех видов(гигов на десять каждая) и кончая Win2k8 (там уже под сотню гигов образа дисков весить могут).
P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.
| |
|
4.25, ананим (?), 12:46, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>А виртуалка в вашем случае одна крутится или много?
много порой.
и виртуалбоксе, и кластер на квм.
>У меня их до десятка одновременно может быть с одного раздела пущено
а какая разница с какого раздела одного диска то?
в бтр понятие разделов вообще если не отменяется, то нивелируется.
там всё - субволумы. и самый главный с субволид=0, и все снепшоты, и собстно субволумы.
зыж
>P.S. Впрочем, попробую еще раз, благо, времени это должно занять относительно немного.
у меня гента - всё самое последнее, если что.
жду вот ещё ядро 3.3
| |
|
5.38, dalco (ok), 14:32, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Ну, разделы далеко не всегда на одном диске живут Да и в случае даже одного ... большой текст свёрнут, показать | |
|
6.42, Аноним (-), 14:49, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Спасибо, об этом я в курсе. Но вы упускаете одну важную вещь
> - все, сказанное вами, справедливо, когда под btrfs отдан диск(или диски)
> целиком.
> А я ведь и извратиться могу (и извращаюсь) - с разделами, LVM,
> mdraid (или аппаратной его реализацией). И только поверх всего это тонким
> слоем нанесу btrfs :)
Хех. И вы еще жалуетесь на низкую производительность?
| |
|
7.43, dalco (ok), 14:59, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Хех. И вы еще жалуетесь на низкую производительность?
Ага :)
Только не забывайте, что при прочих равных условиях (стопицот уровней абстракций и LVMов) ext4 работает нормально, а btrfs в том же самом месте при работе именно с образами виртуалок безбожно тормозит (точнее тормозила на время теста).
P.S. Кстати, https://bugzilla.redhat.com/show_bug.cgi?id=689127 до сих пор не закрыт ;) Так что не один я такой отморозок.
| |
|
8.53, Аноним (-), 18:33, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Напомните, с каких пор в ext4 появился встроенный менеджер и реализация рейда ... текст свёрнут, показать | |
|
9.60, dalco (ok), 19:12, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | А это здесь причем Просто диск mdraid hardware-raid - partitions - LVM - ext... текст свёрнут, показать | |
|
10.85, ананим (?), 13:20, 04/02/2012 [^] [^^] [^^^] [ответить] | +/– | вообще то чем бтр хороша - она использует уже имеющиеся структуры ядра, а не вно... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
2.77, fyjybvec (?), 02:31, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Касательно "хитрых фич типа сжатия и снапшотов", кстати: сжатие влияет на загрузку процессора (но на LZO, на мой взгляд, вообще незначительно), а снапшоты вообще никакого отрицательного влияния не оказывают.
| |
|
1.24, Аноним (-), 12:25, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 7 гигов данных выделяется 1 гиг метаданных :/ Дескать, на его 8-и меговый файл выделился 1 гиг метаданных, и туда, в этот раздел с 1 гигом метаданных, он мог засунуть еще 7 гигов данных. Потом, получается, фс выделит еще 1 гиг метаданных и так далее. Если это именно так, то какой же пустой расход места получается, что для домашних машин с относительно небольшими винтами не особо подходит, лишь для сервачков. Стоит ли расход места на ПК тех плюшек, которые обещает эта фс?
| |
|
2.26, ананим (?), 12:50, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Я просто не понял или это именно так: этот товарищ сказал, что в бтрфс на 7 гигов данных выделяется 1 гиг метаданных
# btrfs filesystem df /
Data: total=215.00GB, used=210.85GB
System, DUP: total=8.00MB, used=32.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=3.50GB, used=2.34GB
210.85 данных - 2.34GB метаданных
или вы думаете журнал юзает меньше?!!!
| |
|
3.27, Аноним (-), 13:08, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
То есть мужичок на видео врет на счет 1 гига метаданных на 7 гигов данных? Или вы не пользуетесь всеми возможностями по снятию снимков, которые показывал он? Откуда расхождения взялись у него и у вас, вот что я спрашиваю. Это не попытка докопаться или подколоть - просто любопытно.
| |
|
4.28, ы (?), 13:39, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.
| |
|
5.35, Аноним (-), 13:59, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> У этой ФС очень велик оверхэд на хранение маленьких объектов. На их
> большом количестве как раз можно получить такое.
Он у любой ФС очень велик. Внезапно.
| |
|
|
7.73, Аноним (-), 21:24, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Кроме рейзера, который хранит их прямо в журнале
Это пресловутый tail packing, заметно снижающий скорость и создающий риск факапа то? Не, я понимаю что экономия места - круто. Но не такой же ценой?!?!
| |
|
8.75, Аноним (-), 01:16, 04/02/2012 [^] [^^] [^^^] [ответить] | +/– | Нет, это пресловутый tail packing, заметно повышающий скорость, снижающий расход... текст свёрнут, показать | |
|
7.79, fyjybvec (?), 02:50, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Btrfs же хранит в журнале маленкие файлы.
Оверхед, конечно, есть. Я не считал сколько, но со слов Hugo Mills:
" ... at a minimum of 413 bytes of metadata overhead for an inline file, plus the length of the filename. "
| |
|
8.91, Bx (ok), 20:46, 05/02/2012 [^] [^^] [^^^] [ответить] | +/– | Ага, а еще и dup raidXY, hugo это признает Впрочем, смотрите первоисточник - ... текст свёрнут, показать | |
|
|
|
5.82, ананим (?), 12:14, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>У этой ФС очень велик оверхэд на хранение маленьких объектов. На их большом количестве как раз можно получить такое.
хм.
могу ещё раз привести мою статистику:
210.85 данных - 2.34GB метаданных
если нужны пояснения - это весь винт под системой, включая /usr, ../lib, ../src (гента всё-таки), плюс коллекция фоток/музыки и тд, и тп
в общем есть масса мелких файлов, а есть и крупные виртуалки - на всё ушло 210.85 гигов.
при этом метаданных - 2.34GB.
и я не считаю это сильно большой жертвой для такой функциональности.
| |
|
4.29, ander (??), 13:44, 03/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
понятно что при каждом создании снепшотов резервируется место, может у него там дофига снепшотов
| |
|
5.33, Аноним (-), 13:54, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> понятно что при каждом создании снепшотов резервируется место, может у него там
> дофига снепшотов
Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
Я к тому речь веду, что для ПК это черезчур получается. Хотя, видимо, можно будет настроить.
Просто расход места впечатляет :)
| |
|
6.47, Аноним (-), 18:01, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
Старые снапшоты подтираются постепенно, поэтому суммарный расход места вполне вменяемый. Ну если конечно не совать эту ФС на флоппики всякие - ну не для дискеток она, а для жестких дисков и даже создания многодисковых хранилищ.
| |
|
7.92, Bx (ok), 21:03, 05/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Это понятно. Он об этом сам и говорит - каждые 30 с делается снимок.
> Старые снапшоты подтираются постепенно, поэтому суммарный расход места вполне вменяемый.
> Ну если конечно не совать эту ФС на флоппики всякие -
> ну не для дискеток она, а для жестких дисков и даже
> создания многодисковых хранилищ.
Вы, похоже, не понимаете суть снапшотов. В человеском языке нет понятия снимка снимка снимка :) А ведь есть еще и ридонли снимок этого всего :) Метадата растет немерянно...
| |
|
|
|
|
3.31, Аноним (-), 13:52, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> или вы думаете журнал юзает меньше?!!!
dumpe2fs /dev/sda4 | grep -m1 'Journal size'
dumpe2fs 1.42 (29-Nov-2011)
Journal size: 128M
df -h
/dev/sda4 1,8T 1,1T 777G 58% /home
Получается, что меньше ;)
| |
|
4.36, Аноним (-), 14:00, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> или вы думаете журнал юзает меньше?!!!
> dumpe2fs /dev/sda4 | grep -m1 'Journal size'
> dumpe2fs 1.42 (29-Nov-2011)
> Journal size:
> 128M
> df -h
> /dev/sda4 1,8T
> 1,1T 777G
> 58% /home
> Получается, что меньше ;)
Депендс. В журналируемых ФС журнал иногда зависит от темпа дисковых транзакций.
| |
|
5.81, ананим (?), 12:07, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
дело то не только в журнале.
вот к примеру сколько у вас на inode ушло тут не отражается как в моём примере.
| |
|
4.48, Аноним (-), 18:04, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Получается, что меньше ;)
Ну и насколько сильную погоду тебе сделает 1-2 Гб на 2Тб диске? Это 0.1% емкости. Другие факторы могут дать в дохрена раз больше оверхеда. Хотя для тех кого давит жаба, есть еще и сжатие, если что. При том LZO имеет свойство распаковываться быстрее чем диск читает :)
| |
|
|
2.80, fyjybvec (?), 03:08, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Есть у меня фс, которая в последний раз использовалась для каких-то тестов с маленькими файлами (кажется, не помню), правда она 10Гб, а не 8.
# df -h /dev/sda8
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sda8 9.9G 6.9G 2.2G 76% /mnt/scratch
# btrfs fi show /dev/sda8
failed to read /dev/sr0
Label: 'scratch' uuid: 6cfe1a7d-052d-4f18-bd1e-38311a29c9ee
Total devices 1 FS bytes used 6.85GB
devid 1 size 9.83GB used 9.46GB path /dev/sda8
Btrfs Btrfs v0.19-dirty
# btrfs fi df /mnt/scratch/
Data: total=8.65GB, used=6.84GB
System, DUP: total=32.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=384.00MB, used=13.52MB
Выглядит не так плохо. А после балансировки ещё лучше:
# btrfs fi bala /mnt/scratch/
# btrfs fi df /mnt/scratch/
Data: total=7.97GB, used=6.84GB
System, DUP: total=32.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=384.00MB, used=11.73MB
| |
|
1.37, Аноним (-), 14:25, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну вот, всякие анонимусы по религиозным соображениям критиковавший корпорации как такие жуют шляпу. Именно корпорации, в погоне за расширением и нажывой инициируют создание очень полезных и доступных всем вещей. Даже корпорации "зла" типа Oracle и Microsoft в итоге способствуют развитию OpenSource в большей мере, чем если бы этих корпораций небыло вообще и они не мешали зазвитию OpenSource.
| |
|
2.41, Аноним (-), 14:47, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Похоже, вы, как и другие пренебрежительно упомянутые вами анонимусы, страдаете ч... большой текст свёрнут, показать | |
|
3.52, Аноним (-), 18:15, 03/02/2012 [^] [^^] [^^^] [ответить] | –2 +/– | Пример 1 http www apache org foundation thanks html Пример 2 http foundati... большой текст свёрнут, показать | |
|
4.57, Аноним (-), 18:45, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
С яблоком - очень неудачные примеры. Ребята весьма потребительски относятся к опенсорсу, так что на долю пользователей и независимых разработчиков хорошего перепадает мало.
Насчет хорошего от мелкософта - пример тем более неубедителен. Скорее даже, убедителен в обратную сторону: спонсируется самое известное опенсорсное кладбище проектов.
Похоже, вы вдолбили себе в голову, что корпорации есть Абсолютное Добро, и ничего кроме добра от них опенсорсу никогда не было. Опять же черно-белый взгляд на мир, просто еще один вариант. Скучно...
| |
|
5.59, Аноним (-), 19:07, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Ну это ваше черно белое восприятие меня Какое вообще может быть добро зло в впо... большой текст свёрнут, показать | |
|
6.64, Аноним (-), 20:45, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Apache-Apache... Просто этот сервер удачнее IIS. M$ никак не могла догнать apache по популярности... и купить не могла, как обычно они это делают. Поэтому просто стали вкладывать деньги, чтобы он лучше работал на Windows...
| |
|
7.70, Аноним (-), 21:15, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Я вам о теплом вы мне о кислом. Да что Вы так Microsoft оравдываете. У Вас что акции Microsoft куплены?
Верю вам на слово, они руководствувались исключительно не благими намерениями и вкладчики Microsoft могут спать спокойно: их деньги не идут на благотворительность :)
| |
|
|
5.63, Аноним (-), 19:46, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | И дополнение, я же забыл опять об Android Думаю, спорить не будете что количест... большой текст свёрнут, показать | |
|
|
3.55, Аноним (-), 18:36, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Кстати, а что такого хорошего для опенсорса сделал мелкософт, что бы перевесило его нечестную конкуренцию, гетьзефаксы и патентный троллинг?
Кстати это как правило касается опять таки не OpenSource как такого, а конкуренции между компаниями. Ну подорожали, например устройства на базе Android из-за действий Microsoft, само же развитие Android не остановилось, наоборот, это теперь открытый проект, теперь, Microsoft косвенно заинтересованна в его развитии, может даже больше чем Google. Конкретно конечный пользователь у себя в KDE/Gnome разве не имеет какой-то функции из-за активности, например, Microsoft? Более того, в такой жестокой борьбе многим приходится открывать код программных продуктов.
| |
|
2.65, Аноним (-), 20:58, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Из всей огромной корпорации вJOBывал аж целый один вполне Крис Мэйсон, между про... большой текст свёрнут, показать | |
|
1.44, iCat (ok), 16:29, 03/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Блин, и ещё раз - блин!
Лучше бы ZFS под GPL перелицензировали!!!
| |
|
2.49, Аноним (-), 18:06, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Лучше бы ZFS под GPL перелицензировали!!!
Кому лучше то? И почему? Бтр - более новый дизайн. Ряд тупняков зфс-а в нем устранили. Эти упыри даже аллокатор блочный там оставили, по сути. Хоть и с блоками переменного размера, но мелкими, блин. Накукуй тебе еще одно блочное тормозилово? Ща 2012 год, наверное можно уже освоить экстенты в нормальном виде, да?!
| |
|
3.50, iCat (ok), 18:08, 03/02/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Лучше бы ZFS под GPL перелицензировали!!!
> Кому лучше то? И почему? Бтр - более новый дизайн...
Мне лучше.
ZFS работает. BTRFS _будет_ работать.
| |
|
4.58, Аноним (-), 18:47, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Мне лучше.
> ZFS работает. BTRFS _будет_ работать.
ZFS прекрасно работает по Linux, уже больше полугода как добавили полноценную работу с файловой системой (ZPL) http://zfsonlinux.org
Другое дело, что это никому, кроме разработчиков проекта, не интересно.
| |
|
5.61, iCat (ok), 19:30, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Мне лучше.
>> ZFS работает. BTRFS _будет_ работать.
> ZFS прекрасно работает по Linux... http://zfsonlinux.org
> Другое дело, что это никому, кроме разработчиков проекта, не интересно.
во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся всё больше как-то сами... мучаются...
| |
|
6.74, Аноним (-), 21:31, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> во-первых, не особенно "прекрасно", а во-вторых - интересно многим, только интересующиеся
> всё больше как-то сами... мучаются...
Наверное секрет в том что дизайн zfs весьма задрючен и довольно странен местами. Плюс лицензия специально выбрана недружественной, что ставит крест на шансы стать майнстримом в майнлайне. А переписать с нуля такое монстило - долго, и если уж так долбаться то не понятно зачем принимать неоднозначные решения еще раз, если можно учесть опыт предшественников и сделать лучше. Btrfs как раз и является чем-то типа этого. При его создании посмотрели на сильные и слабые места уже существующих ФС (включая zfs) и попробовали избавиться от недостатков и выдернуть преимущества. ИМХО вполне годно получилось.
| |
|
|
4.66, Аноним (-), 21:01, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Мне лучше.
Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?
> ZFS работает.
Ну если она у вас работает - пользуйтесь. В чем проблемы?
> BTRFS _будет_ работать.
Да она вообще-то уже вполне прилично работает, если что. Вон там кто-то правильно написал - примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях - "доктор Ватсон не заметил явных проблем". Так что шли б вы уже погулять. Если вы надеетесь указывать толпе людей что им надо делать - они вам тоже что-нибудь укажут. Не очень приличными жестами.
| |
|
5.67, iCat (ok), 21:07, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Так идите и переписывайте. Или вы думаете что то что надо ВАМ будет делать кто-то еще?
так я и так...
>...примерно с 3.2 ядра оно довольно юзабельно и практически не подкидывает сюрпризов, как минимум при типовых операциях...
А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...
Багрепорт отправил...
>...указывать толпе людей что им надо делать...
"Да ни боже мой!!!" С чего бы это?... Моё личное мнение не считаю обязательно верным для кого бы то ни было...
| |
|
6.71, Аноним (-), 21:17, 03/02/2012 [^] [^^] [^^^] [ответить] | +/– | Ну и здорово Если здоровья хватает и цель нужна - way to go Правда если честно... большой текст свёрнут, показать | |
6.83, ананим (?), 12:21, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>А у меня "при прочих равных условиях" iowait показала стремящийся к 100%...
вот как раз iowait в бтр у меня на порядок ниже стал, чем в ext4.
что характерно, скорость копирования некоторые проги показывают почти в 2 раза бульше, чем раньше.
и меня это слегка напрягает - ну не может этого быть!
| |
|
|
|
|
2.56, Аноним (-), 18:39, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Блин, и ещё раз - блин!
> Лучше бы ZFS под GPL перелицензировали!!!
ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов санок.
Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо, преимущества дизайна btrfs все-таки значительны.
| |
|
3.62, iCat (ok), 19:33, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> ZFS нынче полезна главным образом в плане выжимания денег со старых клиентов
> санок.
> Судя по всему, оракл не собирается ее развивать, в отличие от.
Продавальщики хреновы...
Как собака на сене - ни сам не гам, ни другому не дам...
| |
|
4.69, Аноним (-), 21:11, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Как собака на сене - ни сам не гам, ни другому не дам...
Ну так за санки уплачено же. А так - ну вон бсдунам ее вывалили. Правда все на что их хватает - кой-как интегрять хяляву в свое ядро.
Думаю что мы сейчас увидим как пингвин опять обойдет кой-кого на повороте, невзирая на крупную фору. Как обычно...
| |
|
3.68, Аноним (-), 21:09, 03/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Судя по всему, оракл не собирается ее развивать, в отличие от. Видимо,
> преимущества дизайна btrfs все-таки значительны.
Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у. Вообще, я не вижу причин ожидать сногсшибательных результатов от блочного аллокатора как у некоторых.
| |
|
4.84, ананим (?), 12:51, 04/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Судя по всему она для оракловой базы (а чего еще оракла волнует?) ну совсем никак не конкурент бтр-у.
да кстати. в презентахе сабжа "докладчик" несколько раз о проводимых тестах tpc упоминал.
что какбэ интересно с точки зрения фс и методик её тестирования.
| |
|
|
|
1.87, Frank (ok), 18:52, 04/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сдох в ноуте ssd от kingston на 64 ГБ, работавший больше года под btrfs. Внезапно, после ребута вместо бута - ругательства на невозможность монтирования корня. Один раздел на весь диск, два сабволюма: корень и хомяк. Хомяк зашифрован. Прогрузившись с запасного девайса, посмотрел - раздел монтируется, файловая система читается, шифрованные файлы доступны. На винт переустановил ось, стал думать как лучше всего перетянуть файлы. Поскольку юзернейм и пароль в новой системе совпадают со старой, решил тупо заменить файлы .Private и всё такое, загрузившись с LiveCD. SSD пришлось снова вставить в ноут, ибо usb шнурок отказывался его монтировать из-за i/o errors, а напрямую в sata контроллёр ноута оно монтировалось несмотря на. Однако, ноут что-то не захотел грузиться с болванки - мигал капслоком, пока я не изымал болванку из привода. Тут же внезапно обнаружилось, что ноут смог как ни в чём ни бывало загрузиться с ssd в мою старую систему. Просто слил файлы хомяка на винт. В процессе было ругательство на невозможность прочесть какой-то файл - сказал ему игнорировать такие ошибки.
Вывод: btrfs действительно хорошая, надёжная система, которую не так просто развалить в бытовом применении даже не смотря на отсутствие полноценного fschk.
| |
|