Чтобы добавлять сообщения и комментарии, .

@Balancer:
Balancer

ReiserFS мертва, не поддерживается и т.п. ext4 чудовищно тормозит на каталогах с тоннами мелочи. Вдобавок ко всему, на таком разделе с мелочью внезапно, едва он до половины заполнился, кончились inodes. При чём, как я понимаю, в ext4 число inodes увеличить без переформатирования нельзя? Ну и, главное, всё же, это тормоза. Надеялся я, что выделение мелких разделов под конкретные задачи, чтобы фрагментирование свободного пространства не сильно влияло, поможет — но, увы, помогло только частично.

А ReiserFS, который только и спасал в таких ситуациях, мёртв :-/

Почесал, почесал репу, да и решил рискнуть поставить на каталог с мелочью XFS. Это идёт вопреки всему моему старому опыту об этой ФС, но столько лет прошло с прежних тестов и практики — говорят, что её сильно допилили на счёт старых проблем с тормозами на мелочи. Посмотрим :)

@justonemore:
justonemore

Одна из причин держать "хомяка" на отдельном разделе а прочие данные типа музыки, документов, видео, программ и прочего это риск того что файловая система придёт в неисправность. Уже больше 10 минут xfs_repair печатает в терминал точки а я не могу войти в систему под своей учёткой.

@dr-Chaos:
dr-Chaos

всё таки не зря я XFS для файлопомойки выбрал... Дефрагментирую после торрентов.

@Balancer:
Balancer

В который раз натыкаюсь на потерю данных в файле. В фотке. Случаи единичные на многие десятки тысяч фото, но нет-нет, а наткнёшься на фотку, отображаемую лишь до половины, например. Размер тот же, нулей внутри не видно, таймстамп прежний. exiftool возвращает корректные данные. Но если сравнить с бэкапом — md5 файла отличается. Можно бы было винить железо, но это уже третья машина с таким поведением. Было подозрение на xfs, но сейчас случай с ext4. Натыкался на такую потерю данных при переполнении раздела с ext4 при копировании (на уже скопировавшихся файлах), но сейчас копирования нет, на разделе свободно 96Гб из 690Гб. Такие же проблемы иногда всплывают в видеоколлекции. Только там обнаружить сложнее, при просмотре столь короткий сбой в глаза не бросается, а вот при пересчёте хеша торрента, нет-нет, да попадётся раз в несколько месяцев «закачано на 99.8%». За секунды докачивается до 100%, но такое дело есть. Единственное, что объединяет все эти случаи — Gentoo. Но ситуация повторяется регулярно в течении многих лет (не меньше 10), за это время и ядер сколько сменилось, и настройки компиляции... А вот на ntfs/windows многие файлы лежать ещё с середины 1990-х гг., пережив десятки копирований, начиная с винчестеров по 133..270Мб... К сожалению, по той же Ubuntu такой статистики нет, все её инсталляции у меня «временные», основные архивы или в ntfs/windows, или ext4/xfs/gentoo.

Есть мысли, что это может быть? А сами вы с таким сталкивались? На всякий случай уточню, что речь о единичных потерях на многие сотни гигабайт за много лет, железо разное, файловые системы две разные, ядра разные...

@tzirechnoy:
tzirechnoy

xfs отказалась работать со стэктрэйсами. Притом, судя по всему, сначала проблема возникла когда оно не смогло что-то прочитать с одного диска (lvm snapshot переполнился, фиг с ним, оно несколько раз в день для создания бэкапа деляется) — а потом все xfs диски повисли нафиг.
Ребут помог.
Подумываю о виртуализацыи.

@Balancer:
Balancer

Хм. Оказывается, у XFS по дефолту inode хранятся в первом терабайте раздела. И если места в первом терабайте не останется, то система начнёт ругаться на то, что нет места, даже если на разделе оно ещё есть. Чтобы этого не было, нужно при монтировании использовать опцию inode64

@GotF:
GotF

# xfs_db -c frag -r /dev/mapper/home
actual 92833, ideal 80742, fragmentation factor 13.02%
Збс, это на новенькой ФС без торрентов и т.п.

@GotF:
GotF

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

@wilful:
wilful

*CentOS Стал случайным QA-мастером для различных вариаций блочных устройств для хостов на KVM с драйвером virtio и отключённым кэшем.
Опыт простой:
dd if=/dev/zero of=/mnt/storage/test-vm.raw bs=1G count=20

lvm,file+xfs — выдал наибольший показатель скорости записи, НО! la хоста (dom0 кому как удобнее) вырастал до бесконечности, успевал записать около 5-8Gb, дальше kill
lvm,file+ext4 — был на 20-30% медленнее, но la держался в пределах разумного, процесс шёл ровно. lvm+ext4 оказался незначительно быстрее нежели file+ext4.

Честно сказать были большие надежды на xfs. Если кто-то может подсказать, почему так херова? Я бы послушал. Сервер IBM System x3650 M2, RAID5 ServeRAID M5015, CentOS 6.2

@dr-Chaos:
dr-Chaos

господа, сташно тормозит удаление больших файлов(другие не удалял т.к. там фильмы в основном) на xfs. Страшно — это до минут.

uname -a
Linux server 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux

Не подскажете куда копать? Или как диагностировать.

@dr-Chaos:
dr-Chaos

господа, сташно тормозит удаление дольших файлов на zfs

uname -a
Linux server 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux

Не подскажете куда копать?

@nixon89:
nixon89

Файловые системы ближайшего будущего (доклад Google)http://www.linux.org.ru/news/opensource/7274997 <<A HREF=>"> — linux.org.ru

@Strephil:
Strephil

Часто приходится слышать, что эта файловая система плохо переносит всякого рода сбои, не восстанавливается.
Однако, вот мне повезло. Удалось восстановить данные после смерти жесткого диска. Не так всё в Linux с файловыми системами и плохо.

@epsilon:
epsilon

Удалял три десятигиговых файла с XFS-раздела. Система встала колом и стояла минут 20. Надоело, а, раз на клавиатуре нет кнопки SysRq — просто сбросил.
Система стала загружаться и встала колом ещё до иксов. Подождал минут 10, сбросил.
Загрузился в single mode, попробовал смонтировать раздел — встало колом. Правда, минут через 15 всё отвисло, и файлы удалились.
Такой день.

@romanu:
romanu

Я так думаю, что настройки кде4 (а также, частично psi+) сбились вчера из-за XFS. Потому что у меня /home монтируется как папка на разделе с XFS. Не зря я настороженно так к ней относился. Суть в том, что после нажатия на Reset те файлы, которые были открыты на запись, были повреждены после перезагрузки. Так что будет время — обязательно всё перетащу на ext3. Она меня ещё ни разу не подводила.

@alex-aj-jade:
alex-aj-jade

после полутора месяцев неактивности ЖД порадовал ошибкой "superblock read failed"

@rwarrior:
rwarrior

Жуйк, я купил жёсткий диск WD15EARS на полтора терабайта. У него размер сектора --- 4 килобайта. Но fdisk, parted, hdparm пишут, что 512 байт. В интернетах говорят, что это нормально. Так что я в fdisk сделал разметку без флага DOS-совместимости (DOS-несовместимость, лол), оно сделало начало раздела в 2048 секторов, т.е. отступил на 1 мб. А mkfs.xfs я сказал, что -s size=4096. Я всё правильно сделал?

@nixtrian:
nixtrian

Взял винт на 1тер. Жуй, какую фс посоветуешь под файлопомойку(музыка/фильмы)?