| 1.1, pavlinux (ok), 10:27, 07/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Потому что ZFS создали Боги, и в ней нет ошибок и багов, а данные, с вероятностью 1, нельзя потерять.
| | |
| |
| 2.6, Andrew Kolchoogin (?), 11:30, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
От потери данных, связанной с ошибками в реализации файловой системы, fsck не спасёт. Кроме того, так как fsck -- сам по себе программный продукт, а "last bug in our programs won't be corrected until last user is dead", _само по себе наличие_ этой утилиты отрицательно сказывается на надёжности хранения данных.
| | |
| |
| 3.12, pavlinux (ok), 14:10, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>От потери данных, связанной с ошибками в реализации файловой системы, fsck не
>спасёт. Кроме того, так как fsck -- сам по себе программный
>продукт, а "last bug in our programs won't be corrected until
>last user is dead", _само по себе наличие_ этой утилиты отрицательно
>сказывается на надёжности хранения данных.
За 40 лет в UNIX сформировалось понятие об утилите fsck, - хрень
проверяющая целостность файловой системы.
То есть, нет, да и не может существовать, единого алгоритма проверки,
даже не алгоритма, а структуры самих метаданных. Так как способ их представления,
в каждой ФС, разные.
Из этого скромного вывода, можно сделать дугой - любой способ проверки ФС, по
определению можно назвать частью или целым fsck. И из этого же следует,
что этот кусок алгоритма, так же, может являться частью самой FS.
Так что, нужна ли fsck снаружи или внутри, это уже решают сами архитекторы ФС.
Собственно, для ISO9660/UDF, Squashfs, UBIFS, CIFS, и т.п., она тоже не нужна :)
| | |
| |
| 4.14, Andrew Kolchoogin (?), 15:47, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Из этого скромного вывода, можно сделать дугой - любой способ проверки ФС,
> по определению можно назвать частью или целым fsck.
Совершенно верно!
Так вот, в ZFS нет fsck ни внутри, ни снаружи. :) Вот так вот хитро она устроена: state файловой системы на диске consistent ВСЕГДА. В ЛЮБОЙ МОМЕНТ ОСТАНОВКИ РАБОТЫ ZFS. Это фича. :)
| | |
| |
| 5.27, User294 (ok), 07:05, 08/11/2009 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>ВСЕГДА. В ЛЮБОЙ МОМЕНТ ОСТАНОВКИ РАБОТЫ ZFS. Это фича. :)
А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят) - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот момент. Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или память, или хрен там знает чего еще...).
| | |
| |
| 6.32, аноним (?), 21:59, 08/11/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
> А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят)
> - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот
> момент. Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать
> если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг
> оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или
> память, или хрен там знает чего еще...)
Вы в очередной раз выглядите идиотом, не зная матчасть. Что бы там не сбойнуло, чексуммы это отловят и исправят, поэтому да - состояние всегда консистентное, если диски/контроллер не врут о завершении sync. Если врут, создать FS с какими-то гарантиями невозможно в принципе.
| | |
| |
| 7.35, User294 (ok), 01:33, 09/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Вы в очередной раз выглядите идиотом, не зная матчасть. Что бы там
>не сбойнуло, чексуммы это отловят
Это не вы там предлагали /dev/random на диск выгрузить? Если что сами посчитайте через сколько вам 2-байтный флетчер скажет что все зашибись хотя по факту это будет рандом. Как бы для 2-байтной чексумы - вероятнось неотлова далеко не ноль. А считать sha1 как бы накладно. Такая вот подлянка с чексумами, при том - она не только в zfs, а "вообще". Вы или попадаете что иногда простой чексумм лажается и невалидные данные могут быть приняты за валидные, или вынуждены использовать крутые (и сравнительно тормозные...) штуки типа sha с приличной разрядностью и низкой вероятностью коллизий.
>и исправят,
А это откуда следует? И главное - кто и на основе какого алгоритма произведет исправление? Где это описано?
>поэтому да - состояние всегда консистентное, если диски/контроллер
>не врут о завершении sync. Если врут, создать FS с какими-то гарантиями
>невозможно в принципе.
Всем похрену на ваши теоретизирования, когда дело доходит до практики. А на практике - если том рассыпался, нужен утиль который сможет его реанимировать до более-менее монтируемого и доступного состояния. Пусть частично потеряв какие-то данные, это всяко лучше чем выколупывать их исключительно дискэдитором с совсем не цепляющегося тома. Чем лучше такой утиль и чем он больше упирается до последнего в потугах хоть что-то на томе отколупать - тем лучше ФС с точки зрения админов и юзеров. И саночники пардон мягко говоря - неубедительны. Менее мягко говоря - я озвучил как этот подход называется, имхо.
| | |
| |
| |
| |
| 10.43, QuAzI (ok), 23:43, 10/11/2009 [^] [^^] [^^^] [ответить] | +/– | The blocks of a ZFS storage pool form a Merkle tree in which each block validate... текст свёрнут, показать | | |
|
|
|
|
| 6.36, Anon Y Mous (?), 11:58, 09/11/2009 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят) - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот момент.
Это вы технично передергиваете в этом моменте, а парни из Сана рекомендуют предоставить ZFS возможность контролировать уровень избыточности. Метаданные, помимо избыточности вроде зеркал или RAID-Z, хранятся в нескольких экземплярах (два или три) за счет использования дубль-блоков. Плюс, админы локалхоста могут включить дубль-блоки для своих данных даже на одном диске.
Так что, конечно, можно подкинуть бэд-секторов в неудачных местах, но для этого нужно, чтобы они попали во все копиии дубль-блоков, а это уже гораздо менее вероятно.
И потом, не будете же вы утверждать, что не существует набора неудачных бэд-блоков, которые приведут какую-нибудь ext3/ext4 в непригодное состояние?
> Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или память, или хрен там знает чего еще...).
Много бухтите тут, скорее, вы. Консистентность состояния на диске обеспечивается тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее сохранение этих консистентных состояних, это проблема этого диска. Так что повторяем еще раз - с головой даем ZFS контролировать уровень избыточности. А также смотрим сюда:
http://mail.opensolaris.org/pipermail/onnv-notify/2009-October/010682.html
Опять же, надеюсь, что вы не будете утверждать, что сбоящие процессор или память не могут привести другую файловую систему непригодное состояние.
| | |
| |
| 7.42, User294 (ok), 23:26, 10/11/2009 [^] [^^] [^^^] [ответить] | +1 +/– | Парни из сана судя по стилю спича просто технично прикрывают свои жопы и пиарятс... большой текст свёрнут, показать | | |
| |
| 8.50, yalur (ok), 23:01, 11/11/2009 [^] [^^] [^^^] [ответить] | +1 +/– | Когда вы ресет делаете на ext3 - данные негарантированно валидны, нада fsck ког... текст свёрнут, показать | | |
|
|
|
|
| 4.15, Andrew Kolchoogin (?), 15:50, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
> За 40 лет в UNIX сформировалось понятие об утилите fsck,
> - хрень проверяющая целостность файловой системы.
"Нет". (C)
fsck хоть и расшифровывается, как file system check, однако, check -- это лишь одна из её функций. Вторая -- восстановление consistent state файловой системы, если она повреждена.
| | |
| |
| 5.18, vitek (??), 20:42, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
правильно.
но второе не может быть без первого... вначале чек, а потом рековери. и никак иначе.
| | |
| 5.41, sshutdownow (ok), 15:50, 10/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >> За 40 лет в UNIX сформировалось понятие об утилите fsck,
>> - хрень проверяющая целостность файловой системы.
>
>"Нет". (C)
>
>fsck хоть и расшифровывается, как file system check, однако, check -- это
>лишь одна из её функций. Вторая -- восстановление consistent state файловой
>системы, если она повреждена.
а в xfs fsck тоже был return 0;
| | |
|
| 4.26, User294 (ok), 06:58, 08/11/2009 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>Собственно, для ISO9660/UDF, Squashfs,
А там то все просто - это read-only FS. Почему нет fsck? Потому что удачи тебе в записи исправленной ISO9660 на "штамповку" засунутую в сидюшник, ога :D. Оно исправляется, только иначе - отправкой сбоящего носителя в треш и покупкой нового взамен.
| | |
| |
| 5.29, pavlinux (ok), 09:43, 08/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Собственно, для ISO9660/UDF, Squashfs,
>
>А там то все просто - это read-only FS. Почему нет fsck?
>Потому что удачи тебе в записи исправленной ISO9660 на "штамповку" засунутую
>в сидюшник, ога :D. Оно исправляется, только иначе - отправкой сбоящего
>носителя в треш и покупкой нового взамен.
cat /dev/cdrom | fsck.iso9660 -af > fixed.img :)
| | |
| |
| 6.44, User294 (ok), 23:48, 10/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Угу, картина маслом - роутер у которого ВСЯ ФЛЕХА занята squash-ом - крайне типичный такой сценарий, в любом магазине вон куда ни ткни оно вот такое вот. И куда предлагается записать починеный вариант squash? :) В /dev/null чтоли? А то больше как бы и некуда особо. Поэтому никто и не парится - в случае нужды починки ФС делается полная переливка образа, вот и не надо squash-у никакого fsck. А если и перелить образ не получается - так вам в сервисник или на свалку. С цд - опять же исходный том read-only а потому починке не подлежит.
Вообще среди fsck обычно не принято писать результат починки на destination отличный от source, как минимум без специальных плясок с бубном. По вполне понятным причинам (а кто сказал что destination вообще существует и там достаточно места и что кто-то хотел именно такой результат?).Собссно если том только для чтения, его починка - оксюморон.
| | |
| |
| 7.45, pavlinux (ok), 04:31, 11/11/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
>Угу, картина маслом - роутер у которого ВСЯ ФЛЕХА занята squash-ом -
>крайне типичный такой сценарий, в любом магазине вон куда ни ткни
>оно вот такое вот. И куда предлагается записать починеный вариант squash?
>:) В /dev/null чтоли? А то больше как бы и некуда
>особо. Поэтому никто и не парится - в случае нужды починки
>ФС делается полная переливка образа, вот и не надо squash-у никакого
>fsck. А если и перелить образ не получается - так вам
>в сервисник или на свалку.
Cижу в тундре, до ближайшего телефона 300 км на оленях, самолёт
летает 2 раза в год. А данные сейсмологических исследований надо
писать раз в день. А тут прибор накрылся, но его можно загрузить
с сервисного диска, а тот сццука от мороза покорёжило, правда не весь,
а только начало, а прошивка всего 8 мегоф. Вот если бы прогнать через
fsck.iso9660, может удаться её спасти. Я б в ручную записывал, но 1 день
логов это примерно 200 листов A4 =) А нам выдали только одну упаковку.
Туалетной мало - 53 метра x 15 недель:( Да и карандаш всего один.
Из-за сильной ионизации атмосферы в полярную ночь, никакие беспроводные
связи не работают. Осталось только ловить моржей, медведей и оленей,
делать из них пергамент, и писать их жиром с сажей. (ну или кровью) :)
Ещё вариант, научить почтового баклана, чтоб с флэшкой летал до центра,
но где же я в полярную ночь поймаю баклана. :(
| | |
|
|
|
|
|
| 2.25, User294 (ok), 06:52, 08/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Потому что ZFS создали Боги, и в ней нет ошибок и багов,
>а данные, с вероятностью 1, нельзя потерять.
Пусть они если такие умные, расскажут: что делать при серьезном разрушении метаданных ФС? И кто сказал что при этом удастся без ошибок откатиться к снапшоту? Они так много пиндят про CoW но ни звука не издают что делать если метаданные достаточно хардкорно посыпались.
В идеале, FSCK должен прогуляться по ФС и провалидировать метаданные на осмысленность и логическую корректность и перестроить то что явно порушено или хотя-бы попытаться нейтрализовать вред от заведомо невалидных метаданных, хотя-бы убив их. Да, часть данных может быть утеряна. Но ФС с хоть какими-то частично доступными данными - это лучше чем немоунтабельная ФС откуда данные не получить вообще НИКАК кроме разве что диск-эдитора. В итоге звучит весь этот спич в духе "маркетологи вещают про панацею - CoW".
| | |
| |
| 3.33, аноним (?), 22:03, 08/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Пусть они если такие умные, расскажут: что делать при серьезном разрушении метаданных
>ФС? И кто сказал что при этом удастся без ошибок откатиться
>к снапшоту? Они так много пиндят про CoW но ни звука
>не издают что делать если метаданные достаточно хардкорно посыпались.
И откуда же возьмется "хардкорное нарушение"? Любое нарушение integrity (cat /dev/random >/dev/ad*) отловят чексуммы, поэтому битые метаданные не будут использованы _никогда_. Посему достаточно взять самый последний из 128 уберблоков, ссылающихся на консистентные метаданные, и все. Прекратите пукать, и опишите по пунктам конкретную ситуацию, с которой, по-вашему, ZFS не справится.
| | |
| |
| 4.34, User294 (ok), 01:18, 09/11/2009 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Мне не понравилось вот что: саночники очень упирают на природу CoW и на то что консистентность - есть. Не утруждаясь объяснениями того а что будет если консистентности вдруг нет. Это выглядит сочинением маркетологов на тему "почему у нас нет fsck" смысл которого сводится к "да вы не волнуйтесь, мы лучше знаем что вам нужно". Ну, как обычно, собственно - все маркетологи одинаковы.
Насчет "_никогда_" ... погодите, а там по дефолту вроде весьма слабые чексуммы, всего 2 байта. Через сколько они сдадутся рандому с его грубой силой - калькулятор освойте, а потом расскажете как там 2-байтный чексумм нам гарантирует "никогда". А SHA1 считать в реалтайме вы подзаботаетесь пожалуй, в плане нагрузки от этого действа на проц (для недефолтного sha-1 допущение про "никогда" еще можно засчитать с его разрядностью хэша).
А не справится... ну а как насчет ситуации когда на диск пишется не то что посчитано и предположено? Саночники много пиндят про кривое железо и какое оно ... .Но ни звука не говорят - а что же все-таки делать в таких случаях. Грубо говоря - возникает ощущение что это маркетологи пытаются успокоить клиентов или типа того. Ну, сан вообще в довольно нахальном пиаре был замечен в последнее время, где больше макарон на уши чем по делу.
| | |
| |
| 5.49, yalur (ok), 22:37, 11/11/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
>Мне не понравилось вот что: саночники очень упирают на природу CoW и
>на то что консистентность - есть. Не утруждаясь объяснениями того а
>что будет если консистентности вдруг нет. Это выглядит сочинением маркетологов на
Как же до вас туго доходит:
Консистентность - подразумевается, что при работе на исправном железе, ФС постоянно находится в консистентном состоянии и БАСТА. ОНА ВСЕГДА КОНСИСТЕНТНА. НЕТ ТАКОГО ПОНЯТИЯ ВООБЩЕ - НЕКОНСИСТЕНТНАЯ ФС - ДЛЯ ДАННОГО СЛУЧАЯ.
Если проблемы с железом/бб - это уже другой случай. Никак не относится к понятию консистентности. Это повреждение ФС, и при возможности идет востановление данных (если есть резервные копии). если их нет - ДА, ДА, И ЕЩЕ РАЗ ДА. ЭТО ХАНА, ТОРБА, если хотите ЖОПА, если у вас нет бекапа. Так вас устраивает? И вообще чем вы думаете? Если блок испорчен и нет резервной копии, то никакая ФС, даже богом написанная вам не поможет. Если вам руку отрезать - fsck поможет?
| | |
|
|
|
|
| 1.2, Аноним (-), 10:30, 07/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
есть перевод статьи?
p.s. с английским туго, прогуливал уроки сидя в информатике
| | |
| |
| 2.7, Andrew Kolchoogin (?), 11:34, 07/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> zpool scrub poolname — и прочувствуйте фоновую проверку. :)
Почувствуйте школоту, не читавшую документацию.
Команда "zpool scrub" проверяет пул на целостность. То есть, грубо говоря, читает каждый занятый блок пула, считает его контрольную сумму и сравнивает с записанной на диске. С помощью команды "zpool scrub" делается то же самое, что и с помощью, фактически, утилиты "diskdefect" в ранних версиях BSD. Утилита "fsck" никакого отношения к работе команды "zpool scrub" не имеет -- в том месте, где "zpool scrub" обнаружит ошибку и попытается отрекаверить блок, "fsck" вывалится с мерзкими криками: "UNEXPECTED INCONSITENCY: CAN'T READ BLK xxx".
| | |
| |
| 3.19, vitek (??), 20:49, 07/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
перефразирую - т.е. если "отрекаверить" не получится, то "zpool scrub" очень тактично намекнёт, что восстановить не получилось....
не то что эта фсчк с мерзкими криками.... просто ни каких сравнений.
| | |
| |
| 4.48, yalur (ok), 22:22, 11/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>перефразирую - т.е. если "отрекаверить" не получится, то "zpool scrub" очень тактично
>намекнёт, что восстановить не получилось....
>не то что эта фсчк с мерзкими криками.... просто ни каких сравнений.
>
да, неполучится, неполучится. Как вы собираетесь востановить то, на что нет резервных копий. Но мы покрайней мере знаем что есть проблема. При этом он напишет какой именно файл задевает этот блок и там вы уже себе решаете что делать. Хоть бекап хоть еще как. fsck может даже не ругнуться, тогда как zfs всегда обнаружит сбой, а если есть хоть одна копия, то востанавливает ошибку.
| | |
|
| 3.31, iZEN (ok), 18:02, 08/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Почувствуйте школоту, не читавшую документацию.
Молчали бы уж лучше в тряпочку и не говорили полной ерунды тому, кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2.
И fsck (на UFS2), и scrub (на ZFS) — обе начинают проверку ФС в ФОНЕ, но при работе scrub, в отличие от fsck, пользоваться компьютером просто не хочется из-за невыносимых тормозов.
>Команда "zpool scrub" проверяет пул на целостность.
А ещё масло масляное.
>где "zpool scrub" обнаружит ошибку и попытается отрекаверить блок, "fsck" вывалится с мерзкими криками: "UNEXPECTED INCONSITENCY: CAN'T READ BLK xxx".
Бред. На FreeBSD fsck никуда не вываливалось, а просило: "SALVAGE? Y/N".
| | |
| |
| 4.47, yalur (ok), 22:13, 11/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>кто это имел при неудачных обесточиваниях компа с FreeBSD 6.1...8.0-RC2.
>И fsck (на UFS2), и scrub (на ZFS) — обе начинают проверку
>ФС в ФОНЕ, но при работе scrub, в отличие от fsck,
>пользоваться компьютером просто не хочется из-за невыносимых тормозов.
Бред, никогда scrub в фоне при загрузке компа (как это есть с fsck) не запускается.
| | |
| |
| 5.53, iZEN (ok), 23:34, 12/11/2009 [^] [^^] [^^^] [ответить] | +/– | Что касается scrub, то да, действительно он сам не начинает проверку после внеза... большой текст свёрнут, показать | | |
| |
| 6.54, iZEN (ok), 00:00, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Спустя 26 минут от начала проверки:
% zpool status amd64rio
pool: amd64rio
state: ONLINE
scrub: scrub in progress for 0h26m, 12,41% done, 3h6m to go
config:
NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/rio_zfs2 ONLINE 0 0 0
gpt/rio_zfs1 ONLINE 0 0 0
errors: No known data errors
Курсор в Xfce ни разу не замер, что удивительно. Однако отклик GUI происходит "урывками" — то замирает на 5 секунд, то потом отмирает и быстро воспроизводятся проделанные действия — добирается слово, набранное с клавиатуры, открывается меню при выборе пункта меню мышкой и т.д. Как-будто киноплёнка притормаживается на секунды, а потом быстро прокручивается до нормального состояния.
Работать можно, но неприятно.
| | |
|
|
|
|
| 2.40, Stop scrubbing (?), 14:47, 10/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
zpool scrub [-s] pool ...
Begins a scrub. The scrub examines all data in the specified pools
to verify that it checksums correctly. For replicated (mirror or
raidz) devices, ZFS automatically repairs any damage discovered
during the scrub. The "zpool status" command reports the progress
of the scrub and summarizes the results of the scrub upon comple-
tion.
Scrubbing and resilvering are very similar operations. The differ-
ence is that resilvering only examines data that ZFS knows to be
out of date (for example, when attaching a new device to a mirror
or replacing an existing device), whereas scrubbing examines all
data to discover silent errors due to hardware faults or disk fail-
ure.
Because scrubbing and resilvering are I/O-intensive operations, ZFS
only allows one at a time. If a scrub is already in progress, the
"zpool scrub" command terminates it and starts a new scrub. If a
resilver is in progress, ZFS does not allow a scrub to be started
until the resilver completes.
-s Stop scrubbing.
| | |
|
| 1.5, ffsdmad (ok), 10:55, 07/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 а скоро заметки про ZFS будут начинаться так
> один из инженеров Oracle опубликовал < | | |
| |
| 2.10, sHaggY_caT (ok), 13:32, 07/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
В Oracle будет и ZFS, и btrfs, ocfs, lustre... Не много ли на них одних :)? Остальным остается, из вкусного и инновационного, gfs, проприетарный gpfs IBM (хотя, конечно, он очень вкусен, есть уже сейчас, и, во многом интереснее ZFS/brtfs, если, конечно, теплое может быть интереснее мягкого) и.. кучка новеньких пионерских ФС, и все..?
У Оракля монополия на файловые системы :)?
| | |
| |
| 3.28, User294 (ok), 07:12, 08/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>У Оракля монополия на файловые системы :)?
Не раньше чем монополия на mainline ядро и всех разработчиков комитящих в ФС :P. Но задавать вектор развития - пожалуй сможет, если захочет.
| | |
|
|
|
