xfs

Да ntfs неплохо справляется - тем более будет без проблем считаться на венде. А так ext3 по тем же самым причинам.

XFS!

Не надо только ext3, проверка диска после сбоя занимает дохренища времени. От себя рекомендую JFS

>>>проверка диска после сбоя занимает дохренища времен

И ?

Это печально и раздражает

ИБП?

xfs

Не проще ли выбрать любую другую ФС без этого недостатка?

ext3

XFS

> xfs

Глюкавое поделие, один oops в ядре и у вас нули вместо данных + плавающие глюки в структуре каталогов. Лучше уж jfs, на крайний случай ext3 или reiser3.

уж это точно не недостаток.
уж лучше подождать.

> Глюкавое поделие,

4.2

> один oops в ядре

Угу, а если ещё молотком по системнику хряпнуть -- не останется и нулей :) Тоже мне, критерий...

> Лучше уж jfs

Тормозная поделка, страдающая чудовищной фрагментацией.

> на крайний случай ext3

Глючное, безбожно тормозное поделие.

> или reiser3

При данном виде нагрузки будет тормозить лучше всех.

Чем лучше-то? Тот же JFS проверяет целостность в разы быстрее. Лично мне жалко терять много минут при загрузке, когда можно и не терять, при прочих равных.

>>Лучше уж jfs

>Тормозная поделка, страдающая чудовищной фрагментацией.

Вот беда-то, на ноуте с Убунтой используется JFS и как-то за полгода использования и регулярных обновлений потерь в скорости не замечаю. ext3 начинала тупить уже через месяц.

Из универсальных решений - NTFS (драйвер которой в линуксе намного лучше виндового для ext3), из чисто линуксовых - XFS, Reiser4, ext4dev; jfs сильно фрагментируется, ext2-3 и reiserfs имеют неподходящую адресацию

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

А ты на неё фильмов покачай всяких, в несколько потоков.

При больших разделах, для хранения больших файлов XFS вне конкуренции c её xfs_fsr.

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

1. Подождите ещё пару месяцев.

2. Если на ней ворочать большими файлами (пережать DV в mpeg4 или наоборот), то "тупить" она начинает через уже через пару недель. Проверено.

3. Если случайно JFS заполняется более чем на 80 -- 85 %, то фрагментация растёт молниеносно. (XFS тоже этим страдает, но не настолько, и у неё xfs_fsr есть).

> ext3 начинала тупить уже через месяц.

Да она с рождения тупит. А как чудесно у неё fsync устроен -- тут вообще слов нет.

> Подождите ещё пару месяцев.

Отличный совет для тех, кто идёт покупать винч уже сейчас. Вы его всегда в таких случаях советуете?

p.s. ext3 + ИПБ // если плохо с электричеством, выучи alt+sysrq+b

Чукча не читатель, чукча писатель?

> Отличный совет для тех, кто идёт покупать винч уже сейчас.

Совет был дан человеку, у которого уже полгода JFS на ноуте.

> Вы его всегда в таких случаях советуете?

Ни разу не давал таких советов. А Вы всегда отвечаете, не дослушав собеседника?

ВНИМАНИЕ! Тов. manntes, Вы рискуете своими данными!

> Тот же JFS проверяет целостность в разы быстрее.

Нет, она просто нагло обманывает пользователя. jfs_fsck по умолчанию НЕ ПРОВЕРЯЕТ целостность ФС, а просто завершает транзакции, записанные в журнал (что другие ФС делают при монтировании автоматически). Внимательно читайте man jfs_fsck, в частности на предмет ключика -f, а то с такой "проверкой" и данные запороть недолго! У других ФС (даже у ext3) *fsck проверяет целостность ФС по умолчанию.

> Глюкавое поделие, один oops в ядре и у вас нули вместо данных

Люитель проприетарщины? На RHEL за 4 года ни одного oops'a /kernel panic'a.

> На RHEL за 4 года

Хехе. RHEL4. Стабильный kernel panic при подключении юсб-устройства (gprs-модем).

> Стабильный kernel panic при подключении юсб-устройства (gprs-модем).

Вы б его ещё в ядро 2.2.x втыкали.

Как говорится мыши кололись ...

1) Где bug report на bugs.redhat.com?

2) Железка явно новая - что вы ещё хотели?

>Не проще ли выбрать любую другую ФС без этого недостатка? ext3

аналогичная проблема будет и у меня, но в довесок еще такой же винт под систему
на ext3 мне ненравится большой объем служебных данных, долго также удаляются большие файлы
насколько сильна проблема падения XFS? (xfs ранее не использовал)
допустим такая ситуация: расшарю в DC++ или на ftp я свой диск\каталог, народ начнет качать и тут пропадает питане (пусть ИБП нет), либо какойто другой сбой (что редко). Потеряю ли я свои отдаваемые файлы (они были в режиме ro)? Потеряю ли я открытый в ОО файл (режим rw)?
Стоит ли ставить xfs на системный диск?
reiser ставить не буду - не понравилось как она себя ведет при заполнении диска на 100% (а он заполнится)
так что выбор будет между xfs и ext3

ОС будет suse11_64

в догонку - надежно ли хранить файлы от виртуальной машины (vmware-server) на xfs?

> в догонку - надежно ли хранить файлы от виртуальной машины (vmware-server) на xfs?

Без БП вас ничто не спасёт, с БП - пофигу.

> Потеряю ли я свои отдаваемые файлы (они были в режиме ro)?

нет

> Потеряю ли я открытый в ОО файл (режим rw)?

может быть (как впрочем на почти любой фс)

> Стоит ли ставить xfs на системный диск?

С БП - пофигу, без него - под небольшой корень и или /home (<50GB) лучше ext3.

> XFS!

Я вот написал XFS, но моё домашнее файловое хранилище (ровно 100GB) находится под ... ext2. (На работе 500G и 750G на XFS)

1) Оно почти всегда в RO, т.е. журнал ФС мне пофигу

2) Легко восстановить удалённые файлы (что уже два раза делал стандартными средствами e2fsprogs)

3) Читается и пишется из Windows

> 2) Легко восстановить удалённые файлы (что уже два раза делал стандартными средствами e2fsprogs)

Восстанавливать удаленный файл - не Ъ

> 3) Читается и пишется из Windows

это просто разрывной аргумент