Btrfs унылое говно

Кто-нибудь знает, чем диски проверить?

mhdd попробуй, но это надолго.

Пруфов так никто и не доставил.

Сейчас даже напрягаться не буду. Я на ЛОРе пруфы всего, что перечислил, периодически кидаю.

tmpfs + zram решают всё, и нет необходимости тратить ресурс железки на всякую шляпу.

Хорошее оправдание для тех, кто купил 100ГБ памяти и не смог понять, зачем он это сделал.

ext2 рулит и педалит. журналирование нужно только крымчанам.

Желаю тебе плохое питание.

пофиг на

Не злоупотребляй неродным языком.

mystery ★  типичный представитель пользователей Apple, забаненного в гугле

а теперь по теме:

Он даже на Core i7 4790K лагает на SSD, я уж про Core i7 Skylake 6700K под разгоном молчу

расскажи при чём тут процессор. У тебя что, во время лагов загрузка цп до упора?

ну и да, сейчас набегут (если уже не набежали) адепты btrfs

заявлена поддержка различных raid, но замена диска, даже в самом простом случае (raid-1) - лотерея

Это шоустоппер, на одном диске ext4 уже отладили.

идиотский алгоритм определения «сжимаемости» файлов

Сжатие можно не включать, некритично.

Хардварный рейд на десктопе — редкость, да и ненадёжное оно.

Аппаратный рейд это не надёжно?!

Когда ж ты пиздеть устанешь?

Линк я видел, но он 2010 года — старьё.

Видишь, ты опять наврал.

... btrfs is broken by design (aka. Edward Shishkin's «Unbound(?) internal fragmentation in Btrfs»)

Mailing list thread Unbound(?) internal fragmentation in Btrfs (2010)

Short answer: not a design problem but a bug (see 1) that was fixed

The core of the argument is that the b-tree implementation (from year 2010) does not follow the assumptions found in classic literature about b-trees and can lead to underutilization of the space. There are two issues raised: one about variable record length (in particular the file data inlined in the leaves), and a second issue about an inefficient b-tree balancing algorithm (see 3).

Inline extents are not split across leaves and are limited in size of one leaf. This was a decision made based on experience with reiserfs, where inline items were split, causing increased code complexity (and bugs) without much gain (see 2).

To completely avoid the theoretical worst case, you can turn off the file inlining by mounting with max_inline=0 (see 2).

In practice, the worst case means that an inline file extent may occupy one leaf block (which is more limited to the memory page size, usually 4k). This leads to the same space efficiency as in other filesystems, where a small file occupies a full block (see 4).

Предлагаю сделать ход конём и обращаться к тебе на лоре не иначе как «дебил» и «даун» на любую мелочь.

Мне казалось, что там всё обмазано патентами и fuse от этого не спасает.

А ты по ссылке ходил? Товарищ Яо доходчиво объяснил, что юридических проблем нет, только технические, которые в 16.04 решены.

Прям дежавю какое-то: Btrfs Seems To Finally Have Failed Me On A Production System

А что следует из этой цитаты, в которой все выкладки неправильные?

на железках до 500 баксов да, zfs рейд будет производительнее их даже, особенно если эти 200-400 баксов вложить в оперативу.

ext4 даже кеширование не умеет, смысл в 2015 году с такой фс, представь завтра у zfs выкинут ARC и L2ARC, я думаю ты сильно начнёшь думать о её необходимости тогда.

упрлся? Еще не хватала чтобы каждая нативная fs свой кэш имела, как упротая zfs. Кэш он на уровне vfs, один для всех.

По твоему ответу могу поставить диагноз. ЧСВ головного мозга.

ахаха, те же впечатления

А пока не допилили - скакаем на XFS
что на счет fstransform?

скакаем на XFS

xfs это хорошо, надёжно, быстро.

что на счет fstransform?

Ни разу не пользовался, попробуй расскажешь.

На моей генте память закуплена именно для этого. И для рыжей шкуры с кривыми аддонами.

ладно, все важное я и так перенес, только отправлю на гитхаб все, что есть и начну