From: Michael Shigorin <mike@osdn.org.ua> To: community@altlinux.ru Cc: docs@altlinux.ru Subject: [Comm] (my|why) partitions (was: копия /hda to /hdb) Date: Sat, 13 Nov 2004 14:18:57 +0200 Message-ID: <20041113121857.GH1863@osdn.org.ua> (raw) In-Reply-To: <4195F58E.1020303@zaz.zp.ua> [-- Attachment #1: Type: text/plain, Size: 6867 bytes --] On Sat, Nov 13, 2004 at 01:52:46PM +0200, Gennadiy Redko wrote: > А вообще, есть ли какой-нибудь скрытый смысл в отдельных > разделах если диск один? Как минимум разнесение таких проблем, как: - метаданные (меньше шансов, что всё накроется одним бэдом); - учёт места и, возможно, инодов (плюс квоты); - более удобное резервное копирование (тж. см. выше); - возможность индивидуальной регулировки ФС и опций монтирования. Последнее весьма важно для эффективного использования в случае, когда задачи, решаемый даже одним диском, разнообразны (т.е. это не ещё один блин под ftp и всё). Небольшой / -- большой плюс, если развалилось что-то из того, что принадлежит к /usr или /var: машинку по крайней мере до какого-то состояния можно автономно поднять, если его не задело. "Небольшой" по нынешним меркам -- 100--250 Mb, с тем, чтобы не возникало лишних проблем вообще и с обновлением ядер в частности. Отдельный /usr -- вопрос спорный, если есть место -- делается, если при планировании разбивки возникают сомнения -- порой и нет (это бывает на системах с одним диском <1Gb или когда предвидится довольно разнообразное использование места на /usr и тоже невыносящимся в таких случаях /var). Отдельный /home (и при использовании -- /usr/local) -- плюс при обновлениях, переездах, бэкапе, ну и и меньше шансов на то, что чья-то закачка съест место на / или /usr во время обновления системы. Отдельный /var можно поселить и на какой reiser (если есть бесперебойник) -- ему несколько легчает. Отдельный /boot не представляет (для меня по крайней мере) смысла где-то с 2001 года, когда BIOS и LILO уже как-то научились в среднем не спотыкаться об 1024-й цилиндр. Отдельный /var/ftp... У меня когда-то "остатки места" монтировались в /opt, потом оказалось, что именно их удобно раздавать по ftp/nfs/smb; анализ привычки показал её бессмысленность, и "остатки" плавно съехали в /var/ftp. Да -- устойчиво наблюдаю рост симпатии к привычке делать /tmp на tmpfs (за счёт более массивного swap-раздела), а /var/tmp вешать на него при помощи bind mount. (2 wrar: в курсе, уже ответил :) > В чем заключается "сермяжная правда" разбиения ОДНОГО диска на > разделы? Есть правда аргумент повышения безопасности, за счет > невозможности создания нардлинков на файлы каталога /var, но > необходимость постоянно двигать разделы из-за ошибок > планирования разбиения -- пугает больше. Ну, у меня случаев, требующих панических подвижек, попросту не было уже очень давно -- помогает на нескольких листках бумаги планировать использование дисковой подсистемы, рисуя физические и логические ресурсы и решая, чему где жить. А по-хорошему -- при таких страхах надо смотреть на пресловутые LVM/EVMS, ну или эмулировать их небольшим количеством запасных относительно мелких разделов, которыми маневрировать, монтируя при необходимости в /usr/share/doc или /home/user2 для выгадывания места на /usr или /home, соответственно. > Речь не о сервере, а о рабочей станции. Ну вот несколько примеров -- на home и trickster сейчас "каноническая" (практически устоявшаяся) раскладка для сколь-нибудь заметных дисков на рабочих станциях, где я не только админю, но и обитаю, а также занимаюсь разработкой (могут выполнять подсобные серверные роли по ходу дела, хотя это сейчас минимизируется): home:~> sudo fdisk -l /dev/hda Disk /dev/hda: 123.5 GB, 123522416640 bytes 255 heads, 63 sectors/track, 15017 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 94 755023+ 82 Linux swap /dev/hda2 * 95 126 257040 83 Linux /dev/hda3 127 492 2939895 83 Linux /dev/hda4 493 15017 116672062+ 5 Extended /dev/hda5 493 979 3911796 83 Linux /dev/hda6 980 1223 1959898+ 83 Linux /dev/hda7 1224 3048 14659281 83 Linux /dev/hda8 3049 15017 96140961 83 Linux home:~> df -T Filesystem Type Size Used Avail Use% Mounted on /dev/hda2 xfs 247M 184M 63M 75% / /dev/hda7 xfs 14G 14G 985M 94% /home /dev/hda5 xfs 3.8G 3.6G 130M 97% /usr /dev/hda3 xfs 2.8G 1.2G 1.7G 41% /var /dev/hda8 xfs 92G 92G 39M 100% /var/ftp none tmpfs 384M 1.7M 383M 1% /tmp trickster:~> sudo fdisk -l /dev/hda Disk /dev/hda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 130 1044193+ 83 Linux /dev/hda2 131 9729 77103967+ 5 Extended /dev/hda5 131 195 522081 82 Linux swap /dev/hda6 196 226 248976 83 Linux /dev/hda7 227 487 2096451 83 Linux /dev/hda8 488 1009 4192933+ 83 Linux /dev/hda9 1010 2921 15358108+ 83 Linux /dev/hda10 2922 3312 3140676 83 Linux /dev/hda11 3313 9729 51544521 83 Linux trickster:~> df -T Filesystem Type Size Used Avail Use% Mounted on /dev/hda6 xfs 239M 145M 95M 61% / /dev/hda10 xfs 3,0G 3,0G 40K 100% /backup /dev/hda9 xfs 15G 13G 1,7G 89% /home /dev/hda1 reiserfs 1020M 61M 960M 6% /tmp /dev/hda8 xfs 4,0G 3,2G 894M 79% /usr /dev/hda7 xfs 2,0G 1,4G 687M 67% /var /dev/hda11 xfs 50G 44G 5,5G 89% /var/ftp /tmp none 1020M 61M 960M 6% /var/tmp life:~> sudo fdisk -l /dev/hda Disk /dev/hda: 12.0 GB, 12072517632 bytes 255 heads, 63 sectors/track, 1467 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 32 257008+ a0 IBM Thinkpad hibernation /dev/hda2 33 223 1534207+ 83 Linux /dev/hda3 224 255 257040 82 Linux swap /dev/hda4 256 1467 9735390 5 Extended /dev/hda5 256 573 2554303+ 83 Linux /dev/hda6 574 1467 7181023+ 83 Linux life:~> df -T Filesystem Type Size Used Avail Use% Mounted on /dev/hda2 ext3 1,5G 1,4G 54M 97% / /dev/hda5 ext3 2,4G 2,1G 251M 90% /home /dev/hda6 reiserfs 6,9G 6,2G 671M 91% /var/ftp PS: извиняюсь за столь объёмный спам :) (но всё-таки дам копию в docs@, просьба следить за адресацией ответов) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-11-13 12:18 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-11-10 8:07 [Comm] копия /hda to /hdb Ivanov Maxim 2004-11-10 8:13 ` Genix 2004-11-10 8:14 ` Мар'ян Петришин 2004-11-10 10:06 ` Re[2]: " Ivanov Maxim 2004-11-10 10:18 ` Aleksey Avdeev 2004-11-10 10:50 ` Re[2]: " Ivanov Maxim 2004-11-10 11:43 ` [Comm] " Michael Shigorin 2004-11-10 12:12 ` Ivanov Maxim 2004-11-10 12:53 ` Michael Shigorin 2004-11-10 12:04 ` [Comm] " Aleksey Avdeev 2004-11-10 12:15 ` Re[2]: " Ivanov Maxim 2004-11-10 12:33 ` Aleksey Avdeev 2004-11-10 13:18 ` Re[2]: " Ivanov Maxim 2004-11-10 14:15 ` Aleksey Avdeev 2004-11-12 21:23 ` Денис Смирнов 2004-11-13 11:04 ` [Comm] " Michael Shigorin 2004-11-13 11:52 ` Gennadiy Redko 2004-11-13 12:18 ` Michael Shigorin [this message] 2004-11-13 14:26 ` Andrey Rahmatullin 2004-11-13 15:32 ` Денис Смирнов 2004-11-13 15:27 ` Денис Смирнов 2004-11-10 12:28 ` [Comm] " Nick S. Grechukh 2004-11-10 12:30 ` Re[2]: " Ivanov Maxim 2004-11-10 12:44 ` Nick S. Grechukh 2004-11-10 12:47 ` Aleksey Avdeev 2004-11-10 12:53 ` Re[2]: " Ivanov Maxim 2004-11-12 21:26 ` Денис Смирнов 2004-11-10 12:47 ` [Comm] " Michael Shigorin 2004-11-10 12:54 ` Ivanov Maxim 2004-11-10 12:55 ` [Comm] " Aleksey Avdeev 2004-11-10 13:44 ` Nick S. Grechukh 2004-11-10 13:51 ` Aleksey Avdeev 2004-11-11 10:33 ` Nick S. Grechukh 2004-11-11 10:43 ` Aleksey Avdeev 2004-11-10 12:45 ` [Comm] " Michael Shigorin 2004-11-10 13:18 ` Aleksey Avdeev 2004-11-10 13:38 ` Michael Shigorin 2004-11-10 17:35 ` Gennadiy Redko 2004-11-11 11:31 ` [Comm] [JT] " Michael Shigorin 2004-11-11 8:35 ` [Comm] " Aleksey Avdeev 2004-11-10 11:13 ` Re[2]: [Comm] " Mike Lykov 2004-11-10 11:21 ` Alexander Volkov 2004-11-10 8:17 ` Sodom 2004-11-10 9:26 ` Aleksey Avdeev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20041113121857.GH1863@osdn.org.ua \ --to=mike@osdn.org.ua \ --cc=community@altlinux.ru \ --cc=docs@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git