https://opennet.dev/openforum/vsluhforumID3/89785.html Хостинг-оператор Anchor опубликовал (http://www.anchor.com.au/blog/2013/04/the-btrfs-backup-experiment/) отчёт о тестовом внедрении файловой системы Btrfs на нескольких серверах, обеспечивающих работу системы резервного копирования. В итоге сделан вывод о том, что несмотря на обилие интересных возможностей и прогресс в развитии Btrfs, данная ФС ещё не готова для промышленного использования из-за наличия некоторых подводных камней и нерешённых проблем. Тем не менее для ознакомительного использования не на критически важных системах, таких как рабочие станции или персональные серверы, Btrfs уже можно использовать. Компания Anchor вернула на Ext4 системы, на которых был произведён переход на Btrfs, но указала на то, что будет отслеживать состояние разработки ZFS и Btrfs для перехода на одну из данных ФС в будущем. <br><br><br>В процессе эксперимента отсутствовали инциденты с потерей данных, успешно создавались тысячи снапшотов, средствами Btrfs было выявлено повреждение одного бита информации в RAID-массиве. Из пробле https://opennet.dev/openforum/vsluhforumID3/89785.html#176 Fri, 14 Jun 2013 03:14:34 GMT Ты просто не понимаешь, как работает флеш с левелером. Даже при том, что тебе уже 100500+ раз объясняли. Отсюда и такие "умозаключения".<br><br>"Асинхронная запись" не расскажет левелеру флеша, какие блоки можно использовать для внутренних операций в качестве рабочего набора. TRIM для SSD - не просто "фича", а жизненная необходимость.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#175 Thu, 13 Jun 2013 19:03:13 GMT &gt; AFAIK TRIM - медленная операция, так что не всё так радужно.<br><br>Ах, вот оно что. А я-то думал, почему это поддержку TRIM со стороны файловых систем преподносят как панацею от всех-всех проблем с SSD. Оказывается, нет никакого преимущества от увеличения скорости записи на SSD даже с использованием оного функционала ФС. Тогда уж точно: способность асинхронной записи ФС нивелирует преимущество использования TRIM.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#174 Thu, 13 Jun 2013 16:11:30 GMT &gt; AFAIK TRIM - медленная операция, так что не всё так радужно.<br><br>Ее надо грамотно использовать просто. А если ее не использовать - то ее "медленность" размазывается по обычным операциям, плюс за счет снижения объёма рабочего набора идёт дополнительная деградация по производительности.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#173 Thu, 13 Jun 2013 15:56:22 GMT AFAIK TRIM - медленная операция, так что не всё так радужно.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#172 Tue, 07 May 2013 03:39:44 GMT &gt; Напомните как там в linux с поддержкой ntfs ? Писать можно или <br>&gt; только читать ?<br><br>Можно и читать и писать. Модуль ntfs-3g.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#171 Mon, 06 May 2013 23:22:35 GMT Напомните как там в linux с поддержкой ntfs ? Писать можно или только читать ?<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#170 Fri, 03 May 2013 16:03:10 GMT &gt; http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-more <br><br>Адовый гибрид Illumos + QEMU + KVM + тонны маркетингового булшита. Спасибо, избавьте.<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#169 Thu, 02 May 2013 08:32:21 GMT http://joyent.com/blog/why-smartos-kvm-dtrace-zones-and-more<br> https://opennet.dev/openforum/vsluhforumID3/89785.html#168 Thu, 02 May 2013 05:46:02 GMT &gt; А помните рекомендацию оставлять 5-10% дискового пространства SSD неразмеченным ? Наверно <br>&gt; не от нехрен делать это придумали.<br><br>Естественно не зря. В случае ФС без поддержки TRIM это делать просто необходимо (и предварительно делать Factory Erase), чтобы флеш прожил несколько дольше и работал несколько быстрее.<br><br>В случае FS с поддержкой TRIM особой необходимости в этом нет - сама FS будет отдавать блоки в рабочий набор по мере удаления данных.<br>