L29Ah
Linux xfs Единственный выявленный недостаток xfs перед ext4: fstrim в случае ext4 тримает только ещё не триманное, а xfs — всё свободное место.
L29Ah
log Linux xfs ext4 прыщинг Переехал с ext4 на xfs.
Было:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/hdluks 479567560 454220268 20448100 96% /mnt/oldgentoo
Стало:
/dev/mapper/nvluks 488042696 460869012 27173684 95% /mnt/gentoo

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

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

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

Есть мысли, что это может быть? А сами вы с таким сталкивались? На всякий случай уточню, что речь о единичных потерях на многие сотни гигабайт за много лет, железо разное, файловые системы две разные, ядра разные...
tzirechnoy
Linux xfs xfs отказалась работать со стэктрэйсами. Притом, судя по всему, сначала проблема возникла когда оно не смогло что-то прочитать с одного диска (lvm snapshot переполнился, фиг с ним, оно несколько раз в день для создания бэкапа деляется) — а потом все xfs диски повисли нафиг.
Ребут помог.
Подумываю о виртуализацыи.
Balancer
tips xfs файловые_системы Хм. Оказывается, у XFS по дефолту inode хранятся в первом терабайте раздела. И если места в первом терабайте не останется, то система начнёт ругаться на то, что нет места, даже если на разделе оно ещё есть. Чтобы этого не было, нужно при монтировании использовать опцию inode64
wilful
KVM Linux lvm xfs ext4 *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
Linux xfs господа, сташно тормозит удаление больших файлов(другие не удалял т.к. там фильмы в основном) на 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
Linux xfs господа, сташно тормозит удаление дольших файлов на zfs

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

Не подскажете куда копать?
Strephil
xfs Часто приходится слышать, что эта файловая система плохо переносит всякого рода сбои, не восстанавливается.
Однако, вот мне повезло. Удалось восстановить данные после смерти жесткого диска. Не так всё в Linux с файловыми системами и плохо.
epsilon
fail Linux xfs fs Удалял три десятигиговых файла с XFS-раздела. Система встала колом и стояла минут 20. Надоело, а, раз на клавиатуре нет кнопки SysRq — просто сбросил.
Система стала загружаться и встала колом ещё до иксов. Подождал минут 10, сбросил.
Загрузился в single mode, попробовал смонтировать раздел — встало колом. Правда, минут через 15 всё отвисло, и файлы удалились.
Такой день.
romanu
xfs calculate KDE Я так думаю, что настройки кде4 (а также, частично psi+) сбились вчера из-за XFS. Потому что у меня /home монтируется как папка на разделе с XFS. Не зря я настороженно так к ней относился. Суть в том, что после нажатия на Reset те файлы, которые были открыты на запись, были повреждены после перезагрузки. Так что будет время — обязательно всё перетащу на ext3. Она меня ещё ни разу не подводила.
rwarrior
Linux xfs Жуйк, я купил жёсткий диск WD15EARS на полтора терабайта. У него размер сектора --- 4 килобайта. Но fdisk, parted, hdparm пишут, что 512 байт. В интернетах говорят, что это нормально. Так что я в fdisk сделал разметку без флага DOS-совместимости (DOS-несовместимость, лол), оно сделало начало раздела в 2048 секторов, т.е. отступил на 1 мб. А mkfs.xfs я сказал, что -s size=4096. Я всё правильно сделал?