The OpenNET Project / Index page

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

Оценка производительности файловых систем

26.03.2008 09:55

Евгений Поляков провел серию нагрузочных тестов файловых систем в Linux. Для оценки производительности были использованы пакеты dbench, iozone и postmar (эмуляция SMTP сервера, разбор maildir), а также измерение скорости операций с большим числом мелких файлов. Тестирование проводилось в Linux с ядром 2.6.24.3. Результаты наглядно представлены в виде графиков.

Ниже список файловых систем и использованных флагов форматирования и монтирования:

  • XFS: mkfs: -d agcount=1 -l size=128m,version=2, mount: noatime,logbsize=256k, as suggested by Dave Chinner
  • EXT4: mount: data=writeback,noatime,extents
  • EXT3: mount: data=writeback,noatime
  • EXT2: mount: noatime
  • JFS: mount: noatime
  • REISER4: mount: noatime
  • REISER3/REISERFS: mkfs: --format 3.6, mount: noatime
  • BTRFS: mkfs: -l 4k -n 4k, mount: noatime,nodatasum, для теста postmark была добавлена опция ssd.

Некоторые интересные моменты:

  • reiser4 практически блокировала работу системы при нагрузке в 150-200 потоков в тесте dbench;
  • btrfs и reiser4 оказались очень медленными при выполнении операций создания и записи в большое число мелких (4Кб) файлов;
  • Reiser4 оказалась в два раза быстрее btrfs, в тестах на выполнение последовательности операций creates/writes/syncs/closes выполненных поочередно для 10-30 тыс. файлов;
  • Ext4 оказалась медленней, чем ожидалось.
  • При использовании Linux ядер новее 2.6.20 для всех ФС наблюдалось ухудшение результатов измерения производительности при создании большого числа файлов.
  • Тест Postmark, эмуляция почтового сервера: победители: btrfs и reiser4, при большом числе файлов и директорий лидировать начинает ext4dev;
  • Тест iozine: в большинстве измерений победитель reiser4, остальные ФС держатся очень близко, но зависимость сложная, оценить можно только наглядно, по графику. В среднем очень неплохо показала себя JFS.
  • Тест Dbench: с большим отрывом лидирует ext2, далее следуют ext3 и ext4. reiser4 не прошла тест, машина повисла. reaiser3, btrfs, jfs и xfs, на средней нагрузке раз в 5 отстают от ext3, но зато ведут себя более стабильно при увеличении нагрузки, производительность остается примерно на одном уровне;
  • Измерение скорости создания мелких файлов: reiser4 и btrfs существенно отстают, лидирует ext2, остальные показали достаточно близкие результаты.

Уточнение: опубликованы результаты дополнительного тестирования XFS с опциями "mkfs -d agcount=75 -l size=64m" и примонтированной с параметрами "logbufs=8,nobarrier,noatime,nodiratime,osyncisdsync". В результате XFS продемонстрировала ощутимо более высокие показатели.

  1. Главная ссылка к новости (http://tservice.net.ru/~s0mbre...)
  2. Filesystem contest - прошлое сравнение производительности
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/14872-linux
Ключевые слова: linux, disk, banchmark, xfs, ext2, ext3, reiserfs, jfs, ext4, test, speed
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:08, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так это что получается, резер4 самы стабильный чтоли?
     
     
  • 2.2, Kido (?), 10:15, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Так это что получается, резер4 самы стабильный чтоли?

    Reiser4 - довольно быстрая, но требовательная к железу фс - это да, а вот на счет стабильности... Судите сами - ее даже в ванильное ядро до сих пор не включили.

     
     
  • 3.35, Lindemidux (??), 21:39, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Так это что получается, резер4 самы стабильный чтоли?
    >
    >Reiser4 - довольно быстрая, но требовательная к железу фс - это да,
    >а вот на счет стабильности... Судите сами - ее даже в
    >ванильное ядро до сих пор не включили.

    А теперь вспоминаем ... где сидит Райзер.

     
  • 2.22, Аноним (22), 12:25, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Так это что получается, резер4 самы стабильный чтоли?

    Для слепых - да.
    Какая стабильность, если она в одном тесте повесила машину?

     

  • 1.3, Konwin (ok), 10:15, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно было бы посмотреть еще на результаты ZFS
     
     
  • 2.8, fresco (??), 10:53, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    На железе, которго не хватает даже reiser4, думается, ZFS тестить бесполезно.
     
     
  • 3.11, Konwin (ok), 10:59, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >На железе, которго не хватает даже reiser4, думается, ZFS тестить бесполезно.

    Солярка не настолько уж и требовательна....


     
     
  • 4.16, fresco (??), 11:20, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Солярка не требовательна, а ZFS -- да. Работать она, конечно, и на 512 Mb RAM будет, но ни о какой производительности тут речи быть не может.
     
  • 3.29, Аноним (-), 14:50, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >На железе, которго не хватает даже reiser4, думается, ZFS тестить бесполезно.

    4-way Xeon с 4 гб памяти и сказевыми 10к дисками? Думаю, что вполне достаточно.
    Reiser4 просто вешал машину под большой нагрузкой, как написано в блоге.

     
     
  • 4.41, fresco (??), 08:36, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Принято. Че-т пропустил железо-то...
     

  • 1.4, vitek (??), 10:42, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну вот теперь пусть апологеты и скажут чем reiser лучше ext.
    лично я для себя давно решил - для aplication серверов - ext3 (и для файловых)
    для б/д - ext2
    тем более, что это можно подтюнить
     
     
  • 2.25, fresco (??), 13:00, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Че тут говорить...
    Чушь это все. Я у себя никогда таких результатов не получал. И самодельными софтами тестил, и dbench'ем этим. Никогда ext2/3 на моих машинах не выигрывали (ну, только если у ufs2).

    Повторюсь -- бенчмарки ФС дело исключительно субъективное, ОЧЕНЬ многое зависит от параметров машины (в т.ч. от очень экзотических, вплоть до сочетания объема RAM с размером аппаратного кэша жесткого диска и скоростью шины) и от типов данных. Посему у всех по-разному выходит. И неожиданные результаты, которые часто называют проплаченным пиаром, следствие именно грамотного подбора условий, идеальных для конкретной ФС.

    Вообще сегодня трудно говорить о "производительности ФС" в чистом виде -- слишком много разнородных задач, слишком разнятся аппаратные мощности. ИМХО, в оценке ФС не стоит идти дальше довольно абстрактного кртитерия общего архитектурного совершенства, который позволяет лишь с некой вероятностью предсказать, какая ФС покажет наилучшие результаты в данных конкретных условиях.

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

     
     
  • 3.34, Аноним (22), 17:35, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Че тут говорить...
    >Чушь это все. Я у себя никогда таких результатов не получал.

    О-ло-ло! Ты не _ш_могла - значит всё - чушь?
    Замерить все метрики мира только его творцу под силу, потому автор сделал то что под силу человекам - зафиксировал некоторые параметы и выдал на гора некий срез реальности. Так что на той машине с тем ядром - картина такая! Тест как тест - всё нормально.

    PS: Кстати - за исключением совсем уж неважных показателей XFS - совпадает с моей картиной мира. Хотя железо и ядро у меня были другие ...

    PPS: Но вот что радует - так это то что JFS на всех виденных мной тестах показывает своё качество! Оно рулез! Как то незаметно и постепенно _все_ мои линукс боксы ушли на неё :)

     
     
  • 4.40, fresco (??), 08:35, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Херня. Тут десятки таких новостей пробегают за год -- кто-то где-то потестил файловые системы. Результаты у всех разные. Сказано совсем не к тому, что аффтар мудак, а к тому, что в других условиях результаты могут оказать совершенно иные. И делать выводы из чьих-то бенчмарков -- дело пустое, если не опасное.
     

  • 1.5, Аноним (5), 10:43, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    zfs в линуксе не работает, тестировать пришлось бы на солярке, а это не кошерно.
     
     
  • 2.7, vitek (??), 10:52, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >zfs в линуксе не работает, тестировать пришлось бы на солярке, а это
    >не кошерно.

    теперь она уже есть и на bsd, и на macos'и

     
     
  • 3.20, Andrew Kolchoogin (?), 11:34, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > теперь она уже есть и на bsd,

        Experimental.

    > и на macos'и

        Read-only.

     
     
  • 4.55, Planner (?), 20:14, 23/04/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >    Experimental.

    ну если на то пошло, то она Experimental и на солярке тоже. Но по надёжности и фичам лично меня даже этот Experimental на 80%-90% устраивает. И дома, и на некоторых серверах.

     

  • 1.6, Аноним (5), 10:45, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а для десктопов что лучше, не понятно
     
     
  • 2.9, Laz (?), 10:54, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а для десктопов что лучше, не понятно

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

     
  • 2.10, 187 (?), 10:57, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а для десктопов что лучше, не понятно

    Дома сижу на reiser. Cравнил копирование фильма (5Гб) - рейзер ровно в 2 раза быстрее xfs.
    Про маленькие файлы молчу - это вообще основной конек рейзера.

     
     
  • 3.14, devcoder (??), 11:11, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Cравнил копирование фильма (5Гб) - рейзер ровно в 2 раза быстрее xfs.

    Да Вы что? Как сравнивали?

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

    Да, и сравните скорость удаления больших (>1Гб) файлов на xfs
    с рейзером и ext, причём CPU usage и LA гляньте.

     
     
  • 4.18, 187 (?), 11:24, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    1. Раздел был один и тот же, форматировал по очереди в xfs и reiser.
    2. Скорость удаления больших файлов и, тем более, CPU usage [лично для меня] не имеют значения - мы говорим о десктопе, а не о сервере.
     
     
  • 5.19, devcoder (??), 11:28, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > ... мы говорим о десктопе, а не о сервере.

    s/мы говорим/я говорю/
    ;)


     
     
  • 6.23, 187 (?), 12:26, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да нет, МЫ говорим

    >а для десктопов что лучше, не понятно

    Дома сижу на reiser.

     
  • 3.27, Аноним (22), 13:27, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Если на большом файле и нефрагментированном разделе ФС не показывает скорости больше (скорость диска - 5%), то что-то тут явно не так, либо с ФС, либо с руками. Какие нах 2 раза?! У меня на 'тормозной' UFS2 чтение/запись на 3/5MB/s соотв медленней dd с/на диск. А XFS, хотите сказать, в 2 раза?!
     

  • 1.12, Ivan (??), 11:05, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Серьезная ошибка: автор создает на 300Gb винте XFS c параметрами -d agcount=1 (!!!) -l size=128m
    Это не смотря на то что в дкументации четко сказано one allocation group for every 4 GB of capacity in your target block device (округление в большую сторону.
      Как раз недавно столкнулся с ужасной производительностью XFS и курил документацию, в данном случае корретнее было бы форматировать так:
        
    mkfs.xfs -f -d agcount=75 -l size=64m

    а монтировать с такими опциями:

    logbufs=8,nobarrier,noatime,nodiratime,osyncisdsync(правда osyncisdsync щас  и так по умолчанию включается)

    Вот здесь тесты параметров форматироваия и монтирования XFS

    http://everything2.com/index.pl?node_id=1479435

     
     
  • 2.24, fresco (??), 12:44, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    это +1, верно подмечено
     
  • 2.28, Аноним (-), 14:48, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Серьезная ошибка: автор создает на 300Gb винте XFS c параметрами -d agcount=1
    >(!!!) -l size=128m
    >Это не смотря на то что в дкументации четко сказано one allocation
    >group for every 4 GB of capacity in your target block
    >device (округление в большую сторону.

    У автора написано, что ему эти опции посоветовал Dave Chinner.
    David Chinner - Principal Engineer                                                                                                                                                                         SGI Australian Software Group, практически автор xfs.

     
     
  • 3.30, Ivan (??), 15:43, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >У автора написано, что ему эти опции посоветовал Dave Chinner.
    >David Chinner - Principal Engineer        
    >          

    Это все замечательно, только при таком раскладе производительности от xfs ессно можно не ждать.

    выдержка man mkfs.xfs

    agcount  suboption  is  used  to  specify  the number of allocation groups.  The data section of the filesystem is divided into allocation groups to improve the performance of XFS.  

    More  allocation  groups imply  that  more  parallelism can be achieved when allocating blocks and inodes.  The minimum allocation group size is 16 MiB; the maximum size is just under 1 TiB.   The  data  section  of  the  filesystem  is divided  into  agcount  allocation  groups (default value is scaled automatically based on the underlying device size).  Setting agcount to a very large number should be avoided, since this causes  an  unreasonable amount of CPU time to be used when the filesystem is close to full.


    А теперь давай решать, что нам надо. Скорость или висяк при полностью забитом винте. Как мы видим Reiser4 утилизирует процессор, но при этом достигается достаточно неплохая производительность. И потом что значит very large number? Насколько большое должно быть значение. То которое я предложил я вывел из достаточно долгого поиска по докам и тестам. К сожалению я не нашел официальной рекомендации выделять 4G на группу, но поверьте после здания и монтирования ФС с теми опциями которые я предложил производительность заметно возросла.

     
     
  • 4.32, Аноним (-), 16:17, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Это все замечательно, только при таком раскладе производительности от xfs ессно можно
    >не ждать.

    Собственно, автор провел postmark тесты с вашими опциями, указанными в блоге, результат немного лучше.
    Он считает, что все дело в nobarriers, хотя может быть и не прав.

     
  • 4.33, Аноним (-), 16:27, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Как мы видим Reiser4 утилизирует процессор, но при этом
    >достигается достаточно неплохая производительность.

    Reiser4 стабильно вешает систему в dbench при 150-200 потоках. О нем речь вообще идти не должна.

     
  • 3.31, fresco (??), 15:46, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    David Chinner пришел в XFS толи в 2003, толи в 2004 году. Работал, правда, по производительности. ХЗ почему он такую ерунду посоветовал.
     
  • 2.44, Slayer605 (?), 11:38, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    + ещё если у вас рейд на XFS не забываем вставить правильные значения sunit=,swidth=
     

  • 1.13, Аноним (22), 11:05, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    суда бы включили ещё UFS и сравнили с NTFS под WS2003 тогда было бы вообще супер+пропаганда linux увеличилась
     
  • 1.15, Аноним (22), 11:13, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а никому не кажется подозрительным, что при увиличении числа файлов у некоторых ФС скорость (Кб/с) увеличивается?
     
  • 1.17, Аноним (22), 11:21, 26/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    думается обычное дело при пакетной обработке, наверно вопрос к архитекторам..
     
     
  • 2.21, wd (?), 12:09, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    какие-то странные тесты.
    Кому кажется наглядными эти псевдо 3D графики?

    Потом сравнивать Ext3 с опцией writeback и reiserfs без этой опции на операциях создания большого количества мелких файлов, как-то не корректно.
    А если собрать 10 рейд на 15-ти тысячниках и хорошем контроллере со своим 256 М кешем и батарейкой, тогда ext3 точно всех порвет.

     
     
  • 3.26, Аноним (-), 13:02, 26/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно посмотреть на результаты reiserfs с опцией notail
     

  • 1.36, Георгий (??), 00:13, 27/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    mkfs.reiser4 -o create=ccreg40
    должен дать ощутимый прирост производительности по крайней мере там, где процессор не полностью загружен. (Не в тестовых условиях загрузить процессор полностью сложно.)
     
     
  • 2.37, Аноним (-), 00:25, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >mkfs.reiser4 -o create=ccreg40
    >должен дать ощутимый прирост производительности по крайней мере там, где процессор не
    >полностью загружен. (Не в тестовых условиях загрузить процессор полностью сложно.)

    И еще сильнее слить, если данные не компрессируются.
    Эта опциая полезна только для простейших бенчмарков, когда в файлы пишутся одни нули. В реальной жизни подавляющее большинство файлов уже пожаты (pdf/jpg/db/bin).

     

  • 1.38, nanodaemon (?), 08:20, 27/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    на домашнем порносервире (AXP3200+, 2GB, кучка винчей разных размеров) крутится себе FreeBSD 7.0 Release с корнем на ZFS (только /boot на UFS). скорость между ФС одного пула порядка 40-50 мегобайт в секунду. учитывая какое гавножелезо и вообще i386 очень даже хороший результат. а нексента, вообще, крутит зфс на 256 метрах памяти и не жужжит... а уж про менеджмент тулз ZFS я вообще молчу (не надо говорить про лвм, он сасёт громко и со смаком).

    после такого садиться за унылый линукс с его гавнолвмом и недобитым xfs'ом просто пытко :-)))

     
     
  • 2.39, Hetzer (ok), 08:32, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >на домашнем порносервире (AXP3200+, 2GB, кучка винчей разных размеров) крутится себе FreeBSD
    >7.0 Release с корнем на ZFS (только /boot на UFS). скорость
    >между ФС одного пула порядка 40-50 мегобайт в секунду. учитывая какое
    >гавножелезо и вообще i386 очень даже хороший результат. а нексента, вообще,
    >крутит зфс на 256 метрах памяти и не жужжит... а уж
    >про менеджмент тулз ZFS я вообще молчу (не надо говорить про
    >лвм, он сасёт громко и со смаком).
    >
    >после такого садиться за унылый линукс с его гавнолвмом и недобитым xfs'ом
    >просто пытко :-)))

    улыбныло
    видимо n-летнее отсутствие нормальной фс в bsd настолько сильно повлияло на разум, а замечания по этому поводу воспринимались как личное оскорбление, то теперь да, можно ругаться и троллить :) впрочем, от владельца <порносервира> разве можно ожидать иного ;)

     
     
  • 3.42, fresco (??), 09:15, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    За исключением тона чувак прав. Отсутствие ZFS в Linux -- его огромный минус!
     
     
  • 4.43, Hetzer (ok), 09:27, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >За исключением тона чувак прав. Отсутствие ZFS в Linux -- его огромный
    >минус!

    А с чего вы взяли что zfs нет в linux? она там есть (в рамках fuse) и такая-же testing как и в bsd. Вы же прямо сейчас zfs на bsd в production не кинете? так на мало-критичных сервачках пока.
    другое дело что в официальное linux ядро, zfs точно не попадёт по причине лицензий.

     
     
  • 5.45, Slayer605 (?), 11:43, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    даже на solaris в продакшен не стоит пока.
     
     
  • 6.47, ZANSWER (??), 11:56, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > даже на solaris в продакшен не стоит пока.

    У кого как...;) некоторые давно её уже на Thumper-ах юзают...;)

     
  • 5.48, fresco (??), 13:01, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Уже писал где-то тут. zfs-fuse -- это zpool 3-й версии (6 в FreeBSD 7, 10 в последнем OpenSolaris), производительность полный швах, драйвер практически не поддерживается (автор занят портированием Lustre на FreeBSD, если не ошибаюсь). Так что ZFS в Linux практически нет!
     
  • 4.50, nuclight (ok), 20:43, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >За исключением тона чувак прав. Отсутствие ZFS в Linux -- его огромный
    >минус!

    Минус линукса? :) Безусловно. И ведь, сами себе закрыли по лицензии - могли бы и заиметь...

     
     
  • 5.51, Аноним (22), 03:29, 28/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Я сам фряшник и соляровод со стажем и ZFS мне нравится (правда они врут про инновэйшен - это  "пересказ" DEC'Tru64 advfs которая казалась просто сказкой какой то в 90-е то :)

    Но однако же не занимайтесь самообманом - раз ZFS в Линукс портануть официально нельзя - сделают функциональный аналог ... если голубые (или какого другого цвету) раскошелятся :)

    PS: Про лицензии гнилая тема - даже заводить не буду, но есть и обратные примеры, когда хотятЪ GPL-ное а никак.

     
  • 2.46, ZANSWER (??), 11:55, 27/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > на домашнем порносервире (AXP3200+, 2GB, кучка винчей разных размеров) крутится себе FreeBSD 7.0 Release с корнем на ZFS (только /boot на UFS).

    Ну вот для домашнего оно пока только и годиться, на большее kernel panic в массы даёт, по сему, ZFS во FreeBSD, сейчас годиться только, чтобы письками меряться с Линуксоидами...;)

     

  • 1.49, Дмитрий Т (?), 18:42, 27/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Недавно настраивал себе ноутбук и теперь для имеющих на компьютере ещё и виндовс рекомендую ext3 по причине наличия двух вменяемых драйверов, позволяющих читать и писать в линуксовые разделы из виндовс. Для остальных ФС ничего бесплатного и нормально работающего не нашёл.
     
     
  • 2.52, Аноним (22), 03:31, 28/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Здрасте вам! Для FreeBSD UFS2 есть тоже, юзаю уже больше года - жив :)
     
  • 2.53, angra (ok), 08:28, 28/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Открой для себя ntfs-3g и забудь про ext3 как общий раздел для этих систем. Во-первых поведение виндовых драйверов ext3 не совсем стабильно, во вторых в ext3 отсутствует понятие кодировки для имен файлов.
    Находил еще драйвера для рейзера под винду, но так и не попробовал.
     
     
  • 3.54, fresco (??), 08:45, 28/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    rfstools которые? Это не драйвера, это так -- типа прочитать каталог, прочитать файл. Пользоваться не реально.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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