LVM අන්තරායන් සහ අනතුරු ඇඟවීම්

1 TB ට වඩා විශාල දෘ hard තැටි සඳහා මම මෑතකදී සමහර සේවාදායකයන්හි LVM භාවිතා කිරීම ආරම්භ කළෙමි. ඒවා ප්‍රයෝජනවත්, පුළුල් කළ හැකි සහ ස්ථාපනය කිරීමට පහසුය. කෙසේ වෙතත්, එල්වීඑම් හි අන්තරායන් සහ අනතුරු ඇඟවීම් පිළිබඳ කිසිදු දත්තයක් මට සොයාගත නොහැකි විය.

LVM භාවිතා කිරීමේ අවාසි මොනවාද?

සාරාංශය

LVM භාවිතා කිරීමේ අවදානම්:

• එස්එස්ඩී හෝ වීඑම් හයිපර්වයිසර් සමඟ හැඹිලි ගැටළු ලිවීමට අවදානමක් ඇත
• වඩාත් සංකීර්ණ තැටි ව්‍යුහයන් නිසා දත්ත නැවත ලබා ගැනීම දුෂ්කර ය
• ගොනු පද්ධති නිවැරදිව ප්‍රමාණය වෙනස් කිරීම දුෂ්කර ය
• ස්නැප්ෂොට් භාවිතා කිරීම අපහසුය, මන්දගාමී සහ දෝෂ සහිතය
• මෙම ගැටළු නිවැරදිව වින්‍යාස කිරීමට යම් නිපුණතාවයක් අවශ්‍ය වේ

පළමු LVM ගැටළු දෙක ඒකාබද්ධ වේ: ලිවීමේ හැඹිලිය නිවැරදිව ක්‍රියා නොකරන්නේ නම් සහ ඔබට විදුලිය නැතිවීමක් තිබේ නම් (උදා: PSU හෝ UPS අසමත් වේ), ඔබට උපස්ථයෙන් යථා තත්ත්වයට පත් වීමට සිදුවනු ඇත, එනම් සැලකිය යුතු අක්‍රීය කාලයක්. LVM භාවිතා කිරීමට ප්‍රධාන හේතුවක් වන්නේ වැඩි වේලාවක් (තැටි එකතු කිරීමේදී, ගොනු පද්ධති ප්‍රමාණය වෙනස් කිරීම යනාදියයි), නමුත් LVM ඇත්ත වශයෙන්ම අතිකාල අඩු කිරීම වළක්වා ගැනීම සඳහා ලිවීමේ හැඹිලි සැකසුම නිවැරදිව ලබා ගැනීම වැදගත්ය.

- යාවත්කාලීන කරන ලද්දේ 2019 දෙසැම්බර්: LVM ස්නැප්ෂොට් වලට විකල්පයක් ලෙස btrfs සහ ZFS පිළිබඳ සුළු යාවත්කාලීන කිරීම්

අවදානම් අවම කිරීම

ඔබ නම් LVM තවමත් හොඳින් ක්‍රියා කළ හැකිය:

• ඔබගේ ලිවීමේ හැඹිලි සැකසුම හයිපර්වයිසර්, කර්නලය සහ එස්එස්ඩී වලින් ලබා ගන්න
• LVM ස්නැප්ෂොට් වලින් වළකින්න
• ගොනු පද්ධති ප්‍රමාණය වෙනස් කිරීමට මෑත LVM අනුවාද භාවිතා කරන්න
• හොඳ උපස්ථ ලබා ගන්න

විස්තර

LVM හා සම්බන්ධ දත්ත අලාභයක් අත්විඳ ඇති මම අතීතයේ දී මේ පිළිබඳව තරමක් පර්යේෂණ කර ඇත්තෙමි. ප්‍රධාන LVM අවදානම් සහ මා දන්නා ගැටළු:

වීඑම් හයිපර්වයිසර්, ඩිස්ක් හැඹිලි හෝ පැරණි ලිනක්ස් කර්නල් නිසා දෘඩ තැටි ලිවීමේ හැඹිලි වලට ගොදුරු විය හැකි අතර වඩාත් සංකීර්ණ තැටි ව්‍යුහයන් නිසා දත්ත නැවත ලබා ගැනීම දුෂ්කර කරයි - විස්තර සඳහා පහත බලන්න. යථා තත්වයට පත්වීමේ අවදානමකින් තොරව තැටි කිහිපයක සම්පූර්ණ LVM සැකසුම් දූෂිත වී ඇති බව මම දැක ඇත්තෙමි, LVM ප්ලස් හාඩ් ඩිස්ක් ලිවීමේ හැඹිලිය භයානක සංයෝජනයකි.

• දෘ c තැටිය මඟින් හැඹිලි ලිවීම සහ නැවත ඇණවුම් කිරීම හොඳ කාර්ය සාධනය සඳහා වැදගත් වන නමුත් වීඑම් හයිපර්වයිසර්, දෘ hard තැටි ලිවීමේ හැඹිලි, පැරණි ලිනක්ස් කර්නල් ආදිය නිසා බ්ලොක් නිවැරදිව තැටියට හරවා ගැනීමට අසමත් විය හැකිය.
  • ලිවීමේ බාධක යන්නෙන් අදහස් වන්නේ කර්නලය "බාධක" තැටිය ලිවීමට පෙර ඇතැම් තැටි ලිවීම් සම්පුර්ණ කරන බවට සහතික වන අතර, හදිසි පද්ධති අලාභයක් හෝ බිඳවැටීමකදී ගොනු පද්ධති සහ RAID යථා තත්වයට පත් විය හැකි බව සහතික කිරීමයි. එවැනි බාධක වලට FUA (Force Unit Access) මෙහෙයුමක් භාවිතා කර තැටියට වහාම යම් කොටස් ලිවිය හැකිය, එය සම්පූර්ණ හැඹිලි නළයකට වඩා කාර්යක්ෂම වේ. දත්ත නැතිවීමේ අවදානම වැඩි නොකර බුද්ධිමත් ලිවීම් නැවත ඇණවුම් කිරීමට දෘ drive තැටියට හැකි වන පරිදි කාර්යක්ෂම ටැග් / ස්වදේශීය විධාන පෝලිම් (එකවර බහුවිධ තැටි I / O ඉල්ලීම් නිකුත් කිරීම) සමඟ බාධක ඒකාබද්ධ කළ හැකිය .
• VM හයිපර්වයිසර් වලට සමාන ගැටළු තිබිය හැකිය: VMware, Xen , KVM, Hyper-V හෝ VirtualBox වැනි VM හයිපර්වයිසර් එකක් මත ලිනක්ස් ආගන්තුකයෙකු තුළ LVM ධාවනය කිරීම ලිවීමේ බාධක නොමැතිව කර්නලයකට සමාන ගැටළු ඇති කළ හැකිය. ඇණවුම් කිරීම. "ඩිස්ක් ෆ්ලෂ්" හෝ ලිඛිත හැඹිලි විකල්පය ( කේවීඑම් , වීඑම්වෙයාර් , එක්ස් , වර්චුවල් බොක්ස් සහ වෙනත් අය තුළ තිබේ) සඳහා ඔබේ හයිපර්වයිසර් ප්‍රලේඛනය ප්‍රවේශමෙන් පරීක්ෂා කරන්න - ඔබේ සැකසුම සමඟ එය පරීක්ෂා කරන්න. වර්චුවල් බොක්ස් වැනි සමහර හයිපර්වයිසර් වල පෙරනිමි සැකසුමක් ඇති අතර එය ආගන්තුකයාගෙන් ඕනෑම තැටි ප්‍රවාහයක් නොසලකා හරියි.
• LVM සහිත ව්‍යවසාය සේවාදායකයන් සැමවිටම බැටරි පිටුබලය සහිත RAID පාලකය භාවිතා කළ යුතු අතර දෘ disk තැටි ලිවීමේ හැඹිලිය අක්‍රීය කළ යුතුය (පාලකයට බැටරි පිටුබලය සහිත ලිවීමේ හැඹිලිය වේගවත් හා ආරක්ෂිතයි) - මෙම XFS නිති අසන ප්‍රශ්න ඇතුළත් කිරීමේ කතුවරයාගේ මෙම අදහස බලන්න . කර්නලයේ ලිවීමේ බාධක අක්‍රිය කිරීමද ආරක්ෂිත විය හැකි නමුත් පරීක්ෂා කිරීම රෙකමදාරු කරනු ලැබේ.
• ඔබට බැටරි පිටුබලය සහිත RAID පාලකයක් නොමැති නම්, දෘ hard තැටි ලිවීමේ හැඹිලිය අක්‍රීය කිරීමෙන් ලිවීම් සැලකිය යුතු ලෙස මන්දගාමී වන නමුත් LVM ආරක්ෂිත වේ. ඔබ ext3 හි data=orderedවිකල්පයට සමාන (හෝ data=journalඅමතර ආරක්ෂාව සඳහා) භාවිතා කළ යුතුය, තවද barrier=1කර්නල් හැඹිලි අඛණ්ඩතාවයට බලපාන්නේ නැති බව සහතික කිරීම. (හෝ පෙරනිමියෙන් බාධක සක්‍රීය කරන ext4 භාවිතා කරන්න .) මෙය සරලම විකල්පය වන අතර කාර්ය සාධන පිරිවැය අනුව හොඳ දත්ත අඛණ්ඩතාව සපයයි. (ලිනක්ස් පෙරනිමි ext3 විකල්පයdata=writeback ටික කලකට පෙර වඩා භයානක ලෙස වෙනස් කළේය , එබැවින් FS සඳහා පෙරනිමි සැකසුම් මත රඳා නොසිටින්න.)
• දෘ drive තැටි ලිවීමේ හැඹිලි අක්‍රීය කිරීමට : (SATA සඳහා) hdparm -q -W0 /dev/sdXසියලුම ධාවක සඳහා එක් කරන්න /etc/rc.localහෝ SCSI / SAS සඳහා sdparm භාවිතා කරන්න. කෙසේ වෙතත්, එක්ස්එෆ්එස් නිති අසන ප්‍රශ්නවල මෙම ප්‍රවේශයට අනුව (මෙම මාතෘකාව පිළිබඳ එය ඉතා හොඳයි), ධාවක දෝෂයක් යථා තත්ත්වයට පත්වීමෙන් පසු SATA ධාවකය මෙම සැකසුම අමතක කළ හැකිය - එබැවින් ඔබ SCSI / SAS භාවිතා කළ යුතුය, නැතහොත් ඔබ SATA භාවිතා කළ යුතු නම් hdparm විධානය සෑම මිනිත්තුවක් හෝ ඊට වැඩි කාලයක් ක්‍රියාත්මක වන ක්‍රෝන් රැකියාවක.
• වඩා හොඳ ක්‍රියාකාරීත්වයක් සඳහා SSD / දෘ drive තැටි ලිවීමේ හැඹිලි සක්‍රීයව තබා ගැනීමට : මෙය සංකීර්ණ ප්‍රදේශයකි - පහත කොටස බලන්න.
• ඔබ උසස් ආකෘති ධාවක එනම් 4 KB භෞතික අංශ භාවිතා කරන්නේ නම් , පහත බලන්න - ලිවීමේ හැඹිලි අක්‍රීය කිරීම වෙනත් ගැටළු ඇති විය හැකිය.
• UPS ව්යවසාය හා සොහෝ යන දෙකම සඳහා තීරණාත්මක නමුත් LVM ආරක්ෂිත කිරීමට ප්රමාණවත් නොවේ: දෘඪ අනතුර හේතු හෝ බලය අහිමි (උදා: UPS අසමත් වීමත්, PSU අසමත් වීමත්, හෝ ලැප්ටොප් බැටරි හිඟ වීම), දෘඪ තැටියේ හැඹිලි දත්ත අහිමි විය හැක ඕනෑම දෙයක්.
• ඉතා පැරණි ලිනක්ස් කර්නල් (2009 සිට 2.6.x) : ඉතා පැරණි කර්නල් අනුවාද වල අසම්පූර්ණ ලිවීමේ බාධක සහය ඇත, 2.6.32 සහ ඊට පෙර ( 2.6.31 ට යම් සහයක් ඇති අතර 2.6.33 සියලු වර්ගවල උපාංග ඉලක්ක සඳහා ක්‍රියා කරයි ) - RHEL 6 බොහෝ පැච් සමඟ 2.6.32 භාවිතා කරයි . මෙම ගැටළු සඳහා මෙම පැරණි 2.6 කර්නල් නොගැලපේ නම්, දෘ hard තැටිවල ලිවීමේ බෆර වල දත්ත ඉතිරි වන දෘඩ බිඳවැටීමකින් එෆ්එස් පාර-දත්ත විශාල ප්‍රමාණයක් (සඟරා ඇතුළුව) නැතිවිය හැකිය (පොදු SATA ධාවක සඳහා එක් ධාවකයකට 32 MB යැයි කියන්න). කර්නලය දැනටමත් තැටියේ ඇතැයි සිතන ඉතා මෑතකදී ලියන ලද එෆ්එස් පාර-දත්ත සහ ජර්නල් දත්ත 32MB අහිමි වීම සාමාන්‍යයෙන් අදහස් කරන්නේ බොහෝ එෆ්එස් දූෂණ සහ ඒ නිසා දත්ත නැතිවීමයි.
• සාරාංශය: LVM සමඟ භාවිතා කරන ගොනු පද්ධතිය, RAID, VM හයිපර්වයිසර් සහ දෘ hard තැටිය / SSD සැකසුම පිළිබඳව ඔබ සැලකිලිමත් විය යුතුය. ඔබ LVM භාවිතා කරන්නේ නම් ඔබට ඉතා හොඳ උපස්ථ තිබිය යුතු අතර, LVM පාර-දත්ත, භෞතික කොටස් සැකසුම, MBR සහ පරිමාව ඇරඹුම් අංශ විශේෂයෙන් උපස්ථ කිරීමට වග බලා ගන්න. SCSI / SAS ඩ්‍රයිව් භාවිතා කිරීම සුදුසුය, මන්ද ඒවා හැඹිලි ලිවීමේ ආකාරය ගැන බොරු කීමට ඇති ඉඩකඩ අඩුය - SATA ඩ්‍රයිව් භාවිතා කිරීමට වැඩි සැලකිල්ලක් අවශ්‍ය වේ.

කාර්ය සාධනය සඳහා ලිඛිත හැඹිලි සක්‍රීයව තබා ගැනීම (සහ බොරු ධාවකයන් සමඟ කටයුතු කිරීම)

වඩාත් සංකීර්ණ නමුත් ක්‍රියාකාරී විකල්පයක් වන්නේ එස්එස්ඩී / දෘ hard තැටි ලිවීමේ හැඹිලි සක්‍රීය කර තබා ගැනීම සහ කර්නල් 2.6.33+ මත එල්වීඑම් සමඟ වැඩ කරන කර්නල් ලිවීමේ බාධක මත යැපීමයි (ල logs ු-සටහන් වල “බාධක” පණිවිඩ සෙවීමෙන් දෙවරක් පරීක්ෂා කරන්න).

RAID සැකසුම, වීඑම් හයිපර්වයිසර් සැකසුම සහ ගොනු පද්ධතිය ලිවීමේ බාධක භාවිතා කරන බවට ඔබ සහතික විය යුතුය (එනම් යතුරු පාර-දත්ත / ජර්නල් ලිවීමට පෙර සහ පසු අපේක්ෂිත ලිපි ලිවීමට ධාවකය අවශ්‍ය වේ). එක්ස්එෆ්එස් පෙරනිමියෙන් බාධක භාවිතා කරයි, නමුත් ext3 එසේ නොවේ , එබැවින් ext3 සමඟ ඔබ barrier=1සවිකිරීමේ විකල්පයන්හි භාවිතා කළ යුතු අතර, තවමත් භාවිතා කරන්න data=orderedහෝ data=journalඉහත පරිදි භාවිතා කරන්න .

• අවාසනාවකට මෙන්, සමහර දෘ hard තැටි සහ එස්එස්ඩී යන් ඔවුන්ගේ හැඹිලිය තැටියට සැබවින්ම ගසා තිබේද යන්න ගැන බොරු කියති (විශේෂයෙන් පැරණි ඩ්‍රයිව්, නමුත් සමහර SATA ඩ්‍රයිව් සහ සමහර ව්‍යවසාය එස්එස්ඩී ද ඇතුළුව ) - වැඩි විස්තර මෙතැනින් . ඒ නිසා එය ඉතා XFS කරලම මහා සාරාංශයක් .
• එය තියෙනවා බොරු ධාවකයන් සඳහා පරීක්ෂා කිරීම ඉතා මෙවලමක් (perl බසට ලං තිර රචනය), හෝ දැක මෙවලමක් සහිතව මෙම පසුබිම තල්ලුව හැඹිලි ප්රතිඵලයක් ලෙස කපා නැවත ඇනවුම් කිරීම සඳහා පරීක්ෂා කිරීම. මෙම පිළිතුර මෘදුකාංග RAID හි ලිවීමේ බාධක ගැටලුවක් අනාවරණය කරගත් SATA ඩ්‍රයිව්වල සමාන පරීක්ෂණයක් ආවරණය කරයි - මෙම පරීක්ෂණ ඇත්ත වශයෙන්ම මුළු ගබඩා තොගයම ක්‍රියාත්මක කරයි.
• ස්වදේශීය විධාන පෝලිම් (NCQ) සඳහා සහය දක්වන වඩාත් මෑත SATA ඩ්‍රයිව් බොරු කීමට ඇති ඉඩකඩ අඩු විය හැකිය - නැතහොත් NCQ නිසා ලිඛිත හැඹිලි නොමැතිව ඒවා හොඳින් ක්‍රියා කරයි, සහ ඩ්‍රයිව් ස්වල්පයකට ලිවීමේ හැඹිලි අක්‍රීය කළ නොහැක.
• SCSI / SAS ඩ්‍රයිව් සාමාන්‍යයෙන් හොඳින් ක්‍රියා කිරීමට ලිඛිත හැඹිලි අවශ්‍ය නොවන බැවින් ( SATA හි NCQ හා සමාන SCSI Tagged Command Queying හරහා ).
• ඔබේ දෘ hard තැටි හෝ එස්එස්ඩී ඔවුන්ගේ හැඹිලිය තැටියට ගලායාම ගැන බොරු කියනවා නම්, ඔබට සැබවින්ම ලිවීමේ බාධක මත විශ්වාසය තැබිය නොහැකි අතර ලිවීමේ හැඹිලි අක්‍රීය කළ යුතුය. LVM පමණක් නොව සියලුම ගොනු පද්ධති, දත්ත සමුදායන්, වෙළුම් කළමණාකරුවන් සහ මෘදුකාංග RAID සඳහා මෙය ගැටළුවකි .

SSDs ගැටළු සහගත වන්නේ ලිඛිත හැඹිලි භාවිතය SSD හි ජීවිත කාලය සඳහා ඉතා වැදගත් වන බැවිනි. සුපිරි ධාරිත්‍රකයක් ඇති එස්එස්ඩී එකක් භාවිතා කිරීම වඩාත් සුදුසුය (විදුලිය ඇනහිටීම මත හැඹිලි ප්‍රවාහය සක්‍රීය කිරීම සඳහා, එම නිසා හැඹිලිය නැවත ලිවීමට නොව ලිවීමට හැකි වේ).

• බොහෝ ව්‍යවසාය SSDs ලිවීමේ හැඹිලි පාලනය සම්බන්ධයෙන් නිවැරදි විය යුතු අතර සමහර ඒවාට සුපිරි ධාරිත්රක ඇතුළත් වේ.
• සමහර ලාභදායී එස්එස්ඩී වලට ලිවීම්-හැඹිලි වින්‍යාසය සමඟ විසඳිය නොහැකි ගැටළු ඇත - පෝස්ට්ග්‍රෙස්ක්එල් ව්‍යාපෘතියේ තැපැල් ලැයිස්තුව සහ විශ්වාසනීය ලියවිලි විකී පිටුව හොඳ තොරතුරු ප්‍රභවයන් වේ. පාරිභෝගික එස්එස්ඩී වලට දත්ත නැතිවීමට හේතු වන ප්‍රධාන ලිඛිත හැඹිලි ගැටළු ඇති විය හැකි අතර, සුපිරි ධාරිත්‍රක ඇතුළත් නොකරන්න, එවිට දූෂණයට හේතු වන විදුලි බිඳවැටීම් වලට ගොදුරු වේ.

උසස් ෆෝමැට් ඩ්‍රයිව් සැකසුම - හැඹිලි ලිවීම, පෙළගැස්ම, RAID, GPT

• කිබ් භෞතික අංශ 4 ක් භාවිතා කරන නවතම උසස් ෆෝමැට් ඩ්‍රයිව් සමඟ , ඩ්‍රයිව් ලිවීමේ හැඹිලි සක්‍රීයව තබා ගැනීම වැදගත් විය හැකිය, මන්ද එවැනි ඩ්‍රයිව් බොහෝමයක් දැනට බයිට් 512 තාර්කික අංශ ( "512 ඉමියුලේෂන්" ) අනුකරණය කරන අතර සමහරු බයිට් 512 භෞතික ඇති බව කියා සිටිති. අංශ 4 KiB භාවිතා කරන අතරතුර.
• උසස් ෆෝමැට් ඩ්‍රයිව් එකක ලිවීමේ හැඹිලිය අක්‍රිය කිරීමෙන් යෙදුම / කර්නලය බයිට් 512 ක් ලියන්නේ නම් එය ඉතා විශාල කාර්ය සාධන බලපෑමක් ඇති කළ හැකිය, එවැනි ඩ්‍රයිව් 4 කිබී භෞතිකයක් කිරීමට පෙර 8 x 512-බයිට් ලිවීම් රැස් කිරීමට හැඹිලිය මත රඳා පවතී. ලියන්න. ඔබ හැඹිලිය අක්‍රිය කරන්නේ නම් ඕනෑම බලපෑමක් තහවුරු කිරීම සඳහා පරීක්ෂණ නිර්දේශ කෙරේ.
• LVs 4 KiB මායිමකට පෙළගැස්වීම කාර්ය සාධනය සඳහා වැදගත් වන නමුත් PV සඳහා පාදක කොටස් පෙලගැසී ඇති තාක් කල් ස්වයංක්‍රීයව සිදුවිය යුතුය, මන්ද LVM භෞතික දිගුවන් (PEs) පෙරනිමියෙන් 4 MiB වේ. RAID මෙහි සලකා බැලිය යුතුය - මෙම LVM සහ මෘදුකාංග RAID සැකසුම් පිටුව යෝජනා කරන්නේ පරිමාව අවසානයේ RAID සුපර් බ්ලොක් තැබිය යුතු අතර (අවශ්‍ය නම්) pvcreatePV පෙළගැස්වීමට විකල්පයක් භාවිතා කිරීමයි . මෙම LVM ඊමේල් ලැයිස්තු නූල් මඟින් 2011 දී කර්නල් වල සිදු කරන ලද කාර්යයන් පෙන්වා දෙන අතර එක් LV එකක බයිට් 512 සහ KiB අංශ 4 ක් සමඟ තැටි මිශ්‍ර කිරීමේදී අර්ධ වාරණ ලිවීම පිළිබඳ ගැටළුව ලියයි.
• උසස් ආකෘතිය සමඟ ජීපීටී කොටස් කිරීම , විශේෂයෙන් ඇරඹුම් + මූල තැටි සඳහා, පළමු එල්වීඑම් කොටස (පීවී) 4 කිබී මායිමකින් ආරම්භ වන බව සහතික කිරීම සඳහා සැලකිලිමත් විය යුතුය.

වඩාත් සංකීර්ණ තැටි ව්‍යුහයන් නිසා දත්ත නැවත ලබා ගැනීම දුෂ්කර ය :

• දෘඩ බිඳවැටීමකින් හෝ විදුලිය අහිමිවීමකින් පසු අවශ්‍ය වන LVM දත්ත නැවත ලබා ගැනීම (වැරදි ලිවීම් හැඹිලියක් හේතුවෙන්) අතින් සිදුකරන ක්‍රියාවලියකි, මන්ද පෙනෙන පරිදි සුදුසු මෙවලම් නොමැති බැවිනි. LVM එහි පාර-දත්ත /etc/lvmඋපස්ථ කිරීම හොඳය, එය LV, VG සහ PV වල මූලික ව්‍යුහය යථා තත්වයට පත් කිරීමට උපකාරී වන නමුත් නැතිවූ ගොනු පද්ධති පාර-දත්ත සමඟ උදව් නොකරනු ඇත.
• එබැවින් උපස්ථයෙන් පූර්ණ ප්‍රතිෂ් restore ාපනයක් අවශ්‍ය වනු ඇත. LVM භාවිතා නොකරන විට ඉක්මන් ජර්නල් පාදක fsck ට වඩා වැඩි අක්‍රීයතාවයක් මෙයට ඇතුළත් වන අතර අවසාන උපස්ථයේ සිට ලියා ඇති දත්ත නැති වී යයි.
• TestDisk , ext3grep , ext3undel සහ වෙනත් මෙවලම් වලට LVM නොවන තැටි වලින් කොටස් සහ ලිපිගොනු නැවත ලබා ගත හැකි නමුත් ඒවා LVM දත්ත ප්‍රතිසාධනයට සෘජුවම සහාය නොදක්වයි. නැතිවූ භෞතික කොටසක LVM PV අඩංගු බව ටෙස්ට් ඩිස්ක් හට සොයාගත හැකි නමුත් මෙම මෙවලම් කිසිවක් LVM තාර්කික පරිමාවන් තේරුම් නොගනී. ෆොටෝරෙක් සහ තවත් බොහෝ ගොනු කැටයම් මෙවලම් දත්ත පද්ධතියෙන් ගොනු නැවත එක්රැස් කිරීම සඳහා ගොනු පද්ධතිය මඟ හරින විට ක්‍රියා කරනු ඇත, නමුත් මෙය වටිනා දත්ත සඳහා අවසාන මට්ටමේ, පහත් මට්ටමේ ප්‍රවේශයක් වන අතර කැබලි කරන ලද ලිපිගොනු සමඟ හොඳින් ක්‍රියා කරයි.
• අතින් LVM ප්‍රතිසාධනය සමහර අවස්ථාවලදී කළ හැකි නමුත් සංකීර්ණ හා කාලය ගත වේ - මෙම උදාහරණය බලන්න සහ මෙය , මෙය සහ මෙය යථා තත්වයට පත් වන්නේ කෙසේද යන්න බලන්න.

ගොනු පද්ධති නිවැරදිව ප්‍රතිප්‍රමාණනය කිරීම අසීරුය - පහසු ගොනු පද්ධති ප්‍රතිප්‍රමාණනය බොහෝ විට LVM හි ප්‍රතිලාභයක් ලෙස ලබා දී ඇත, නමුත් LVM මත පදනම් වූ FS ප්‍රමාණය වෙනස් කිරීම සඳහා ඔබට ෂෙල් විධාන දුසිම් භාගයක් ධාවනය කළ යුතුය - මෙය සම්පූර්ණ සේවාදායකය සමඟ තවමත් කළ හැකි අතර සමහර අවස්ථාවලදී එෆ්එස් සවිකර ඇති නමුත් යාවත්කාලීන උපස්ථ නොමැතිව සහ සමාන සේවාදායකයක පෙර පරීක්‍ෂා කළ විධාන භාවිතා නොකර මම කිසි විටෙකත් අවදානමට ලක් නොකරමි (උදා: නිෂ්පාදන සේවාදායකයේ ආපදා ප්‍රතිසාධන ක්ලෝනය).

• යාවත්කාලීන කිරීම: තවත් මෑත සංස්කරණ lvextendසහාය -r( --resizefs) විකල්පය - මෙම ලබා ගත හැකි නම්, එය LV හා ගොනු පද්ධතිය නැවත ප්රමාණය ආරක්ෂිත හා ක්ෂණික විදිහට, ඔබ FS, හැකිලෙන කර ඇති අතර, ඔබ බොහෝ දුරට මෙම කොටස මඟ හැරිය හැක, විශේෂයෙන් නම් වේ.
• LVM මත පදනම් වූ FS ප්‍රමාණය වෙනස් කිරීම සඳහා බොහෝ මාර්ගෝපදේශකයින් FS LV ප්‍රමාණයට වඩා තරමක් කුඩා විය යුතුය යන කාරණය සැලකිල්ලට නොගනී: මෙහි සවිස්තරාත්මක පැහැදිලි කිරීම . ගොනු පද්ධතියක් හැකිලෙන විට, ඔබට නව ප්‍රමාණය FS ප්‍රමාණය වෙනස් කිරීමේ මෙවලමට නියම කිරීමට අවශ්‍ය වනු ඇත, උදා: resize2fsext3 සඳහා, සහ lvextendහෝ lvreduce. 1 GB (10 ^ 9) සහ 1 GiB (2 ^ 30) අතර වෙනස නිසා හෝ විවිධ මෙවලම් වටේට ඉහළට හෝ පහළට ගමන් කරන ආකාරය නිසා විශාල සැලකිල්ලකින් තොරව ප්‍රමාණයන් තරමක් වෙනස් විය හැකිය .
• ඔබ ගණනය කිරීම් හරියටම නොකරන්නේ නම් (හෝ වඩාත්ම පැහැදිලිව පෙනෙන පියවරෙන් ඔබ්බට අමතර පියවර කිහිපයක් භාවිතා කරන්න), ඔබට අවසන් විය හැක්කේ LV වලට වඩා විශාල FS ය. ඔබ එෆ්එස් සම්පූර්ණයෙන් පුරවන තුරු සෑම දෙයක්ම මාස හෝ අවුරුදු ගණනක් හොඳින් පෙනෙනු ඇත, එම අවස්ථාවේදී ඔබට බරපතල දූෂණයක් සිදුවනු ඇත - තවද මෙම ගැටලුව පිළිබඳව ඔබ නොදැන සිටියහොත් එයට හේතුව සොයා ගැනීමට අපහසුය, ඒ වන විටත් ඔබට සැබෑ තැටි දෝෂ ඇති විය හැක. තත්වය වළාකුළු. (මෙම ගැටළුව ගොනු පද්ධතිවල ප්‍රමාණය අඩු කිරීමට පමණක් බලපායි - කෙසේ වෙතත්, ගොනු පද්ධති දෙපැත්තටම ප්‍රතිප්‍රමාණනය කිරීම දත්ත නැතිවීමේ අවදානම වැඩි කරන බව පැහැදිලිය. පරිශීලක දෝෂයක් නිසා විය හැක.)

• LV ප්‍රමාණය FS ප්‍රමාණයට වඩා 2 x LVM භෞතික ප්‍රමාණය (PE) ප්‍රමාණයෙන් විශාල විය යුතු බව පෙනේ - නමුත් මේ සඳහා ප්‍රභවය බලයලත් නොවන බැවින් විස්තර සඳහා ඉහත සබැඳිය පරීක්ෂා කරන්න. බොහෝ විට 8 MiB ට ඉඩ දීම ප්‍රමාණවත්ය, නමුත් වැඩිපුර ඉඩ දීම වඩා හොඳ විය හැකිය, උදා: 100 MiB හෝ 1 GiB, ආරක්ෂිතව සිටීමට. 4 KiB = 4096 බයිට් කුට්ටි භාවිතා කරමින් PE ප්‍රමාණය සහ ඔබේ තාර්කික පරිමාව + FS ප්‍රමාණ පරීක්ෂා කිරීමට:

  KiB හි PE ප්‍රමාණය පෙන්වයි:
  vgdisplay --units k myVGname | grep "PE Size"
  
  සියලුම LV වල ප්‍රමාණය :
  lvs --units 4096b
  
  (ext3) FS ප්‍රමාණය, 4 KiB FS අවහිර කිරීම් උපකල්පනය කරයි:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• ඊට වෙනස්ව, එල්වීඑම් නොවන සැකසුම මඟින් එෆ්එස් ප්‍රමාණය වෙනස් කිරීම ඉතා විශ්වාසදායක සහ පහසු කරයි - ජීපාර්ට් ධාවනය කර අවශ්‍ය එෆ්එස් ප්‍රමාණය වෙනස් කරන්න, එවිට එය ඔබ වෙනුවෙන් සියල්ල කරනු ඇත. සේවාදායකයන් මත, ඔබට කවචයෙන් භාවිතා කළ හැකිය parted.

  • ඩිස්ට්‍රෝ අනුවාදයට වඩා මෑතදී හා බොහෝ විට දෝෂ රහිත Gparted & කර්නලයක් ඇති බැවින් Gparted Live CD හෝ Parted Magic භාවිතා කිරීම වඩාත් සුදුසුය - ඩිස්ට්‍රෝ හි Gparted කොටස් නිසි ලෙස යාවත්කාලීන නොකිරීම නිසා මට වරක් මුළු FS එකක්ම අහිමි විය. කර්නලය. ඩිස්ට්‍රෝ හි Gparted භාවිතා කරන්නේ නම්, කොටස් වෙනස් කිරීමෙන් පසු නැවත ආරම්භ කිරීමට වග බලා ගන්න එවිට කර්නලයේ දැක්ම නිවැරදි වේ.

ස්නැප්ෂොට් භාවිතා කිරීම අසීරු, මන්දගාමී සහ දෝෂ සහිතයි - කලින් වෙන් කළ ඉඩ ප්‍රමාණයෙන් ස්නැප්ෂොට් ඉවතට ගියහොත් එය ස්වයංක්‍රීයව පහත වැටේ . ලබා දී ඇති LV හි සෑම ස්නැප්ෂොට් එකක්ම එම LV ට එරෙහි ඩෙල්ටාවකි (පෙර ස්නැප්ෂොට් වලට එරෙහිව නොවේ) සැලකිය යුතු ලිවීමේ ක්‍රියාකාරකම් සහිත ගොනු පද්ධති ස්නැප්ෂොට් කිරීමේදී විශාල ඉඩක් අවශ්‍ය වේ (සෑම ස්නැප්ෂොට් එකක්ම පෙරට වඩා විශාල වේ). මුල් එල්.වී.ට සමාන ප්‍රමාණයේ ස්නැප්ෂොට් එල්.වී එකක් සෑදීම ආරක්ෂිතයි, මන්ද ස්නැප්ෂොට් එක කිසි විටෙකත් නිදහස් ඉඩෙන් ඉවතට නොයනු ඇත.

ස්නැප්ෂොට් ද ඉතා මන්දගාමී විය හැකිය ( මෙම MySQL පරීක්ෂණ සඳහා LVM නොමැතිව 3 සිට 6 ගුණයක් මන්දගාමී වේ ) - විවිධ ස්නැප්ෂොට් ගැටළු ආවරණය වන මෙම පිළිතුර බලන්න . මන්දගාමී වීමට එක් හේතුවක් වන්නේ ස්නැප්ෂොට් වලට බොහෝ සමමුහුර්ත ලිවීම් අවශ්‍ය වන බැවිනි .

ස්නැප්ෂොට් වල සැලකිය යුතු දෝෂ කිහිපයක් තිබේ, උදා: සමහර අවස්ථාවලදී ඒවා ඇරඹුම ඉතා මන්දගාමී කළ හැකිය, නැතහොත් ඇරඹුම සම්පූර්ණයෙන්ම අසාර්ථක වීමට හේතු වේ (මක්නිසාද යත් කර්නලය එල්වීඑම් ස්නැප්ෂොට් එකක් වන විට එෆ්එස් මූලය එනතෙක් බලා සිටිය හැකි බැවිනි [ඩෙබියන් initramfs-toolsයාවත්කාලීනයේදී ස්ථාවර කර ඇත , මාර්තු 2015]. ).

• කෙසේ වෙතත්, බොහෝ ස්නැප්ෂොට් ධාවන තත්ව දෝෂ 2015 වන විට නිවැරදි කර ඇත.
• ස්නැප්ෂොට් නොමැතිව LVM සාමාන්‍යයෙන් හොඳින් නිදොස් කර ඇති බවක් පෙනේ, සමහර විට මූලික ලක්ෂණ තරම් ස්නැප්ෂොට් භාවිතා නොකෙරේ.

Snapshot විකල්ප - ගොනු පද්ධති සහ VM හයිපර්වයිසර්

වීඑම් / වලාකුළු ඡායාරූප:

• ඔබ VM හයිපර්වයිසර් හෝ IaaS වලාකුළු සැපයුම්කරුවෙකු භාවිතා කරන්නේ නම් (උදා: VMware, VirtualBox හෝ Amazon EC2 / EBS), ඔවුන්ගේ ස්නැප්ෂොට් බොහෝ විට LVM ස්නැප්ෂොට් වලට වඩා හොඳ විකල්පයකි. උපස්ථ අරමුණු සඳහා ඔබට පහසුවෙන් ඡායාරූපයක් ගත හැකිය (නමුත් ඔබ එසේ කිරීමට පෙර එෆ්එස් කැටි කිරීම සලකා බලන්න).

ගොනු පද්ධති ස්නැප්ෂොට්:

• ඔබ හිස් ලෝහයක නම් ZFS හෝ btrfs සහිත ගොනු පද්ධති ස්නැප්ෂොට් භාවිතා කිරීමට පහසු වන අතර සාමාන්‍යයෙන් LVM වලට වඩා හොඳය (නමුත් ZFS වඩා පරිණත බවක් පෙනේ, ස්ථාපනය කිරීමට වඩා කරදරයක් වේ):

  • ZFS: දැන් කර්නල් ZFS ක්‍රියාත්මක කිරීමක් පවතින අතර එය වසර ගණනාවක් තිස්සේ භාවිතයේ පවතින අතර ZFS දරුකමට හදා ගැනීමක් ලෙස පෙනේ. 19.10 දී මූලයේ පර්යේෂණාත්මක ZFS ද ඇතුළුව උබුන්ටු දැන් ZFS 'පිටත කොටසේ' විකල්පයක් ලෙස ඇත .
  • btrfs: නිෂ්පාදන භාවිතය සඳහා තවමත් සුදානම් නැත ( පෙරනිමියෙන් එය නැව්ගත කරන සහ btrf සඳහා කණ්ඩායම කැපවී ඇති openSUSE හි පවා ), RHEL එයට සහාය දීම නවතා දමා ඇත). btrfs සතුව දැන් fsck මෙවලමක් (FAQ) ඇත , නමුත් නිතර අසන පැන ඔබට නිර්දේශ කරන්නේ ඔබට බිඳුණු ගොනු පද්ධතියක් fsck කිරීමට අවශ්‍ය නම් සංවර්ධකයෙකුගෙන් උපදෙස් ලබා ගන්නා ලෙසයි.

සබැඳි උපස්ථ සහ fsck සඳහා ස්නැප්ෂොට්

ඔබ අවකාශය වෙන් කිරීම ගැන සැලකිලිමත් වන තාක් කල්, උපස්ථ සඳහා ස්ථාවර ප්‍රභවයක් සැපයීමට ස්නැප්ෂොට් භාවිතා කළ හැකිය (ඉතා මැනවින් ස්නැප්ෂොට් එක LV උපස්ථයට සමාන ප්‍රමාණයකි). විශිෂ්ට rsnapshot (1.3.1 සිට) ඔබ වෙනුවෙන් LVM ස්නැප්ෂොට් නිර්මාණය / මකාදැමීම පවා කළමනාකරණය කරයි - LVM භාවිතා කරමින් rsnapshot හි මෙම HOWTO බලන්න . කෙසේ වෙතත්, ස්නැප්ෂොට් සමඟ ඇති පොදු ගැටළු සහ ස්නැප්ෂොට් එකක් උපස්ථයක් ලෙස නොසැලකිය යුතුය.

තවමත් ප්රධාන-සැණරුව නොවන FS භාවිතා කරන අතරතුර, සැණරුව තරගවලින් සහ සැණරුව fsck: - ඔබ ද LVM ඔන්ලයින් fsck කරන්න snapshots භාවිතා කළ හැකි මෙහි විස්තර - කෙසේ වෙතත්, ඒක සම්පූර්ණයෙන්ම සරල නොවේ එය භාවිතා කිරීමට හොඳම එසේ e2croncheck ලෙස ටෙඩ් මහතා විසින් විස්තර කර 'o , ext3 හි පාලකයා.

ස්නැප්ෂොට් ලබා ගැනීමේදී ඔබ තාවකාලිකව ගොනු පද්ධතිය "කැටි කළ යුතුය " - එල්වීඑම් විසින් ස්නැප්ෂොට් නිර්මාණය කරන විට ext3 සහ XFS වැනි සමහර ගොනු පද්ධති ස්වයංක්‍රීයව මෙය සිදු කරයි.

නිගමන

මේ සියල්ල තිබියදීත්, මම තවමත් සමහර පද්ධති වල LVM භාවිතා කරමි, නමුත් ඩෙස්ක්ටොප් සැකසුම සඳහා මම අමු කොටස් වලට කැමැත්තෙමි. LVM වෙතින් මට දැකිය හැකි ප්‍රධාන වාසිය නම් ඔබට සේවාදායකයක ඉහළ වේලාවක් තිබිය යුතු විට එෆ්එස් චලනය කිරීමට හා ප්‍රමාණය වෙනස් කිරීමට නම්යශීලී වීමයි - ඔබට එය අවශ්‍ය නොවන්නේ නම්, gparted පහසු වන අතර දත්ත නැතිවීමේ අවදානම අඩුය.

වීඑම් හයිපර්වයිසර්, දෘ hard තැටිය / එස්එස්ඩී ලිවීමේ හැඹිලි යනාදිය නිසා ලිඛිත හැඹිලි සැකසුම පිළිබඳව එල්වීඑම් හට විශාල සැලකිල්ලක් අවශ්‍ය වේ - නමුත් ලිනක්ස් ඩීබී සේවාදායකයක් ලෙස භාවිතා කිරීම සඳහා ද එය අදාළ වේ. බොහෝ මෙවලම් වලින් ( gpartedවිවේචනාත්මක ප්‍රමාණ ගණනය කිරීම් සහ testdiskයනාදිය) සහාය නොලැබීම එය තිබිය යුතු ප්‍රමාණයට වඩා භාවිතා කිරීම දුෂ්කර කරයි.

LVM භාවිතා කරන්නේ නම්, ස්නැප්ෂොට් සමඟ විශාල සැලකිල්ලක් දක්වන්න: හැකි නම් VM / cloud ස්නැප්ෂොට් භාවිතා කරන්න, නැතහොත් LVM සම්පූර්ණයෙන්ම වළක්වා ගැනීම සඳහා ZFS / btrfs විමර්ශනය කරන්න - ස්නැප්ෂොට් සමඟ LVM හා සසඳන විට ZFS හෝ btrs ප්‍රමාණවත් තරම් පරිණත බව ඔබට පෙනී යනු ඇත.

නිගමනය: ඉහත ලැයිස්තුගත කර ඇති ගැටළු සහ ඒවා විසඳන්නේ කෙසේද යන්න පිළිබඳව ඔබ නොදන්නේ නම්, LVM භාවිතා නොකිරීම වඩාත් සුදුසුය.

මම එම තනතුර [+1] වන අතර, අවම වශයෙන් මට නම් බොහෝ ගැටලු පවතින බව මම සිතමි. සේවාදායකයන් 100 ක් සහ 100TB දත්ත කිහිපයක් ධාවනය කරන අතරතුර ඒවා දැක ඇත. මට නම් ලිනක්ස් හි LVM2 යමෙකු දැන සිටි “දක්ෂ අදහසක්” මෙන් දැනේ. මේවායින් සමහරක් මෙන්, ඔවුන් විටින් විට "දක්ෂ නොවේ" බවට පත්වේ. දැඩි ලෙස වෙන් කරන ලද කර්නලය සහ පරිශීලක අවකාශය (lvmtab) නොමැති වීම දූෂණය පිළිබඳ ගැටළු ඇති විය හැකි නිසා (ඔබට කේතය නිවැරදිව නොලැබුනේ නම්) ඉවත් කිරීමට ඇත්තෙන්ම බුද්ධිමත් යැයි හැඟෙන්නට ඇත.

හොඳයි, මෙම වෙන්වීම හේතුවක් නිසා පමණක් විය හැකිය - පීවී පාඩු හැසිරවීම සමඟ වෙනස්කම් පෙන්නුම් කරයි, සහ වී.වී යක් නැවත සක්‍රිය කිරීම සඳහා නැතිවූ පීවී සමඟ සබැඳිව නැවත සක්‍රිය කිරීම - “මුල් එල්වීඑම්” (AIX) හි සුළඟ යනු කුමක්ද? , HP-UX) LVM2 හි කපටි බවට හැරෙන්නේ රාජ්‍ය හැසිරවීම ප්‍රමාණවත් නොවන බැවිනි. (මම ද පැමින ලෙස සලකුණු කළ නොහැකි බව තැටි, ඉවත් කරන්න නම්. එය පවා නැත පවා මට ගණපූරණය අහිමි හඳුනා (හාහා) හෝ රාජ්ය කටයුතු කළ යුතු ආකාරය ගැන කතා ගන්න එපා ඇති මෙම යානාව විපතට පත්වීම තත්ව තීරුව)

Re: ස්ථාවරත්වය pvmove ... ඇයි

pvmove දත්ත නැතිවීම

මගේ බ්ලොග් අඩවියේ එවැනි ඉහළ පෙළේ ලිපියක්, හ්ම්? දැන් මම තැටියක් දෙස බලන්නේ ෆයිස්කල් එල්වීඑම් දත්ත තවමත් පීවීඑම්ඕව් මැද සිට රාජ්‍යය මත එල්ලා ඇති බැවිනි. මා සිතන සමහර මතක සටහන් ඇති අතර, පරිශීලක අවකාශයෙන් සජීවී බ්ලොක් දත්ත පිටපත් කිරීම හොඳ දෙයක් යන සාමාන්‍ය අදහස කනගාටුවට කරුණකි. Lvm ලැයිස්තුවෙන් හොඳ උපුටා දැක්වීමක් "vgreduce --missing pvmove හසුරුවන්නේ නැති බව පෙනේ" ඇත්ත වශයෙන්ම අදහස් කරන්නේ pvmove අතරතුර තැටියක් අනාවරණය වුවහොත් lvm කළමනාකරණ මෙවලම lvm සිට vi දක්වා වෙනස් වන බවයි. කියවීමේ / ලිවීමේ දෝෂයකින් පසුව pvmove දිගටම පවතින අතර ඇත්ත වශයෙන්ම ඉලක්කගත උපාංගයට දත්ත ලිවීම සිදු නොවන දෝෂයකි. WTF?

Re: Snapshots නව දත්ත Snapshot lv ප්‍රදේශයට යාවත්කාලීන කිරීමෙන් සහ ඔබ සැණෙළිය මකා දැමූ පසු නැවත ඒකාබද්ධ කිරීමෙන් CoW අනාරක්ෂිතව සිදු කරයි. මෙයින් අදහස් කරන්නේ නව දත්ත අවසාන LV සමඟ ඒකාබද්ධ කිරීමේදී ඔබට අධික IO ස්පයික් ඇති අතර, වඩා වැදගත් දෙය නම්, ඇත්ත වශයෙන්ම ඔබට දත්ත දූෂණය වීමේ වැඩි අවදානමක් ඇති බවය, මන්ද ඔබ පහර දුන් පසු සැණෙළිය කැඩී නොයනු ඇත. බිත්තිය, නමුත් මුල් පිටපත.

කාර්ය සාධනයෙහි වාසිය වන්නේ 3 වෙනුවට 1 ලිවීමයි. වේගවත් නමුත් අනාරක්ෂිත ඇල්ගොරිතම තෝරා ගැනීම VMware සහ MS වැනි අයගෙන් පැහැදිලිවම අපේක්ෂා කරන දෙයක් වන අතර, “යුනික්ස්” හි “දේවල් නිවැරදිව සිදු වේවි” යැයි මම සිතමි. ප්‍රාථමික දත්ත වලට වඩා වෙනස් තැටි ධාවකයක ස්නැප්ෂොට් පසුබිම් ගබඩාවක් ඇති තාක් කල් මම බොහෝ කාර්ය සාධන ගැටළු දුටුවේ නැත (සහ තවත් එකකට උපස්ථ කිරීම)

Re: බාධක LVM මත යමෙකුට දොස් පැවරිය හැකිදැයි මට විශ්වාස නැත. මා දන්නා තරමින් එය ඩෙව්මැපර් ප්‍රශ්නයක් විය. නමුත් අවම වශයෙන් කර්නලය 2.6 සිට 2.6.33 දක්වා මෙම ගැටළුව ගැන සැබවින්ම සැලකිලිමත් නොවීම සම්බන්ධයෙන් යම් දෝෂාරෝපණයක් තිබිය හැකිය. අථත්‍ය යන්ත්‍ර සඳහා O_DIRECT භාවිතා කරන එකම හයිපර්වයිසර් AFAIK Xen වේ, කර්නලය නිසා “ලූප්” භාවිතා කරන විට ඇති වූ ගැටළුව එය තවමත් භාවිතා කරයි. අතථ්‍ය පෙට්ටියට අවම වශයෙන් මේ වගේ දේවල් අක්‍රීය කිරීමට යම් සැකසුමක් ඇති අතර Qemu / KVM සාමාන්‍යයෙන් හැඹිලිගත කිරීමට ඉඩ දෙන බව පෙනේ. සියලුම FUSE FS හි ද එහි ගැටළු ඇත (O_DIRECT නැත)

Re: ප්‍රමාණයන් මම හිතන්නේ LVM මඟින් පෙන්වන ප්‍රමාණයෙන් “වටකුරු” කරයි. නැතහොත් එය GiB භාවිතා කරයි. කෙසේ වෙතත්, ඔබට VG Pe ප්‍රමාණය භාවිතා කළ යුතු අතර එය LV හි LE අංකය මගින් ගුණ කරන්න. එය නිවැරදි ශුද්ධ ප්‍රමාණය ලබා දිය යුතු අතර, එම ගැටළුව සැමවිටම භාවිත ගැටළුවක් වේ. Fsck / mount (හෙලෝ, ext3) අතරතුර එවැනි දෙයක් නොදකින හෝ වැඩ කරන මාර්ගගත "fsck -n" (හෙලෝ, ext3) නොමැති ගොනු පද්ධති විසින් එය වඩාත් නරක අතට හැරේ.

ඇත්ත වශයෙන්ම එය පවසන්නේ එවැනි තොරතුරු සඳහා ඔබට හොඳ ප්‍රභවයන් සොයාගත නොහැකි බවයි. "VRA සඳහා LE කීයක් තිබේද?" "පීවීආර්ඒ, වීජීඩීඒ, ... ආදිය සඳහා ෆයිස්කල් ඕෆ්සෙට් යනු කුමක්ද?"

මුල්ම LVM2 හා සසඳන විට "යුනික්ස් නොතේරෙන අය එය යථා තත්වයට පත් කිරීම හෙළා දකී."

මාස කිහිපයකට පසු යාවත්කාලීන කරන්න: මම මේ වන විට පරීක්ෂණයක් සඳහා "සම්පූර්ණ සැණෙළිය" දර්ශනයට පහර දෙමි. ඒවා සම්පුර්ණ වුවහොත්, සැණෙළිය අවහිර වේ, මුල් LV නොවේ. මම මෙය පළ කළ විට එහි වැරදිය. මම යම් ලේඛනයකින් වැරදි තොරතුරු ලබා ගත්තා, නැතහොත් සමහර විට මම එය තේරුම් ගෙන ඇති. මගේ සැකසීම් වලදී මම ඒවා නිතරම පුරවා නොගෙන ඒවා පුරවන්නට ඉඩ නොදෙමි. එබැවින් මම කිසි විටෙකත් නිවැරදි නොකළෙමි. සංග්‍රහයක් වන ස්නැප්ෂොට් දිගු කිරීම / හැකිලීම ද කළ හැකිය.

මට තවමත් විසඳීමට නොහැකි වී ඇත්තේ ස්නැප්ෂොට්ගේ වයස හඳුනා ගන්නේ කෙසේද යන්නයි. ඔවුන්ගේ ක්‍රියාකාරිත්වය සම්බන්ධයෙන් ගත් කල, “සිහින්” ෆෙඩෝරා ව්‍යාපෘති පිටුවේ සටහනක් ඇත, එහි සඳහන් වන්නේ එක් එක් සැණින් ඡායාරූපය සමඟ මන්දගාමී නොවන පරිදි ස්නැප්ෂොට් තාක්‍ෂණය සංශෝධනය කරන බවයි. මම දන්නේ නැහැ ඔවුන් එය ක්‍රියාත්මක කරන්නේ කෙසේද කියා.

ඔබ උපස්ථ සඳහා ස්නැප්ෂොට් භාවිතා කිරීමට අදහස් කරන්නේ නම් - ස්නැප්ෂොට් ඇති විට ප්‍රධාන කාර්ය සාධනය සඳහා සූදානම්ව සිටින්න. වැඩි විස්තර මෙතැනින් කියවන්න . නැතිනම් ඒ සියල්ල හොඳයි. මම වසර කිහිපයක් තිස්සේ සේවාදායකයන් දුසිම් ගණනක් තිස්සේ lvm නිෂ්පාදනය කර ඇත, නමුත් එය භාවිතා කිරීමට මගේ ප්‍රධාන හේතුව පරමාණුක ස්නැප්ෂොට් නිසා පහසුවෙන් පරිමාව පුළුල් කිරීමට නොහැකි වීමයි.

btw ඔබ 1TB ධාවකය භාවිතා කිරීමට යන්නේ නම්, කොටස් පෙළගැස්ම ගැන මතක තබා ගන්න - මෙම ධාවකය බොහෝ විට 4kB භෞතික අංශ ඇත.

ආදම්,

තවත් වාසියක්: ඔබට නව භෞතික පරිමාවක් (පීවී) එක් කළ හැකිය, සියලු දත්ත එම පීවී වෙත ගෙන ගොස් සේවා බාධාවකින් තොරව පැරණි පීවී ඉවත් කරන්න. මම පසුගිය අවුරුදු පහ තුළ අවම වශයෙන් හතර වතාවක් එම හැකියාව භාවිතා කර ඇත්තෙමි.

මා තවමත් නොදකින අවාසියක් පැහැදිලිව පෙන්වා දී ඇත: LVM2 සඳහා තරමක් තද ඉගෙනුම් වක්‍රයක් ඇත. බොහෝ විට වියුක්තයේදී එය ඔබගේ ලිපිගොනු සහ යටින් පවතින මාධ්‍ය අතර නිර්මාණය වේ. ඔබ සේවාදායක කට්ටලයක වැඩ බෙදාගන්නා පුද්ගලයන් කිහිප දෙනෙකු සමඟ වැඩ කරන්නේ නම්, සමස්තයක් වශයෙන් ඔබේ කණ්ඩායමට අතිරික්ත සංකීර්ණ බවක් ඔබට පෙනෙනු ඇත. තොරතුරු තාක්ෂණ කටයුතු සඳහා කැපවී සිටින විශාල කණ්ඩායම්වලට සාමාන්‍යයෙන් එවැනි ගැටළුවක් ඇති නොවේ.

නිදසුනක් ලෙස, අපි එය මගේ කාර්යයේදී මෙහි බහුලව භාවිතා කරන අතර නිවැරදිව ආරම්භ නොවන පද්ධති නැවත ලබා ගැනීම පිළිබඳ මූලික කරුණු, භාෂාව සහ අත්‍යවශ්‍ය දෑ සමස්ත කණ්ඩායමට ඉගැන්වීමට කාලය ගෙන ඇත.

විශේෂයෙන් පෙන්වා දීමට එක් අවවාදයක්: ඔබ LVM2 තාර්කික පරිමාවෙන් ආරම්භ කරන්නේ නම්, සේවාදායකය බිඳ වැටෙන විට ප්‍රතිසාධන මෙහෙයුම් දුෂ්කර බව ඔබ සොයා ගත්තේය. Knoppix සහ මිතුරන් සෑම විටම ඒ සඳහා නිවැරදි දේවල් නොමැත. එබැවින්, අපගේ / ඇරඹුම් නාමාවලිය තමන්ගේම කොටසක තිබිය යුතු අතර සෑම විටම කුඩා හා ස්වදේශීය වනු ඇතැයි අපි තීරණය කළෙමු.

සමස්තයක් වශයෙන්, මම LVM2 හි රසිකයෙක්මි.

දේවල් කිහිපයක්:

බහු පීවී හරහා LV විහිදේ

මම දීර්ඝ වෙනුවෙන් පෙනී (StackExchange සහ වෙනත් තැන්වල) ජනයා දැකලා තියෙනවා VM එකතු කිරීම මඟින් වැඩි ඉඩක්: පාර්ශ්චිකව අවකාශය අතිරේක වූ වැඩි එදිරිව වූ VG කිරීමට PVs තනි පීවී. එය කැත වන අතර ඔබේ ගොනු පද්ධතිය (පීවී) බහු පීවී හරහා පැතිරෙන අතර, එය සදාකාලික හා දිගු පීවී දාමයක් මත යැපීමක් නිර්මාණය කරයි. ඔබ ඔබේ වීඑම් ගබඩාව පාර්ශ්වීයව පරිමාණය කළහොත් ඔබේ ගොනු පද්ධති පෙනෙන්නේ මෙයයි:

පීවී එකක ධාරක ධාරිතාව අහිමි වුවහොත් දත්ත නැතිවීම

මම මේ ගැන බොහෝ ව්‍යාකූලතා දැක ඇත්තෙමි. රේඛීය LV- සහ එහි වාසය කරන ගොනු පද්ධතිය - බහු PV හරහා විහිදේ නම්, සම්පූර්ණ හෝ අර්ධ දත්ත අලාභයක් අත්විඳිය හැකිද? මෙන්න නිදර්ශනය:

තර්කානුකූලව, අප අපේක්ෂා කළ යුත්තේ මෙයයි. අපගේ LV දත්ත රඳවා තබා ඇති ප්‍රමාණය බහු PV හරහා පැතිරී ඇති අතර එම PV වලින් එකක් අතුරුදහන් වුවහොත්, එම LV හි ගොනු පද්ධතිය විනාශකාරී ලෙස හානි වනු ඇත.

මෙම කුඩා ඩූඩල් LVM සමඟ වැඩ කිරීමේදී අවදානම් තේරුම් ගැනීමට සංකීර්ණ විෂයයක් ටිකක් පහසු කර ඇතැයි සිතමු