На нетбуке юзаю SSD без разбивки на разделы. В свопе нет необходимости, так как 8Гб рамы. Думал о btrfs и даже о нативной zfs, но так и оставил ext4. Только журнал отключил и подтюнинговал по мелочи.
LinuxForum.Fans
Кто какую разметку жёсткого диска делает ?
Автор: lone_wolf
32 сообщений
3981 просмотров
кстати, журнал ИМХО зря. ИМХО надо было оставить.На нетбуке юзаю SSD без разбивки на разделы. В свопе нет необходимости, так как 8Гб рамы. Думал о btrfs и даже о нативной zfs, но так и оставил ext4. Только журнал отключил и подтюнинговал по мелочи.
tl;dr про SSD http://emulek.blogspot.ru/2013/04/ssd.html
кстати, журнал ИМХО зря. ИМХО надо было оставить.
Сомневался на эту тему. Ну включить-то его недолго.
Кстати, что можешь сказать про ZFS? Стоит ли его юзать? Фс крута, но чужеродность ее происхождения вызывает у меня некоторое недоверие.
Сомневался на эту тему. Ну включить-то его недолго.
дык и включи. Вероятность потери данных на SSD весьма велика(да, мала в абсолютной величине, но дык и битов там сотни и тысячи миллиардов!). И если это метаинформация, то можно загубить ВСЮ ФС. Журнал конечно не панацея, но в 99.9999% случаев -- помогает. А вот "ужасы от записи" == городские легенды. Куча народу юзают SSD с журналом (в т.ч. я), и ничего, брат жив.
Кстати, что можешь сказать про ZFS?
ничего не могу сказать. Могу спросить: зачем? Хочешь изврата/красноглазия -- ну делай, потом расскажи о впечатлениях.
EXT4 на сегодня уже достаточно близка к идеалу. Идеальная ФС может и лучше, но ненамного. Посему очевидно, что и ZFS ненамного лучше, даже если она идеальна.
Могу спросить: зачем?
Могу ответить: Copy-on-Write, снапшоты, storage pool, прозрачное сжатие. Неужели недостаточно?
CoW, по-моему, просто создана для SSD.
Copy-on-Write
угу. Вместо того, что-бы копировать A->B, мы говорим, что B -- это A.
Рассказать, как это выглядит IRL?
Очень просто:
1. вы фапаете в интернетах.
2. вам захотелось сделать бекап
3. вы нажали кнопку, и ВНЕЗАПНО сделался бекап
4. вы радостно дальше фапаете в интернетах
5. ВНЕЗАПНО вас настигает БЕШЕНЫЙ ЛЮТЫЙ 12309, вы перезагружаетесь в Windows, и пишете сюда: "какое-же тормозное гуано ваш лялех!"
А разгадка проста -- бекап-то вы сделали быстро, но вы его НЕ СДЕЛАЛИ. Как только ваш браузер поменял там хоть один байтик в каком-нить кеше, то у вас ВСЁ колом встало, ибо бекап нужно делать СЕЙЧАС.
Такая ерунда делается в fork(2), но там другое -- ни один нормальный программист не станет менять двоичный код на лету. Т.е. код там и так read-only. Но зачем делать такие снапшоты, которые всё равно же тормозят, но не тогда, когда их делают, а ВНЕЗАПНО?
прозрачное сжатие.
man chattr
text
A file with the `c' attribute set is automatically compressed on the disk by the
kernel. A read from this file returns uncompressed data. A write to this file
compresses data before storing them on the disk. Note: please make sure to read
the bugs and limitations section at the end of this document.
BUGS AND LIMITATIONS
The `c', 's', and `u' attributes are not honored by the ext2, ext3, and ext4
filesystems as implemented in the current mainline Linux kernels.
включите, попробуйте, поймите, что оно вам не нужно.
CoW, по-моему, просто создана для SSD.
вы думает, что у вас от SSD система колом не встанет? Ошибаетесь. Даже с RAM она виснет в таких случаях.
Обычное копирование можно делать в фоне (оно так и делается), а вот этот ваш снапшот мало того, что ВНЕЗАПНО надо копировать, дык ещё и гарантировать атомарность операции. А это значит, что ядро ВСЁ ОСТАНОВИТ, пока не скопирует.
ЗЫЖ у меня вот бекапы делаются в фоне и неатомарно. Потому не тормозят. Ну а консистентность я обеспечиваю путём соблюдения неизменности внутри интервала. Да, это сложнее, зато ничего не тормозит.
Рассказать, как это выглядит IRL?
Приходилось тестировать?
Как только ваш браузер поменял там хоть один байтик в каком-нить кеше
Кеш не то, для чего нужен бекап.
Не стоит полагать, что заполучив возможность делать моментальные снапшоты я стану снэпшотить все подряд. Но бэкап для некоторых вещей, которые редко меняются (и соответственно, редко перезаписываются на диске) тоже порой нужен. Тут-то и я и вижу преимущества ZFS. Использовать наряду со снэпшотами еще и другие средства бэкапа я считаю не только приемлемым но и необходимым. Ведь снэпшоты совершенно очевидно не спасут от физической неисправности диска.
Кроме того, это вопрос не только и даже не столько производительности. На моем нетбуке "бутылочным горлышком" чаще всего является не диск.
[quote="bobr"]Copy-on-Write
man chattr включите, попробуйте, поймите, что оно вам не нужно. вы думает, что у вас от SSD система колом не встанет? Ошибаетесь. Даже с RAM она виснет в таких случаях.[/quote]Показать
угу. Вместо того, что-бы копировать A->B, мы говорим, что B -- это A.
Рассказать, как это выглядит IRL?
Очень просто:
1. вы фапаете в интернетах.
2. вам захотелось сделать бекап
3. вы нажали кнопку, и ВНЕЗАПНО сделался бекап
4. вы радостно дальше фапаете в интернетах
5. ВНЕЗАПНО вас настигает БЕШЕНЫЙ ЛЮТЫЙ 12309, вы перезагружаетесь в Windows, и пишете сюда: "какое-же тормозное гуано ваш лялех!"
А разгадка проста -- бекап-то вы сделали быстро, но вы его НЕ СДЕЛАЛИ. Как только ваш браузер поменял там хоть один байтик в каком-нить кеше, то у вас ВСЁ колом встало, ибо бекап нужно делать СЕЙЧАС.
Такая ерунда делается в fork(2), но там другое -- ни один нормальный программист не станет менять двоичный код на лету. Т.е. код там и так read-only. Но зачем делать такие снапшоты, которые всё равно же тормозят, но не тогда, когда их делают, а ВНЕЗАПНО?
прозрачное сжатие.text A file with the `c' attribute set is automatically compressed on the disk by the
kernel. A read from this file returns uncompressed data. A write to this file
compresses data before storing them on the disk. Note: please make sure to read
the bugs and limitations section at the end of this document.
BUGS AND LIMITATIONS
The `c', 's', and `u' attributes are not honored by the ext2, ext3, and ext4
filesystems as implemented in the current mainline Linux kernels.
CoW, по-моему, просто создана для SSD.
Обычное копирование можно делать в фоне (оно так и делается), а вот этот ваш снапшот мало того, что ВНЕЗАПНО надо копировать, дык ещё и гарантировать атомарность операции. А это значит, что ядро ВСЁ ОСТАНОВИТ, пока не скопирует.
ЗЫЖ у меня вот бекапы делаются в фоне и неатомарно. Потому не тормозят. Ну а консистентность я обеспечиваю путём соблюдения неизменности внутри интервала. Да, это сложнее, зато ничего не тормозит.
тогда эм если будет время и желание конечно же... не могли бы вы написать how-to заметку ну или статейку о создании backup. Я думаю не 1 я скажу вам за это спасибо. :[
С бэкапом все сугубо индивидуально. Слишком много способов и ситуаций чтобы охватить в одной заметке или статейке. Для одних целей подходят локальные средства, для других - копирование на удаленный ресурс. И опять здесь масса вариантов: В первом случае это может быть и снэпшоты и зеркалирование, во втором - rsync, ftp или даже mercurial/git/svn/etc.
Кеш не то, для чего нужен бекап.
о да... У вас снапшоты как-то селективно делаются, или сразу весь профиль?
Приходилось тестировать?
конкретно zfs? неа. Я не верю в серебряные пули. Сами пробуйте, с удовольствием ознакомлюсь.
Не стоит полагать, что заполучив возможность делать моментальные снапшоты я стану снэпшотить все подряд. Но бэкап для некоторых вещей, которые редко меняются (и соответственно, редко перезаписываются на диске) тоже порой нужен.
и чем такой бекап лучше обычного тарбола? Мне сиё непонятно.
т.е. вы сами не знаете, чего хотите получить? Ну пробуйте...Кроме того, это вопрос не только и даже не столько производительности. На моем нетбуке "бутылочным горлышком" чаще всего является не диск.
угу. Попробую.тогда эм если будет время и желание конечно же... не могли бы вы написать how-to заметку ну или статейку о создании backup. Я думаю не 1 я скажу вам за это спасибо.
ну можно ведь общие принципы рассмотреть, и некоторые частные случаи, не?С бэкапом все сугубо индивидуально. Слишком много способов и ситуаций чтобы охватить в одной заметке или статейке. Для одних целей подходят локальные средства, для других - копирование на удаленный ресурс. И опять здесь масса вариантов: В первом случае это может быть и снэпшоты и зеркалирование, во втором - rsync, ftp или даже mercurial/git/svn/etc.
о да... У вас снапшоты как-то селективно делаются, или сразу весь профиль?
Ну так ведь storage pools же.
bobr пишет:
Приходилось тестировать?
конкретно zfs? неа. Я не верю в серебряные пули. Сами пробуйте, с удовольствием ознакомлюсь.
А что приходилось? Откуда-то взлялось же вот это:
Рассказать, как это выглядит IRL?
Ведь не умозрительно же делаются выводы о том, как это выглядит IRL
и чем такой бекап лучше обычного тарбола?
Экономией дискового пространства. А чем хуже?
т.е. вы сами не знаете, чего хотите получить?
Copy-on-Write, снапшоты, storage pool, прозрачное сжатие. Неужели недостаточно?
Ну пробуйте...
Пожалуй, нетбук уж не стану теребить. Он мне для работы частенько нужен. А вот на десктопе попробую. Правда там обычный хард. Все ж интересно, что оно за фрукт.
ну можно ведь общие принципы рассмотреть, и некоторые частные случаи, не?
Можно. Для общего введения в тему. Мне, конечно, оно не нужно. Но неосведомленным в теме, полагаю, интересно будет.
Ну так ведь storage pools же.о да... У вас снапшоты как-то селективно делаются, или сразу весь профиль?
при чём тут storage pools? Вот надо сделать бекап /home/, вы его как будете делать?
А что приходилось? Откуда-то взлялось же вот это:
а вам приходилось биться головой в бетонную стену? А откуда вы знаете, что это не нужно? В жизни ведь всё надо проверить? Вот я вам и говорю: проверяйте, потом расскажите.
Ведь не умозрительно же делаются выводы о том, как это выглядит IRL
нет. Я видел, как работает эта ваша COW. ИМХО в условиях типичных для лаптопа/десктопа -- плохо работает. Но я могу и ошибаться конечно... Может головой в стену -- приятно и нужно.
Экономией дискового пространства. А чем хуже?
экономия тут будет тогда, и только тогда, когда COW поделит всё пространство снапшота на множество кусков. И будет копировать не всё, а только изменившиеся куски. Причё только тогда, когда это действительно надо. Причём это отдельный абстрактный слой, и он потому не знает, что происходит выше и ниже. Потому ошибки не только возможны, но и неизбежны. Потому:
1. не факт, что из-за ошибок действительно будет экономия в месте и/или во времени.
2. не факт, что накладные расходы не будут больше профита.
Моё мнение -- профит если и будет, то незначительный. Да, мне интересно, в каких случаях будет заметный профит.
И да, вы слышали про инкрементальный бекап? Там тоже экономия пространства.
хм... Вам не нужно? Т.е. вы уже ВСЁ про это знаете? И вам чужой опыт не интересен? Круто. Может поделитесь?Можно. Для общего введения в тему. Мне, конечно, оно не нужно. Но неосведомленным в теме, полагаю, интересно будет.
Войдите или зарегистрируйтесь, чтобы ответить.
