имхо е3 отстой, и нафиг никому не нужна. Нельзя, опираясь на стрые взгляды, создать что-то принципиально новое и крутое. сколько уже тянется ее разработка? а уже ведь есть вполне работоспособные xfs (ну и так уж и быть, рейзер). JFS вон тоже не за горами...
To Bluesman: Хороша Альфа, если работает стабильней некоторых релизов.
2All: Да и вобще я что-то устал отвечать на подобные заявления, если люди не вопринимают должным образом объективную действительность, то я понимаю почему ТАКОЕ качество продуктов MS.
Чем клепать толпу разных файловых систем лучше бы объеденились над одним, но самым перспективным проектом. На мой взгляд это XFS.
И довели бы ее до уровня возможностей NTFS5 хотя бы.
"А Linux вообще - одна большая альфа версия. Которая бетой никогда не станет, т.к. пихают в нее
новые фичи, не отлаживая старые."
Это уж точно... :-(
"И Windows - тоже альфа версия тогда. Там постоянно появляются какие-то SR1, SR2, SR3 ..."
Я не знаю что такое SR...но вот SP's (Service Pack), наверно ты их имел ввиду, как раз исправляют ошибки, а нового ни чего особенного не вносят.
2 Direct (*) (2001-06-08 11:21:34.0)
Нашел чем хвастаться "исправляют ошибки, а нового ни чего особенного не вносят."
С твоих слов получается, что если новое понадобится то его через
Service Pack не внесут, а выпустят новую версию за отдельные $$,
разумеется. Разумеется это даже в MS не совсем так.
IMHO, это одно из идеологических достоинств unix, что сильные
изменения можно изолированно пачить.
2 Eugeny Balahonov (*) (2001-06-08 11:13:40.0)
А может и разработчиков NSFS попросить присоединиться :)?
Извини, легче принять стандарт файловой системы, чем убедить
крупные и уважаемые коллективы сотрудничать.
2All
Поживем увидим. Я и первый релиз (не говоря об альфах и беттах)
побоюсь ставить. Но reiser мне нравится больше за открытость и идеи,
а Xfs за надежность. Rowdev не нравится вообще, но он самый быстрый.
Расскажите плиз что в NTFS5 есть такого, чего к XFS будет сложно прикрутить. Что XFS действительно хуже NTFS5 (и Win лучше IRIX, а почему SGI не перешло не NT? )?
Кстати, а за каким хреном эти патчики включены в ядро от RH7.1? Совсем
красношляпые крэнканулись?
Antichrist (*) (2001-06-08 13:21:55.0)
Неа. Они же специально разрабатывали ext3 "для себя". Теперь оно
достигло той фазы когда без широкого тестирования глюки не
выявишь. Это как Suse с reserfs.
И Линус кстати, когда ему предложили это включить в 2.3 им так и
сказал - обкатайте мол в своем дистрибуте, а потом и будем думать.
Так что все логично и никто не рехнулся.
прикрутить. Что XFS действительно хуже NTFS5 (и Win лучше IRIX, а
почему SGI не перешло не NT? )?
cornholio (*) (2001-06-08 13:12:29.0)
А они пытались. И сильно. С тех времен даже NT (3.51 вроде)на MIPS
остался. Но судя по всему они поняли что их ожидает судьба
DEC если они будут продолжать так и дальше.
Кстати , к знатокам - есть NT 4.0 для MIPS
или уже нет ?
Frйdйric L. W. Meunier:
"If you still don't know, there are ext3 patches for 2.4. I'm using 2.4.5 without any problems. ext3 will be the standard, not ReiserFS or XFS. I'm not asking the developers to include support for ext3.
http://www.uow.edu.au/~andrewm/linux/ext3/
And you can subscribe to the ext3 mailing-list here:https://listman.redhat.com/mailman/listinfo/ext3-users/."
dolphin,
бульк:)
Во. Карячился-карячился Райзер, а ему - хлобысь по ушам. ext3 будет стандартом. Как только выйдет ext3 (если вообще смогут довести ее до работоспособного состояния), лавочку Райзера можно будет закрывать.
2kernel: есть NT4 for MIPS. Но не поддерживает сто лет как - последний SP3 чтол был...
2BlackRabit: я если честно не готов сравнивать XFS & NTFS5... К слову может подскажишь где про XFS, про ее структуру и т.д. почитать можно? А пока пара вопросов:
1. Насколько я понял потоков в ней нет? Но это действительно можно добавить при желание - имхо не слишком трудно...
2. Поддержка сжатия файлов " на лету" есть?
3. Криптование файлов есть?
4. Как вообще под линуксом делается что-то аналогичное динамическим томам в нте?
Про ACL, квоты и журнал понятно что все есть...:) Понятно также что проблем с ограничением на размер файла, как до недавнего времени ext2 тоже нет...:)
2Bluesman: Райсер тоже не спит - я читал его планы, он вроде собирается многопоточность прикручивать...:) С другой стороны возмуться делать ext4...;) Если доживут...:)
2 Irsi: Да он пусть это сначала отладит. Так и не удалось решить проблемы с data corruption, насколько я знаю. Не делаются такие вещи под пивом и на коленке. Тут метода нужна, мудрые люди и много денег.
1. Насколько я понял потоков в ней нет? Ну и нахрен они нужны? Где реально используются? Понятно, что в теории всё красиво, а на практике никто не использует - даже ваши любимые Windows (9x, NT) и ничё, оказыватеся можно жить, как бы Irsi не уверял в обратном ;0)
2. Поддержка сжатия файлов? Тоже сомнительная фича, особенно в свете постоянного уменьшения цены за мегабайт.
Как вообще под линуксом делается что-то аналогичное динамическим томам в нте? Правильней другой вопрос - есть ли нте что-то подобное LVM?
Понятно также что проблем с ограничением на размер файла, как до недавнего времени ext2 тоже нет. Здесь тоже срамимся - У ext2 ограничений на размер не было, они были у ядра.
Кроче последовательность такая;
RTFM
Постим комментарий.
Если вы в глубине души мазохист, можете придерживаться прежнего стиля.
2 Irsi (*) (2001-06-09 01:36:51.0)
Что такое динамические тома -- что это такое, кинь ссылку я посмотрю.
Сжатие отдельных файлов -- посмотрю, проверю и отпишу, но
я его прикручивал (стыдно вспомнить как) еще в slackware 1.2.???.
Вообще, лично мне если и было нужно, то не конкретно сжатие,
а триггер с произвольной внешней функцией на creat|read|write|unlink
на персонально обозначенные файлы.
Такого, к сожалению, ни у кого нет, а на ntfs у меня не получилось (теоритически я знаю как -- ума в ручках не хватило, за то в ddk
поковырялся).
2 rabbit (*) (2001-06-09 06:20:42.0)
На счет потоков -- это как электростеклоподъемники в тачке --
премет некой гордости производителя и небольшой комфорт для водителя.
Очень мало приложений им пользуется, но прикрутить не сложно.
Тем не менее можно включить в зачет по плюсам и минусам.
Сжатие файлов на лету нужно, по крайней мере, в ряде
[коммуникационных] финансовых программ -- объемы исчисляются гигабайтами, файлы или текстовые и легко жмутся или с дырками, а
обслужывают их старые 486-P1, куда большие диски ставить жалко.
Не совсем понимаю о чем спич :)) У меня Reiser крутиться на встроенных компах уже месяца три, и их перегружают кнопкой питания (чтобы например перенести аппарат в другое место). Хоть бы одна проблема была =))) И вряд ли я стану использовать что то другое и за сексапильной многопоточности или других возможностей.
Я кстати так и не понял в чём суть динамических томов под НТ :-)
Но вот что со мной было:
Принесли как-то нам в контору винт от МД2000 как раз с
динамическими томами. Какой-то товарищ поформатировал ФАТовый
диск С и динамический том на d: похерился. Попросил он восстановить
ио :-). Ну первым делом воткнули его в МД2000 - нифига, не видит
она свои родные динамические тома :-). Потом пробовали всякими
ПыКумагиками и еже с ними тип файловой системы изменить чтобы данные
оттудова содрать на другой ХДД. В итоге последняя их надежда осталась
на мой бедный Линукс, которому даже подышать обычно не дают (очень
редко есть возможность его грузить, там в основном НТ ВС работает).
Ну блага я как умный Вася давно на всякий случай скомпилил поддержку
НТФС и примонтировал и скопирова и русские имена и всё на свете
получилось. Без всяких док за 5 минут запустил копирование (13 Гиг)
Всё получилось замечательно, нам (вообще-то надо было только мне) дали
100 рублей и коньяк поставили %-))) Коньяк я так свой и не попил ...
Без меня его съели ... но это уже другая история %-)
Вот как на динамических томах M$ можно деньги зарабатывать %-)
2Warmonger: "Какой-то товарищ поформатировал ФАТовый диск С и динамический том на d: похерился...надежда осталась на мой бедный Линукс"
Идите сказки рассказывать в другое место. У него в лучше случае была простая NTFS с испорченным Partion Table. Линукс драйвер НТФС не поддерживает динамические тома (тем более в случае "давно на всякий случай").
2rabbit: "1. Насколько я понял потоков в ней нет? Ну и нахрен они нужны? Где реально используются?"
Они используются EA
"2. Поддержка сжатия файлов? Тоже сомнительная фича"
Кроме сжатия файла, есть еще его шифрация и если вдруг диск утянут, то файл все равно останется не прочитанным.
Я тоже Вам желаю сделать RTFM на счет динамических томов, прежде чем сюда писать :)
PQmagic так сказал :-))) Это не я придумал, так же и сами хозяева винта сказали.
НТФС быраспознался МД2000 , но она не смогла ничё сделать с родной системой :-)
Так что вот ! :-) Я не красноглазый ... не очень :-) Я не знаю чё там под-
держивается или нет от M$, я просто взял и попробовал - получилось.
P.S./нам дали 100р + коньяк + коробку конфет, правда ничё из этого мне не досталось :-)
и в этом виноваты поклонники M$, которые всё без меня сожрали!!!/
Много разных FS - это хорошо. Вообще, производительность и надёжность файловых
систем - штуки дико эмпирические, формализации не поддающиеся, и, соответственно,
чем больше разных идей будет реализовано тем больше ценных экспериментов можно будет
поставить, что рано или поздно приведет и к созданию Самой Правильной Файлухи.
2Warmonger: "PQmagic так сказал"
Ну PQMagic и не такое может сказать...
"НТФС быраспознался МД2000 , но она не смогла ничё сделать с родной системой"
chkdsk нужно было запускать. А то что линукс выдел этот раздел меня не удивляет, т.к. драйвер в линуксе работает с НТФС как б-г на душу положет, не случайно не рекомендуют использовать этот драйвер для записи на НТФС, а если уж занисал чего-нить, то просят запускать chkdsk из-под W2K. Просто для примера, в свое время популярно было востанавливать диску с помощью Нотрон Утилиты, потому как там можно было сразу по секторам бегать, но ни кому в голову не приходило говорить, что NU работали лучше чем FAT драйвер в дос'e
> не случайно не рекомендуют использовать этот драйвер для записи
А где ты прочитал, что он писал на NTFS? Он только читал диск. Да, на запись
не рекомендуется, а читать можно. Кстати это не единственный пример, когда
линукс спасает мастдайные проколы. Я помню, как мастдайный fdisk ни черта
не мог определить на диске. Выручила только аварийная дискетка с линуксом на
которой был линуксовый fdisk.
Ребята, кончайте отходить от темы.
А что вынь не может работать с файлами даже в фате по всем своим семействам,
когда попадает случайно в случае ошибки самой например винды минус в начало или коды не от ср866,
когда линь их берет - это факт. с нтфс5.0 с включеной компресией он у меня мало взял -
ядрышко я не менял давно (2.2.14)- не смейтесь, я спокойно живу на патченом РХ6.1...
А что касается динамических томов - реальных динамических томов - то это реализовано в LVM
в оригинале в Оси/2(4.5 ака Аврора). но мне динамика сейчас не нужна и как я понял -
динамические тома не прописываются в мбр табле а где-то еще... там же пробовал jfs.
всегда стараюсь попробовать фс и прочие расширения(лвм) там, где они изначально реализованы,
их я там видел 2 года назад (с января 99 года, с бетой авроры).
в моей практике журнал.фс не спасали, что jfs, что ntfs, когда идет отображение файла в памяти,
а на фате и ехт2 проносило... они проще, меньше за что-либо зацепиться и #держался, держался и
рухнул(с)ирония судьбы или с легким паром#.
2zelya: да, ты правильно понял - динамические тома кладут с высокой колокольни на такую мягко говоря устаревшую древность как партишн тейбл.
Впрочем мелкософт и не скрывает того факта что свои диномические тома они лицензировали у VERITAS Software... Изначально конторка делала софт для коммерческих юниксов к слову...
loopback device с DES шифрованием и все дела. RTFM батенька, это для вас! ;0)
По поводу сжатия - ключевое слово e2compr. Правда есть сомнения, поддерживается ли это в 2.4.x
А насчёт динамических томов вам тут популярно объяснили пару месяцев назад, что динамические тома в NT весьма недоразвиты по сравнению с LVM, и вы это признали. Что-то с памятью вашей стало.
Необходимость многопоточных ФС сомнительна, если без них обходится 90% десктопов
Вот почитал тут, несколько мыслей возникло.
1. Каталог с файлами - не тоже ли самое, что многопточный файл?
С той только разницей, что всем без исключения приложениям и
пользователям видно, с чем реально они имеют дело, и не возникает
путаницы типа копирования только одного потока. Так что по-моему
потоки - бзик M$
2. Насколько я понял, Ext3 есть Ext2 с прикрученным журналом.
Безусловно прогресс, структуры каталогов этой ФС по нынешним
временам скоростью не отличаются, хотя и вполне приемлемы. Всё-таки
рейсер в этом вопросе дальше продвинулся. Хотя у Ext3 плюс -
обратная совместимость.
3. И почему все уверены, что можно создать самую правильную ФС?
И что любые альтернативы - полный отстой.
Единственное, что тут по-моему реальный отстрой - это такие
подходы, основанные на крайностях. А ФСы пущай развиваются.
2anonymous (*) (2001-06-14 09:42:27.0): ну во-первых потоки не бзик мелкософта. Урезаная реализация многопоточной FS поддерживается в MacOS и насколько я помню в OS/2, полная - NT/2k, BeOS, QNX6... Так что...
Далее - решение, похожее на твое применяется в MacOS при копировании ее файлов на FATовские диски. В качестве неприятных эффектов - регулярно теряется resorce fork (просто забывают скопировать), потребляемые ресурсы растут очень быстро вызывая тем самым изрядные тормоза. Если первое можно сказать "проблемы юзера", то второе увы...
С другой стороны для реализации поддержки потоков надо всего лишь разрешить для записи в каталоге ссылаться не на одну i-node, а на несколько... Разумеется это вызывет некоторые проблемы с совместимостью, но не слишком серьезные. Для "старых" утилит можно эмулировать твой подход или нечто аналогичное (есть по крайнеймере еще два варианта.)
> ну во-первых потоки не бзик мелкософта. Урезаная реализация многопоточной
> FS поддерживается в MacOS и насколько я помню в OS/2, полная - NT/2k, BeOS,
> QNX6... Так что... Далее - решение, похожее на твое применяется в MacOS при
> копировании ее файлов на FATовские диски. В качестве неприятных эффектов -
> регулярно теряется resorce fork (просто забывают скопировать), потребляемые
> ресурсы растут очень быстро вызывая тем самым изрядные тормоза. Если первое
> можно сказать "проблемы юзера", то второе увы... С другой стороны для
> реализации поддержки потоков надо всего лишь разрешить для записи в каталоге
> ссылаться не на одну i-node, а на несколько... Разумеется это вызывет
> некоторые проблемы с совместимостью, но не слишком серьезные. Для "старых"
> утилит можно эмулировать твой подход или нечто аналогичное (есть по
> крайнеймере еще
> два варианта.)
Мне представляется, что тут всё-таки нехорошесть другого рода. Что есть
многопоточный файл? Объект ФС с несколькими потоками данных внутри. Что
есть каталог? Объект ФС с набором произвольных именованных объектов
ФС внутри. Среди которых могут быть и потоки данных (т. е. обычные
файлы). Спрашивается, зачем гордить частный случай уже имеющейся
сущности?
А городят по причине того, что слишком многие проги не желают до конца
понимать сущность каталога. То, что, например, копирование содержимого есть
часть копирования каталога, для большинства копировщиков является "левым"
режимом, требующим для включения дополнительных опций. Конечно, можно
сказать, что "так сложилось" ... Но теперь добавляем понятие многопоточного
файла. И опять имеем кучу софта, кторый это дело недопонимает, потому
что привых ассоциировать файл с одним потоком. То есть заменяем один
маразм на другой.
Я не вижу простого выхода, но аргументы в пользу усложнения ситуации
мне не нравятся.
2anonymous (*) (2001-06-16 14:29:09.0): а кто сказал что будет легко...:)
Вообщем-то многопоточные файлы это всего лишь еще один шаг по пути к слиянию искуственно разделенных понятий - BD & FS...
А вообщем что делать - компы расширяют область своего применения, появляются новые классы задачь, для эффективной реализации которых нужны новые решения. Дело в том что принципы организации и структуры FS типа ext2, ufs и им подобных сформировались еще в конце 70х годов и для решения того класса задачь, которые тогда решались на компьютерах они подходили очень хорошо... Но с тех пор много изменилось...