ФС

>А /usr отдельно, вообще, кто-нибудь выделяет?

Я когда-то выделял. Но получается, что /home отдельно, /var - отдельно. И в корне уже ничего не остаётся. Так что смысл отделять корень от /usr я перестал видеть :)

Пишут - дефраг есть:

Дефрагментация без размонтирования (online Defragmentation). Реализовано в самой последней версии e2fsprogs. (~/misc/e4defrag)

http://www.gentoo.ru/content/nikto-ne-znaet-kogda-vyydet-e4defrag

:-)

Я когда-то выделял. Но получается, что /home отдельно, /var - отдельно. И в корне уже ничего не остаётся. Так что смысл отделять корень от /usr я перестал видеть :)

Корень получается слишком большой. Как-то не очень... Наверняка, минусы них объединения найдутся, если поискать. :-)

Назвать, наверное, самую стабильную ФС ext2 - ненадежной?

А какая может быть надежность без журналирования? Зато этот ее недостаток является одновременно и преимуществом, позволяющим без забот использовать эту ФС на SSD (с остальными надо чуть больше помучиться, чтобы отключить журналирование).

Нет, видимо, видимо это только тебе, кисо. С какого бока нежурналируемая ФС стала самой надёжной? Ты ведь это имел ввиду? Только не говори мне, что стабильность и надёжность - одно и тоже.

>Реализовано в самой последней версии e2fsprogs

В 1.41.12 нету. Более свежих e2fsprogs в Gentoo нет даже замаскированных. А ставить что-то настолько экспериментальное, что его замаскированного нет - я на живой машине к этому ещё не готов :)

Корень получается слишком большой. Как-то не очень... Наверняка, минусы них объединения найдутся, если поискать. :-)

Я пока не нашёл ;) Когда-то был минус в том, что я корень (в отличии от /usr) не мог в ro перемонтировать, соответственно, не мог систему по живому переносить куда-то. Но вопрос решился :) - http://www.linux.org.ru/jump-message.jsp?msgid=4373604&cid=4373961

По-моему, как раз-таки хорошо, когда корень достаточно большой. А вот для /var можно выделить отдельный раздел; /tmp монтировать в разделяемой памяти; /home, естественно, тоже сделать отдельным разделом, 1Гб вполне хватает; ну, а для данных, фильмов и т.п. лучше завести пару-тройку жестких дисков на несколько Тб, и либо объединить их в один большой RAID, либо сделать по одному разделу на каждом.

ext3 у тебя тоже нежурналируемая?

А вот для /var можно выделить отдельный раздел

Не можно, а нужно :) Если /var держать с остальными - это же пипец :)

/home, естественно, тоже сделать отдельным разделом, 1Гб вполне хватает

Гы :)

$ df -h /home
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/mapper/vgs-home   60G   55G  1,6G  98% /home

И там ничего лишнего. Одни рабочие файлы, проекты и т.п. Сейчас в группе vgs место кончилось, просто так не расширить (оно - stripe), хочу почистить (в смысле - перенести на другие разделы) - и фигушки. Нечего чистить :)

В 1.41.12 нету. Более свежих e2fsprogs в Gentoo нет даже замаскированных. А ставить что-то настолько экспериментальное, что его замаскированного нет - я на живой машине к этому ещё не готов :)

А 23%? :-) Думаете, что хуже от неё будет? Нет, значит просто ещё не проверили. Сомневаюсь, что она зверски уничтожит ФС.

Не только в этом минус. В принципе, возможно более гибко настроить ФС: для /usr - одну, для / - другую. Плюс, в / пишутся только конфиги, обычно... Он редко меняется. Статичен. А в /usr, например, софт устанавливается. Обновляться может периодически. Т.е., имеется вероятность того, что он грохнется, плюс фрагментация и т.д... В принципе, если он помрёт, / останется жив, и того, что в / хватит, чтобы всё восстановить, при разделении. Ну, это так, размышления.

>ext3 у тебя тоже нежурналируемая?

Это не делает её надёжной :) У меня только две файловые системы умирали за последние 20 лет. FAT разных вариаций и ext3 :)

У меня ext3 нет. Ты говорил про ext2. К тому же, стабильность с надёжностью снова путаешь. Грабли - хобби или профессия?

/home, естественно, тоже сделать отдельным разделом, 1Гб вполне хватает; ну, а для данных, фильмов и т.п. лучше завести пару-тройку жестких дисков на несколько Тб, и либо объединить их в один большой RAID, либо сделать по одному разделу на каждом.

Ну, с терабайтами вы загнули. Мне хватит пока вполне и моих 350 Гб. RAID, тоже, - не для меня, пока что. :-( Но вот насчёт создания отдельных разделов - интересно. У меня всегда данные находились на /home. А стоит ли разделять?

>А 23%? :-) Думаете, что хуже от неё будет?

Конечно. Сейчас там фрагментации 23% и 258Гб файлов. А после дефрага может оказаться 0% фрагментации и 0Гб файлов :)

Сомневаюсь, что она зверски уничтожит ФС.

При дефрагментации - всё бывает. Кстати, намного хуже, чем полная смерть - это повреждение файлов. Я тут и без дефрагов уже несколько раз обнаруживал у себя битые в потрохах JPEG'и. От чего и как - х.з...

для /usr - одну, для / - другую

Так пофиг :) Что /usr, что / используются почти исключительно в ro. Так что тут и ext4, и xfs, и reiser4 одинаково себя покажут. А что-то другое сегодня мало актуально :)

Т.е., имеется вероятность того, что он грохнется

Так какая разница, если он грохнется - всё равно систему переставлять. А /etc итак обязан в бэкапе лежать. Да ещё и версионном на всякий случай ;)

плюс фрагментация и т.д

/etc маленький. В кеш всё что надо легко кладётся :)

Мне хватит пока вполне и моих 350 Гб

Хорошо, когда так... :)

А тут:

$ vgdisplay balvg
File descriptor 8 (pipe:[3668111]) leaked on vgdisplay invocation. Parent PID 18649: bash
  --- Volume group ---
  VG Name               balvg
  System ID             
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  211
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                9
  Open LV               8
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               3,44 TiB
  PE Size               4,00 MiB
  Total PE              902110
  Alloc PE / Size       718233 / 2,74 TiB
  Free  PE / Size       183877 / 718,27 GiB
  VG UUID               UGwUoB-8ymr-odmn-kcmc-5iO0-xkUK-KFCvPK

Да, вот точно - недостаток windows - смешение изменяемых данных и неизменяемых. В лучшем случае, только падает скорость дефрагментации. В худшем... :-| Все изменяемые данные точно нужно отдельно от системы держать.

А я в \home кроме настроек ничего не держу, и сейчас он у меня вообще в корневом разделе лежит (351Мб размер всего \home):

df
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sda1             9,6G  8,7G  920M  91% /
/dev/sda2             2,0G  847M  1,1G  44% /var
/dev/sdb2             909G  761G  149G  84% /Big
/dev/sdb1             489G  143G  346G  30% /Music
/dev/sda4             220G  179G   42G  82% /Data
none                 1013M     0 1013M   0% /dev/shm
/Data/DVD.ext2        4,4G  335M  4,0G   8% /4write@DVD

>В лучшем случае, только падает скорость дефрагментации.

Под Windows вопрос фрагментации вообще не актуален. Там есть дефраги (Perfect Disk - the best :)), которые не только файлы качественно дефрагментируют, но и свободное пространство. Что не менее актуально и никак, кроме «дефрага мувом» не решается под Linux...

Все изменяемые данные точно нужно отдельно от системы держать.

В принципе, никто не мешает C:\Documents and Settings смонтировать на отдельный раздел :)

Правда, это мало спасёт от логгирования с C:\WINDOWS

$ df -lTh
Ф. система    Тип     Разм  Исп  Дост  Исп% смонтирована на
/dev/vgs/root ext4     40G   27G   12G  71% /
tmpfs        tmpfs   1012M  980K 1011M   1% /tmp
/dev/mapper/vgs-home
              ext4     60G   55G  1,6G  98% /home
/dev/mapper/balvg-backup3
              ext4     99G   81G   13G  87% /home/backup
/dev/mapper/balvg-small_files
              ext4     50G   43G  4,2G  92% /mnt/data/small-files
/dev/mapper/balvg-downloads2
               xfs    400G  390G   11G  98% /home/balancer/downloads
/dev/mapper/balvg-family
              ext4    148G   47G   94G  34% /home/family
/dev/mapper/balvg-downloads2
               xfs    400G  390G   11G  98% /home/family/Downloads
/dev/mapper/balvg-files
              ext4     99G   90G  4,4G  96% /home/family/Files
/dev/mapper/balvg-family_our
              ext4    443G  258G  163G  62% /home/family/Our
/dev/mapper/balvg-music2
              ext4    108G   95G  7,5G  93% /home/family/Music
/dev/mapper/balvg-video3
               xfs    1,1T  850G  197G  82% /home/family/Video
/dev/mapper/vgs-var
              ext4     25G   17G  6,8G  72% /var

:)

> кэш squid'а

Сквид на десткопе?

Конечно. Сейчас там фрагментации 23% и 258Гб файлов. А после дефрага может оказаться 0% фрагментации и 0Гб файлов :)

Я думаю, что там, всё-же дефрагментация не по принципу rm -rf / реализована. :-) Не всё так печально. Я бы проверил на тестовом разделе.

Так пофиг :) Что /usr, что / используются почти исключительно в ro. Так что тут и ext4, и xfs, и reiser4 одинаково себя покажут. А что-то другое сегодня мало актуально :)

Но, тем не менее, остаётся обновление программ... Не такое и редкое, я думаю.

Так какая разница, если он грохнется - всё равно систему переставлять.

Не обязательно. chkfs и далее...

А /etc итак обязан в бэкапе лежать. Да ещё и версионном на всякий случай ;)

Ну да. Но, авось, пронесёт... :-)

vgdisplay balvg

Я никогда ещё не пользовался LVM. Познаний мало. А стоит ли его пробовать..?

Сквид на десткопе?

И чего такого?

А зачем столько разделов для данных? Мне кажется лучшим вообще соблюдать политику один жесткий диск - один раздел (кроме системы - для нее, все-таки, разделы надо выделить). Вот свой полуторатерабайтник никак не «соберу» - надо с утра ставить все копироваться на второй полуторный, а потом объединять разделы...

Сквид на десткопе?

Естественно. Куда же без него? Во-первых, трафик считаю; во-вторых, экономлю до 20% трафика.

>Сквид на десткопе?

У меня тоже долго использовался :) Сейчас уже не использую, но так не снесённый и стоит пока. Заодно служит для доступа с Авиабазы к сайтам, где она заблокирована по IP :)

Кстати, KRoN73, не боитесь, что в случае, если диск начнет «сыпаться», весь ваш LVM накроется медным тазом? Или сейчас в этом смысле уже проблем нет?

Под Windows вопрос фрагментации вообще не актуален. Там есть дефраги (Perfect Disk - the best :)), которые не только файлы качественно дефрагментируют, но и свободное пространство. Что не менее актуально и никак, кроме «дефрага мувом» не решается под Linux...

Ну да, если бы. Стандартный дефрагментатор, помнится, там косячил. А все эти «Perfect Disk»'и и «Disk Defrag»'и да ну...

В принципе, никто не мешает C:\Documents and Settings смонтировать на отдельный раздел :)

1. Мешают. Не все программы его ищут по переменным окружения. Плюс куча настроек, плюс ещё проблемы. Возможно, но мелкие проблемы... Пробовал. Неудобно. 2. Причём тут именно этот раздел? А про запись в каталог системы вы забываете? При установке программ - непременно. А запись в глобальный реестр?

Правда, это мало спасёт от логгирования с C:\WINDOWS

Ну и это... И ещё, наверняка, много что пишет.

Мне кажется лучшим вообще соблюдать политику один жесткий диск - один раздел (кроме системы - для нее, все-таки, разделы надо выделить).

Вы полегче. У некоторых ещё IDE. ;-) 4 диска максимум. Причём, один DVD-ROM. И не один Linux на них стоит. Потому, никак не получится выделить раздел на диск.

>Не обязательно. chkfs и далее...

В том-то и проблема, что описанные случаи повреждения картинок никаким fsck не ловятся. Да и не могут ловиться :)

А стоит ли его пробовать..?

Если планируешь со временем менять винты в системе, то это единственный разумный выбор :)

...

Т.е. когда винт один, то на другой и перенести всё не поломает. А вот когда у тебя 2-3 винта и апгрейд проходит по принципе «новый винт добавим, самый старый вынем», то тут LVM рулит неимоверно. Вырубил машину. Воткнул новый винт. Загрузился. Сделал на нём физический том (pvcreate /dev/sdc1). Расширил на него виртуальную группу (vgextend mygroup /dev/sdc1). Перенёс все данные со старого винта (pvmove /dev/sdb1). Выключил. Вынул старый винт. Включил. Работаешь дальше. Все переносы делаются на лету, без отмонтирований. Правда, сейчас (надеюсь, временно :)) оно виснет при переносе /var. Я вчера его переносил на новый двухтерабайтник в три приёма. Если при переносе проблема какая-то возникла - то после перезагрузки pvmove без параметров - и оно дальше работает.

...

В общем, у меня на домашнем серверочке винты уже с момента перехода на LVM почти два раза сменились :) Когда-то были 2xPATA 80G + 1xSATA 250G. Потом добавлялись 500G, 640G, два раза по 1T, вчера 2T добавил. Сейчас - 2x1T + 2T. И всё это без ручного копирования файлов :)

Ну и как бонус - расширение разделов на лету, когда в них кончается место. lvextend + resize2fs или xfs_grow. И раздел увеличился прямо при работе с ним. Хоть в rw, хоть с кучей открытых файлов.

Кстати, а если вместо lvm использовать простое старое монтирование? :-) Это - хуже?

>А зачем столько разделов для данных?

По типу сильно отличаются :)

Мне кажется лучшим вообще соблюдать политику один жесткий диск - один раздел

Это пока у тебя LVM нет :)

надо с утра ставить все копироваться на второй полуторный, а потом объединять разделы...

LVM отменяет весь этот геморрой ;)

>Или сейчас в этом смысле уже проблем нет?

Проблема сия была, есть и будет. И если в линейном LVM еще остается шанс вытянуть данные, оставшиеся на живых pv, то в страйпе такого шанса нет — это же фактически RAID0.
Поэтому если надежность важна — бэкапы и/или создавать LVM сразу поверх рейда.

> Куда же без него?

Тем у кого безлимит, всё равно, наверное, будет... Или по скорости лучше, чем просто с кэшем файрфокса, например?

>не боитесь, что в случае, если диск начнет «сыпаться», весь ваш LVM накроется медным тазом? Или сейчас в этом смысле уже проблем нет?

Сам не сталкивался, но, говорят, что пропадают только те файлы, что на накрывшемся винте будут. Понятно, что речь идёт о linear-объединении, не о stripe. Поэтому у меня stirpe только на систему (если что, переставить не страшно), а на основных разделах уникальные данные стараюсь бэкапить на другую машину.

Ну а если что-то архиважное, то можно и на mirror поставить. Только оно всё равно не спасёт от rm или от побития файлов при копировании или сбое в FS. Так что бэкап всё равно нужен...

> Если планируешь со временем менять винты в системе, то это единственный разумный выбор :)

А как же btrfs, zfs?

>Стандартный дефрагментатор, помнится, там косячил.

Жутко косячил :)

А все эти «Perfect Disk»'и и «Disk Defrag»'и да ну...

Perfect Disk - реально рулит :) Единственная известная мне полноценная замена Norton Speedisk в смысле дефрага свободного пространства и сортировки файлов по частоте модификации.

Помимо этого, он ещё и всякую гадость может повырезать. Или поменять user-agent, например. Гораздо удобнее настроить всё в одном месте, а не устанавливать сотню дополнений для f**s.

>Мешают. Не все программы его ищут по переменным окружения

Не-не. Я же говорю именно про точку монтирование. Т.е. оно будет C:\Documents and Settings, а физически располагаться хоть в другом разделе, хоть на другом винте.

А про запись в каталог системы вы забываете?

Я же писал про это :)

Ну и это... И ещё, наверняка, много что пишет.

Всё разнести можно ;)

>Кстати, а если вместо lvm использовать простое старое монтирование? :-) Это - хуже?

Это не решает вопрос автоматизации переноса данных :) Ну и, само собой, не решает вопрос роста раздела по мере надобности.

А так - да. Раньше на основном десктопе, где только один винт был, так и делал. Недавно на LVM и его тоже перевёл.

и/или создавать LVM сразу поверх рейда.

Вот этого я никогда не понимал. Зачем так извращаться, если можно сразу сделать рейд средствами LVM? :) Собственно, у меня корень и /home в LVM-RAID1 и стоят :)

$ hdparm -t /dev/vgs/home 

/dev/vgs/home:
 Timing buffered disk reads:  628 MB in  3.02 seconds = 208.04 MB/sec

Это при том, что по отдельности винты дают трансфер в 110, 118 и 83Мб/с :) Пустячёк, а приятно...

В том-то и проблема, что описанные случаи повреждения картинок никаким fsck не ловятся. Да и не могут ловиться :)

Да я про /usr. Конечно, кое-что придётся переставить... Но не полностью же.

Если планируешь со временем менять винты в системе, то это единственный разумный выбор :)

Пока не планирую.

Все переносы делаются на лету, без отмонтирований.

Хм... Такой, наверное, глупый вопрос: а чем хуже простое создание ФС, монтирование, перенос..? В принципе, даже fstab менять не придётся (диск ведь встанет на тоже место, что и старый, ФС та же самая). Если, мне не нужен RAID (или кажется, что не нужен), что даст lvm?

Ну и как бонус - расширение разделов на лету, когда в них кончается место. lvextend + resize2fs или xfs_grow. И раздел увеличился прямо при работе с ним. Хоть в rw, хоть с кучей открытых файлов.

Угу, если есть место куда расширять.

> Помимо этого, он ещё и всякую гадость может повырезать.

Если ПК один и используется firefox, то, имхо, AdBlock+ всё же проще и лучше с этим справляется. Хотя, с другой стороны - если вдруг придется переустановить систему кэш сохранится, в отличии от кэша браузера.

>А как же btrfs, zfs?

А это - привязка к FS. В первом случае - экспериментальной и не быстрой, во втором - ещё и к отсутствующей в Linux ;)

А так - да. Раньше на основном десктопе, где только один винт был, так и делал. Недавно на LVM и его тоже перевёл.

Для чего? К тому же, говорят тут о потерях данных... Вот у меня что-то грохнулось, ФС недоступна, - но ещё возможно восстановить, хотя бы с бубном. А если с LVM? Это ж - край.

Не-не. Я же говорю именно про точку монтирование. Т.е. оно будет C:\Documents and Settings, а физически располагаться хоть в другом разделе, хоть на другом винте.

А, понятно. Да, припоминаю есть в винде что-то подобное. Плюс ещё какой-то join вспоминается. Ну да, возможно. Любопытно, вообще-то. Хотя и ФС только одна. А возможно ли в винде примонтировать раздел только для чтения?

Всё разнести можно ;)

На части... :-) Не всё. Всё-равно, она будет писать в свой системный каталог. Вместе со своими файлами. Каталоги там новые создавать. И никуда вы от этого не денетесь.

а чем хуже простое создание ФС, монтирование, перенос..?

Возни намного больше. И во время переноса (который для современных винтов длится уже часами) ничего делать нельзя.

А тут - копируется себе в фоне, а ты работаешь спокойно дальше :) Кроме уже описанной (надеюсь, временной) бяки с /var. Но /var обычно не очень большой и переносится быстро даже вручную.

диск ведь встанет на тоже место, что и старый

:)

/dev/vgs/root           /                           ext4    barrier=0,commit=100,noatime,nobh,nouser_xattr  0 0
UUID=0383097e-cb54-44a6-97f5-ce947c6fa859           /boot                       ext2    noauto,noatime  0 0
UUID=9ab8ca9b-d7b9-4450-9e50-b64dafa6ece6           none                        swap    sw,pri=1        0 0
tmpfs                   /tmp                        tmpfs   noexec      0 0

/dev/vgs/home           /home                       auto    barrier=0,commit=60,data=writeback,nobh 0 3
/dev/vgs/portage        /data/portage               auto    noatime 0 0
/dev/balvg/backup3      /home/backup                auto    barrier=0,commit=100,data=writeback,noatime,nobh,nouser_xattr   0 13

/dev/balvg/small_files  /mnt/data/small-files       ext4    barrier=0,commit=100,data=writeback,noatime,nobh,nouser_xattr   0 0

/dev/balvg/downloads2   /home/balancer/downloads    xfs     barrier=0,relatime                                  0 7
/dev/balvg/family       /home/family                auto    barrier=0,commit=60,data=writeback,nobh,relatime    0 6
/dev/balvg/downloads2   /home/family/Downloads      auto    barrier=0,commit=300,data=writeback,nobh,relatime   0 3
/dev/balvg/files        /home/family/Files          auto    barrier=0,commit=60,data=writeback,nobh,relatime    0 6
/dev/balvg/family_our   /home/family/Our            auto    barrier=0,commit=60,data=writeback,nobh,relatime    0 6
/dev/balvg/music2       /home/family/Music          auto    barrier=0,commit=60,data=writeback,nobh,relatime    0 0
/dev/balvg/video3       /home/family/Video          xfs     barrier=0,relatime                                  0 11
/dev/vgs/var            /var                        auto    barrier=0,commit=100,data=writeback,noatime,nobh,nouser_xattr   0 0

Вот уж о чём не задумываюсь, так это о том, куда втыкать винты ;)

Угу, если есть место куда расширять.

Дык, втыкаешь новый винт, место отдаёшь под группу томов, но разделы не увеличиваешь сразу. А только когда будет нужно и на сколько нужно. Ну, с небольшим запасом на перспективу, так как при расширениях, понятно, виртуальные тома фрагментируются. С годами - достаточно сильно.

Или по скорости лучше, чем просто с кэшем файрфокса, например?

У нас пиковая скорость 100кБ/с, а обычно ~5-10кБ/с (и меньше). Для часто загружаемых данных и статики squid заметно увеличивает скорость.

Это при том, что по отдельности винты дают трансфер в 110, 118 и 83Мб/с :) Пустячёк, а приятно...

Хм... Не такой и пустячок. Для этого надо создавать том, чтобы он находился на двух физических дисках? И делать что-то вроде RAID с чередованием?

>Для чего?

Потому что на ту машину «ползучим апгрейдом» стали заползать винты, остающиеся после апгрейда домашнего сервера :) Вот сейчас 640G с сервера вывел, на десктоп поставлю. Сейчас там 250G+500G. Все три мне не нужны, нефиг греться и шуметь, 250G выведу. С LVM всё это быстро и удобно делается :)

К тому же, говорят тут о потерях данных...

Один фиг они терялись ещё до превода домашнего архива на LVM :) Так что потеря на уровне именно FS была. А вот какой - х.з. Архив пережил reiserfs, xfs и ext4.

Вот у меня что-то грохнулось, ФС недоступна, - но ещё возможно восстановить, хотя бы с бубном. А если с LVM?

То же самое. Если тянуть физические данные прямо из секторов - то тут вообще ничего не меняется. Если винт совсем умер, то и так, и эдак всё пропадает. Если вопрос геометрии и затирания MBR - то тоже одинаково лечится.

Исключение - stripe. Но тут ты сам знаешь, на что идёшь :)

>А возможно ли в винде примонтировать раздел только для чтения?

Вроде, нет. Но можно R/O на все файлы прописать ;)

Всё-равно, она будет писать в свой системный каталог

Так зависит от твоей настырности :) Если прямо в C:\WINDOWS срёт много - монтируем C:\WINDOWS на один раздел, а C:\WINDOWS\System32 и т.п. - на другие :)

...

Но всё это смысла не имеет. Всё равно нормальная FS в Windows только одна и под неё есть качественный дефраг ;)

А тут - копируется себе в фоне, а ты работаешь спокойно дальше :) Кроме уже описанной (надеюсь, временной) бяки с /var. Но /var обычно не очень большой и переносится быстро даже вручную.

Но ведь время копирования увеличивается?

Вот уж о чём не задумываюсь, так это о том, куда втыкать винты ;)

Кхм, ну я про то и говорил... Разве, что ФС на новом диске должна быть, как на старом.