Linux жүйесіндегі LVM (Logical Volume Manager) – дискіні басқару құралы. Файлдық жүйелерді, көлемдерді бөлуге, өзгеруге және сақтауға көмектеседі. LVM2 туралы толық ақпарат!
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Linux үшін логикалық көлемді басқару бағдарламалық жасақтамасы
Logical volume management software for Linux
Linux жүйесінде Logical Volume Manager (LVM) – Linux ядросы үшін логикалық көлемдерді басқаруды қамтамасыз ететін құрылғы карталаушы фреймворкі. Көптеген қазіргі заманғы Linux дистрибутивтері LVM-ді қолдайды, сондықтан олардың түбірлік файлдық жүйелері логикалық томда орналасуы мүмкін. Хайнц Мауэлшаген 1998 жылы Sistina Software компаниясында жұмыс істеген кезде LVM кодын жазды, оның негізгі дизайндық принциптерін HP UX көлемді басқарушысынан алды. немесе оқу/жазу көшірмелері (LVM2). Егер логикалық томдар (LV) бөліністі қамтымаса, көлемдік топтар (VG) орын ауыстырусыз бөліне де, біріктіріле де алады. Бұл бүкіл LV-ді офлайн сақтау құрылымына немесе одан көшіру кезінде пайдалы болуы мүмкін. LVM объектілерін әкімшілік жұмысын жеңілдету үшін таңбалауға болады. Негізгі құрылғылар қолжетімді болғанда, lvmetad қызметін пайдаланып VG және LV-ларды белсенді етуге болады.
In Linux, Logical Volume Manager (LVM) is a device mapper framework that provides logical volume management for the Linux kernel. Most modern Linux distributions are LVM aware to the point of being able to have their root file systems on a logical volume. Heinz Mauelshagen wrote the original LVM code in 1998, when he was working at Sistina Software, taking its primary design guidelines from the HP UX's volume manager. or read/write snapshots (LVM2)
VGs can be split or merged in situ as long as no LVs span the split. This can be useful when migrating whole LVs to or from offline storage. LVM objects can be tagged for administrative convenience. VGs and LVs can be made active as the underlying devices become available through use of the lvmetad daemon.
Қосымша функционалдық
Гибридті томдар dm кэш мақсатын пайдаланып құруға болады, ол бір немесе бірнеше жылдам сақтау құрылғыларына, мысалы, флэш-негізгі SSD-лерге, бір немесе бірнеше баяу қатты дискілер үшін кэш ретінде жұмыс істеуге мүмкіндік береді. Жұқа қамтамасыз етілген LV-лер жиынтықтан бөлінеді. Құрылғы картасының жаңа нұсқаларында LVM, егер lvm.conf файлында құрылғылар/көпжолды компонентті анықтау=1 параметрі орнатылса, dm көпжолды құрылғының негізінде жатқан жеке жолдарды елемеуге жеткілікті деңгейде құрылғы картасының қалған бөлігімен интеграцияланған. Бұл LVM-ге көпжолды құрылғының орнына жеке жол бойынша томдарды белсендіруге кедергі келтіреді.
Hybrid volumes can be created using the dm cache target, which allows one or more fast storage devices, such as flash based SSDs, to act as a cache for one or more slower hard disk drives. Thinly provisioned LVs can be allocated from a pool. On newer versions of device mapper, LVM is integrated with the rest of device mapper enough to ignore the individual paths that back a dm multipath device if devices/multipath component detection=1 is set in lvm. conf. This prevents LVM from activating volumes on an individual path instead of the multipath device.
RAID
LV-ларды RAID функционалдығын қосу үшін құруға болады, оның ішінде RAID 1, 5 және 6 түрлерін. LV-лардың толық көлемі немесе олардың бөліктері RAID 0-ге ұқсас бірнеше PV-ға жолақты орналастырылуы мүмкін. RAID 1 артқы құрылғысы (PV) "көбінесе жазу" режимінде конфигурациялануы мүмкін, бұл қажет болмаса, осы құрылғылардан оқуды болдырмайды. LV-ны қайта құру кезінде қанағаттанарлық I/O өнімділігін сақтау үшін lvchange raidmaxrecoveryrate және lvchange raidminrecoveryrate командаларын пайдаланып, қалпына келтіру жылдамдығын шектеуге болады.
LVs can be created to include RAID functionality, including RAID 1, 5 and 6. Entire LVs or their parts can be striped across multiple PVs, similarly to RAID 0. A RAID 1 backend device (a PV) can be configured as "write mostly", resulting in reads being avoided to such devices unless necessary. Recovery rate can be limited using lvchange raidmaxrecoveryrate and lvchange raidminrecoveryrate to maintain acceptable I/O performance while rebuilding a LV that includes RAID functionality.
Қақпақтар
Linux ядросының 2.6.31 нұсқасына дейін жазу кедергілері толық қолдау таппады (2.6.33 нұсқасында толық қолдау көрсетілді). Бұл, ext3 және XFS сияқты журналмен сақталатын файлдық жүйелер ұсынған файлдық жүйенің зақымдануына қарсы кепілдік, кейбір жағдайларда күшін жойды дегенді білдіреді. 2015 жылға дейін LVM үшін онлайн немесе оффлайн дефрагментация бағдарламасы болған жоқ. Бұл мәселе көлемді кеңейту кезінде ғана фрагментация пайда болуымен және жоғарыда аталған бөлу саясатын қолдану арқылы біршама азайтылады. Алайда, фрагментация орын ала береді, және оны азайту үшін, үздірілмеген бөлімдерді анықтап, pvmove командасын қолдана отырып қолмен қайта орналастыру қажет. Көптеген LVM конфигурацияларында әрбір физикалық томға (PV) LVM бас файлының тек бір көшірмесі сақталады, бұл томдарды дискідегі бұзылған секторларға осалдырақ етеді. Бұл әрекетті vgconvert pvmetadatacopies командасын қолдану арқылы өзгертуге болады. Егер LVM бірінші көшірме арқылы дұрыс бас файлды оқи алмаса, томның соңындағы резервтік бас файлды тексереді. Көптеген Linux дистрибутивтері /etc/lvm/backup каталогында жұмыс істеп тұрған резервтік көшірмені сақтайды, бұл vgcfgrestore командасын қолдана отырып, зақымдалған LVM бас файлын қолмен қайта жазуға мүмкіндік береді.
Until Linux kernel 2.6.31, write barriers were not supported (fully supported in 2.6.33). This means that the guarantee against filesystem corruption offered by journaled file systems like ext3 and XFS was negated under some circumstances. as of 2015, no online or offline defragmentation program exists for LVM. This is somewhat mitigated by fragmentation only happening if a volume is expanded and by applying the above mentioned allocation policies. Fragmentation still occurs, however, and if it is to be reduced, non contiguous extents must be identified and manually rearranged using the pvmove command. On most LVM setups, only one copy of the LVM head is saved to each PV, which can make the volumes more susceptible to failed disk sectors. This behavior can be overridden using vgconvert pvmetadatacopies. If the LVM can not read a proper header using the first copy, it will check the end of the volume for a backup header. Most Linux distributions keep a running backup in /etc/lvm/backup, which enables manual rewriting of a corrupted LVM head using the vgcfgrestore command.