Re: Перенос системы с минимальной болью
On Thu, 23 Oct 2014 08:08:46 +0400 Victor Wagner wrote: VW Очевидно, есть два варианта, когда такое возможно VW 1. Мы копируем систему на другой диск и хотим, чтобы метки VW сохранились. Потому что какой же в них иначе смысл, если при VW апгрейде их менять придется? Разве что они более удобочитаемы, чем VW uuid-ы Временно меняем $LABEL на $LABELNEW, потом обратно. Это если речь идёт об апгрейде. Если будут сохранены оба диска, просто система переедет на новый, то переименовываем старый в $LABELOLD, для нового ставим метку $LABEL. VW 2. Мы подключаем чужой диск к своей системе, и метки случайно VW совпали. При этом подключаем не по-горячему Теоретически - да, возможно. На практике - вряд ли. Я пользуюсь метками, но ни разу не сталкивался с тем, чтобы их использовал кто-то другой, а уж с той же меткой... В общем, склонен считать этот пункт почти чисто теоретическим. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023142008.6b9c4...@desktop.home
Re: Перенос системы с минимальной болью
On 2014.10.23 at 14:20:08 +0400, Алексей Витальевич Коротков wrote: On Thu, 23 Oct 2014 08:08:46 +0400 Victor Wagner wrote: VW Очевидно, есть два варианта, когда такое возможно VW 1. Мы копируем систему на другой диск и хотим, чтобы метки VW сохранились. Потому что какой же в них иначе смысл, если при VW апгрейде их менять придется? Разве что они более удобочитаемы, чем VW uuid-ы Временно меняем $LABEL на $LABELNEW, потом обратно. Это если речь идёт об апгрейде. Если будут сохранены оба диска, просто система переедет на В процессе этой операции совершаем небольшую ошибку, и забываем переименовать один из 15 разделов, или просто до того, как поменяли метку, выключают электричество. Вообще чем безумно плохи и labels и uuids, так это тем, что когда у тебя на столе лежит вытащенный из машины диск, ты не можешь предсказать, как будут называться те разделы, которые на нем сейчас есть. Вот раньше, во времена узкого SCSI в BSD и Solaris можно было посмотреть на выставленный перемычками SCSI ID и сказать: Ага, вот я сейчас подключу это к третьей шине и оно будет /dev/c3d2p3. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023102524.ga11...@wagner.pp.ru
UUID=, LABEL=
Victor Wagner vi...@wagner.pp.ru writes: […] Вообще чем безумно плохи и labels и uuids, так это тем, что когда у тебя на столе лежит вытащенный из машины диск, ты не можешь предсказать, как будут называться те разделы, которые на нем сейчас есть. Вот раньше, во времена узкого SCSI в BSD и Solaris можно было посмотреть на выставленный перемычками SCSI ID и сказать: Ага, вот я сейчас подключу это к третьей шине и оно будет /dev/c3d2p3. «Аппаратные» идентификаторы пока никто не отменял. Если я сейчас подключу диск вот к этому порту SATA, — имя устройства найду в /sys/devices/pci:00/:00:0a.0/host1/target1:0:0/ 1:0:0:0/block/. Подозреваю, что если приклеить к носителю листок с UUID, именем группы томов LVM, или иной меткой, — задача окажется еще проще. -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbnbnjzw.fsf...@violet.siamics.net
Re: UUID=, LABEL=
В Thu, 23 Oct 2014 10:44:19 + Ivan Shmakov i...@siamics.net пишет: Victor Wagner vi...@wagner.pp.ru writes: […] Вообще чем безумно плохи и labels и uuids, так это тем, что когда у тебя на столе лежит вытащенный из машины диск, ты не можешь предсказать, как будут называться те разделы, которые на нем сейчас есть. Вот раньше, во времена узкого SCSI в BSD и Solaris можно было посмотреть на выставленный перемычками SCSI ID и сказать: Ага, вот я сейчас подключу это к третьей шине и оно будет /dev/c3d2p3. «Аппаратные» идентификаторы пока никто не отменял. Если я сейчас подключу диск вот к этому порту SATA, — имя устройства найду в /sys/devices/pci:00/:00:0a.0/host1/target1:0:0/ 1:0:0:0/block/. Подозреваю, что если приклеить к носителю листок с UUID, именем группы томов LVM, или иной меткой, — задача окажется еще проще. Актуальность листка еще нужно будет поддерживать. UUID и LABEL еще бывают вредны, если создать LVM снапшот и перезагрузиться. Бывает, что система монтирует снапшот, вместо оригинала. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023151310.0a788b51@dragoncore.local
Re: UUID=, LABEL=
Andrey Tataranovich tataranov...@gmail.com writes: В Thu, 23 Oct 2014 10:44:19 + Ivan Shmakov пишет: […] Подозреваю, что если приклеить к носителю листок с UUID, именем группы томов LVM, или иной меткой, — задача окажется еще проще. Актуальность листка еще нужно будет поддерживать. Да. Впрочем, — зависит от назначения. Отведенному под зеркало какого-нибудь http://e4ftl01.cr.usgs.gov/ НЖМД едва ли потребуется «реструктуризация». UUID и LABEL еще бывают вредны, если создать LVM снапшот и перезагрузиться. Бывает, что система монтирует снапшот, вместо оригинала. Если snapshot требуется для целей резервного копирования — следует сразу же перевести его в read-only (# lvchange -p r.) Если исходная ФС при этом подключается как read-write, — snapshot вместо нее подключен, очевидно, не будет. В других случаях, — не забывать перебивать UUID= (LABEL=) после создания snapshot. Можно даже отдельную программу (на shell) для этих целей создать. -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k33rndx1@violet.siamics.net
Re: UUID=, LABEL=
В Thu, 23 Oct 2014 12:55:38 + Ivan Shmakov i...@siamics.net пишет: Если snapshot требуется для целей резервного копирования — следует сразу же перевести его в read-only (# lvchange -p r.) Если исходная ФС при этом подключается как read-write, — snapshot вместо нее подключен, очевидно, не будет. В других случаях, — не забывать перебивать UUID= (LABEL=) после создания snapshot. Можно даже отдельную программу (на shell) для этих целей создать. Я сталкивался с ситуацией, когда сервер перезагружается в процессе бэкапа и соответственно снапшот остается. А потом не может загрузиться по причине неправильного монтирования (снапшот вместо оригинала). От чего это зависит я не разбирался, просто стал все LVM тома указывать по /dev/vg_name/lv_name. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023171224.154fcc78@dragoncore.local
Re: UUID=, LABEL=
Andrey Tataranovich tataranov...@gmail.com writes: В Thu, 23 Oct 2014 12:55:38 + Ivan Shmakov i...@siamics.net пишет: Если snapshot требуется для целей резервного копирования — следует сразу же перевести его в read-only (# lvchange -p r.) Если исходная ФС при этом подключается как read-write, — snapshot вместо нее подключен, очевидно, не будет. В других случаях, — не забывать перебивать UUID= (LABEL=) после создания snapshot. Можно даже отдельную программу (на shell) для этих целей создать. Я сталкивался с ситуацией, когда сервер перезагружается в процессе бэкапа и соответственно снапшот остается. А потом не может загрузиться по причине неправильного монтирования (снапшот вместо оригинала). Можно добавить что-то подобное фрагменту ниже в код резервного копирования, однако проблему возможной перезагрузки между lvcreate(8) и tune2fs(8) (или иной подобной) это, конечно, не решит. Но сделает несравнимо менее вероятной. # lvcreate --snapshot … tune2fs -U random -- $snapshot lvchange -p r -- $snapshot От чего это зависит я не разбирался, просто стал все LVM тома указывать по /dev/vg_name/lv_name. Имена группы и логического тома LVM — тоже вполне пригодные для использования метки. Кроме того, существуют еще и UUID /самих/ логических томов LVM, — независимые от размещаемых на них ФС. -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnp2om2a@violet.siamics.net
Re: UUID=, LABEL=
On 2014-10-23 10:44:19 +, Ivan Shmakov said: Вообще чем безумно плохи и labels и uuids, так это тем, что когда у тебя на столе лежит вытащенный из машины диск, ты не можешь предсказать, как будут называться те разделы, которые на нем сейчас есть. Вот раньше, во времена узкого SCSI в BSD и Solaris можно было посмотреть на выставленный перемычками SCSI ID и сказать: Ага, вот я сейчас подключу это к третьей шине и оно будет /dev/c3d2p3. «Аппаратные» идентификаторы пока никто не отменял. Если я сейчас подключу диск вот к этому порту SATA, — имя устройства найду в /sys/devices/pci:00/:00:0a.0/host1/target1:0:0/ 1:0:0:0/block/. Подозреваю, что если приклеить к носителю листок с UUID, именем группы томов LVM, или иной меткой, — задача окажется еще проще. Не надо листок клеить, на всех новых винтах есть WWN (вот например с WD - WWN: 50014EE0AD9207DD) и его можно увидеть в /dev/disk/by-id/wwn- . По крайней мере в nexenta (разновидность openindiana (opensolaris)) такая система монтирования по умолчанию, в принципе удобно, когда на карманах сервера написан WWN - получается без проблем нужный отключить и поменять. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2bk0t$kvk$1...@ger.gmane.org
