LVM మరియు Matryoshka మధ్య ఉమ్మడిగా ఏమి ఉంది?

మంచి రోజు.
md RAID + LVMని ఉపయోగించి KVM కోసం డేటా స్టోరేజ్ సిస్టమ్‌ను రూపొందించడంలో నా ఆచరణాత్మక అనుభవాన్ని నేను సంఘంతో పంచుకోవాలనుకుంటున్నాను.

కార్యక్రమంలో ఇవి ఉంటాయి:

• NVMe SSD నుండి md RAID 1ని నిర్మిస్తోంది.
• SATA SSD మరియు సాధారణ డ్రైవ్‌ల నుండి md RAID 6ని అసెంబ్లింగ్ చేస్తోంది.
• SSD RAID 1/6లో TRIM/DISCARD ఆపరేషన్ యొక్క లక్షణాలు.
• సాధారణ డిస్క్‌ల సెట్‌లో బూటబుల్ md RAID 1/6 శ్రేణిని సృష్టిస్తోంది.
• BIOSలో NVMe మద్దతు లేనప్పుడు NVMe RAID 1లో సిస్టమ్‌ను ఇన్‌స్టాల్ చేస్తోంది.
• LVM కాష్ మరియు LVM థిన్‌ని ఉపయోగించడం.
• BTRFS స్నాప్‌షాట్‌లను ఉపయోగించడం మరియు బ్యాకప్ కోసం పంపడం/స్వీకరించడం.
• BTRFS స్టైల్ బ్యాకప్‌ల కోసం LVM థిన్ స్నాప్‌షాట్‌లు మరియు థిన్_డెల్టాను ఉపయోగించడం.

మీకు ఆసక్తి ఉంటే, దయచేసి పిల్లిని చూడండి.

అప్లికేషన్ రూపం

ఈ కథనం నుండి పదార్థాలు/ఉదాహరణలు/కోడ్/చిట్కాలు/డేటాను ఉపయోగించడం లేదా ఉపయోగించకపోవడం వల్ల కలిగే పరిణామాలకు రచయిత ఎలాంటి బాధ్యత వహించడు. ఈ విషయాన్ని ఏ విధంగానైనా చదవడం లేదా ఉపయోగించడం ద్వారా, ఈ చర్యల యొక్క అన్ని పరిణామాలకు మీరు బాధ్యత వహిస్తారు. సాధ్యమయ్యే పరిణామాలు:

• క్రిస్ప్-ఫ్రైడ్ NVMe SSDలు.
• రికార్డింగ్ వనరు మరియు SSD డ్రైవ్‌ల వైఫల్యం పూర్తిగా ఉపయోగించబడింది.
• బ్యాకప్ కాపీలతో సహా అన్ని డ్రైవ్‌లలోని మొత్తం డేటాను పూర్తిగా కోల్పోవడం.
• తప్పు కంప్యూటర్ హార్డ్‌వేర్.
• సమయం, నరాలు మరియు డబ్బు వృధా.
• పైన జాబితా చేయని ఏవైనా ఇతర పరిణామాలు.

ఇనుము

అందుబాటులో ఉండేవి:

దాదాపు 2013 నుండి Z87 చిప్‌సెట్‌తో మదర్‌బోర్డ్, ఇంటెల్ కోర్ i7 / హాస్‌వెల్‌తో పూర్తి చేయబడింది.

• ప్రాసెసర్ 4 కోర్లు, 8 థ్రెడ్లు
• 32 GB DDR3 ర్యామ్
• 1 x 16 లేదా 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps SATA 3 కనెక్టర్లు

SAS అడాప్టర్ LSI SAS9211-8I IT / HBA మోడ్‌కు ఫ్లాష్ చేయబడింది. RAID-ప్రారంభించబడిన ఫర్మ్‌వేర్ ఉద్దేశపూర్వకంగా HBA ఫర్మ్‌వేర్‌తో భర్తీ చేయబడింది:

1. మీరు ఎప్పుడైనా ఈ అడాప్టర్‌ని విసిరివేయవచ్చు మరియు మీరు చూసిన మరేదైనా దాన్ని భర్తీ చేయవచ్చు.
2. TRIM/డిస్కార్డ్ సాధారణంగా డిస్క్‌లలో పని చేస్తుంది, ఎందుకంటే... RAID ఫర్మ్‌వేర్‌లో ఈ కమాండ్‌లకు అస్సలు మద్దతు లేదు మరియు HBA, సాధారణంగా, బస్సు ద్వారా ఏ ఆదేశాలు ప్రసారం చేయబడుతుందో పట్టించుకోదు.

హార్డ్ డ్రైవ్‌లు - ల్యాప్‌టాప్‌ల కోసం 8 ఫారమ్ ఫ్యాక్టర్‌లో 7 TB సామర్థ్యంతో HGST ట్రావెల్‌స్టార్ 1000K1 యొక్క 2.5 ముక్కలు. ఈ డ్రైవ్‌లు గతంలో RAID 6 శ్రేణిలో ఉండేవి. కొత్త వ్యవస్థలో వాటి ఉపయోగం కూడా ఉంటుంది. స్థానిక బ్యాకప్‌లను నిల్వ చేయడానికి.

అదనంగా జోడించబడింది:

6 ముక్కలు SATA SSD మోడల్ Samsung 860 QVO 2TB. ఈ SSDలకు పెద్ద వాల్యూమ్ అవసరం, SLC కాష్ ఉనికి, విశ్వసనీయత మరియు తక్కువ ధర అవసరం. డిస్కార్డ్/సున్నాకి మద్దతు అవసరం, ఇది dmesgలోని లైన్ ద్వారా తనిఖీ చేయబడుతుంది:

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD మోడల్ Samsung SSD 2 EVO 970GB యొక్క 500 ముక్కలు.

ఈ SSDల కోసం, యాదృచ్ఛికంగా చదవడం/వ్రాయడం వేగం మరియు మీ అవసరాలకు వనరుల సామర్థ్యం ముఖ్యమైనవి. వారికి రేడియేటర్. తప్పనిసరిగా. ఖచ్చితంగా. లేకపోతే, మొదటి RAID సమకాలీకరణ సమయంలో వాటిని క్రిస్పీగా వేయించాలి.

8 x NVMe SSD కోసం StarTech PEX2M2E2 అడాప్టర్ PCIe 3.0 8x స్లాట్‌లో ఇన్‌స్టాల్ చేయబడింది. ఇది మళ్ళీ, కేవలం HBA మాత్రమే, కానీ NVMe కోసం. అంతర్నిర్మిత PCIe స్విచ్ ఉన్నందున మదర్‌బోర్డు నుండి PCIe విభజన మద్దతు అవసరం లేని చౌక అడాప్టర్‌ల నుండి ఇది భిన్నంగా ఉంటుంది. ఇది x1 PCIe 1.0 స్లాట్ అయినప్పటికీ, PCIeతో అత్యంత పురాతన సిస్టమ్‌లో కూడా పని చేస్తుంది. సహజంగా, తగిన వేగంతో. అక్కడ RAIDలు లేవు. బోర్డులో అంతర్నిర్మిత BIOS లేదు. కాబట్టి, మీ సిస్టమ్ అద్భుతంగా NVMeతో బూట్ చేయడం నేర్చుకోదు, ఈ పరికరానికి NVMe RAID ధన్యవాదాలు.

ఈ భాగం సిస్టమ్‌లో కేవలం ఒక ఉచిత 8x PCIe 3.0 మాత్రమే ఉండటం వల్ల ఏర్పడింది మరియు 2 ఉచిత స్లాట్‌లు ఉంటే, దానిని రెండు పెన్నీ PEX4M2E1 లేదా అనలాగ్‌లతో సులభంగా భర్తీ చేయవచ్చు, వీటిని ఎక్కడైనా 600 ధరకు కొనుగోలు చేయవచ్చు. రూబిళ్లు.

అన్ని రకాల హార్డ్‌వేర్ లేదా అంతర్నిర్మిత చిప్‌సెట్/BIOS RAIDల తిరస్కరణ ఉద్దేశపూర్వకంగానే, మొత్తం సిస్టమ్‌ను పూర్తిగా భర్తీ చేయగలగాలి, SSD/HDDని మినహాయించి, మొత్తం డేటాను భద్రపరుస్తుంది. ఆదర్శవంతంగా, మీరు పూర్తిగా కొత్త/వేర్వేరు హార్డ్‌వేర్‌కు వెళ్లేటప్పుడు ఇన్‌స్టాల్ చేయబడిన ఆపరేటింగ్ సిస్టమ్‌ను కూడా సేవ్ చేయవచ్చు. ప్రధాన విషయం ఏమిటంటే SATA మరియు PCIe పోర్ట్‌లు ఉన్నాయి. ఇది లైవ్ CD లేదా బూటబుల్ ఫ్లాష్ డ్రైవ్ లాంటిది, చాలా వేగంగా మరియు కొంచెం స్థూలంగా మాత్రమే ఉంటుంది.

హాస్యంలేకపోతే, ఏమి జరుగుతుందో మీకు తెలుసు - కొన్నిసార్లు మీరు తీసివేయడానికి మొత్తం శ్రేణిని మీతో అత్యవసరంగా తీసుకెళ్లాలి. కానీ నేను డేటాను కోల్పోవడం ఇష్టం లేదు. దీన్ని చేయడానికి, పేర్కొన్న అన్ని మీడియాలు ప్రామాణిక కేసు యొక్క 5.25 బేలలోని స్లయిడ్‌లలో సౌకర్యవంతంగా ఉంటాయి.

బాగా, మరియు, వాస్తవానికి, Linuxలో SSD కాషింగ్ యొక్క వివిధ పద్ధతులతో ప్రయోగాలు చేయడం కోసం.

హార్డ్‌వేర్ దాడులు బోరింగ్‌గా ఉన్నాయి. దాన్ని ఆన్ చేయండి. ఇది పనిచేస్తుంది లేదా పని చేయదు. మరియు mdadm తో ఎల్లప్పుడూ ఎంపికలు ఉన్నాయి.

సాఫ్ట్

ఇంతకుముందు, డెబియన్ 8 జెస్సీ హార్డ్‌వేర్‌లో ఇన్‌స్టాల్ చేయబడింది, ఇది EOLకి దగ్గరగా ఉంటుంది. RAID 6 పైన పేర్కొన్న HDDల నుండి LVMతో జత చేయబడింది. ఇది kvm/libvirtలో వర్చువల్ మిషన్లను రన్ చేసింది.

ఎందుకంటే పోర్టబుల్ బూటబుల్ SATA/NVMe ఫ్లాష్ డ్రైవ్‌లను రూపొందించడంలో రచయితకు తగిన అనుభవం ఉంది మరియు సాధారణ సముచితమైన టెంప్లేట్‌ను విచ్ఛిన్నం చేయకుండా ఉండటానికి, ఉబుంటు 18.04 లక్ష్య వ్యవస్థగా ఎంపిక చేయబడింది, ఇది ఇప్పటికే తగినంతగా స్థిరీకరించబడింది, కానీ ఇప్పటికీ 3 సంవత్సరాలు ఉంది. భవిష్యత్తులో మద్దతు.

పేర్కొన్న సిస్టమ్ బాక్స్ వెలుపల మనకు అవసరమైన అన్ని హార్డ్‌వేర్ డ్రైవర్‌లను కలిగి ఉంది. మాకు థర్డ్-పార్టీ సాఫ్ట్‌వేర్ లేదా డ్రైవర్‌లు ఏవీ అవసరం లేదు.

సంస్థాపన కోసం సిద్ధమవుతోంది

సిస్టమ్‌ను ఇన్‌స్టాల్ చేయడానికి మనకు ఉబుంటు డెస్క్‌టాప్ ఇమేజ్ అవసరం. సర్వర్ సిస్టమ్ ఒక రకమైన శక్తివంతమైన ఇన్‌స్టాలర్‌ను కలిగి ఉంది, ఇది UEFI సిస్టమ్ విభజనను డిస్క్‌లలో ఒకదానిపైకి నెట్టడం ద్వారా డిసేబుల్ చేయలేని అధిక స్వాతంత్ర్యాన్ని చూపుతుంది, మొత్తం అందాన్ని పాడు చేస్తుంది. దీని ప్రకారం, ఇది UEFI మోడ్‌లో మాత్రమే ఇన్‌స్టాల్ చేయబడింది. ఏ ఎంపికలను అందించదు.

దీనితో మేము సంతోషంగా లేము.

ఎందుకు?దురదృష్టవశాత్తూ, UEFI బూట్ బూట్ సాఫ్ట్‌వేర్ RAIDతో చాలా పేలవంగా అనుకూలంగా ఉంది, ఎందుకంటే... UEFI ESP విభజన కోసం ఎవరూ మాకు రిజర్వేషన్‌లను అందించరు. USB పోర్ట్‌లో ఫ్లాష్ డ్రైవ్‌లో ESP విభజనను ఉంచాలని సూచించే వంటకాలు ఇంటర్నెట్‌లో ఉన్నాయి, అయితే ఇది వైఫల్యానికి సంబంధించిన అంశం. మెటాడేటా వెర్షన్ 1తో సాఫ్ట్‌వేర్ mdadm RAID 0.9ని ఉపయోగించే వంటకాలు ఉన్నాయి, ఇవి UEFI BIOS ఈ విభజనను చూడకుండా నిరోధించవు, అయితే BIOS లేదా మరొక హార్డ్‌వేర్ OS ESPకి ఏదైనా వ్రాసి, దానిని ఇతర వాటికి సమకాలీకరించడం మర్చిపోయినప్పుడు ఇది సంతోషకరమైన క్షణం వరకు జీవిస్తుంది. అద్దాలు.

అదనంగా, UEFI బూట్ NVRAMపై ఆధారపడి ఉంటుంది, ఇది డిస్క్‌లతో పాటు కొత్త సిస్టమ్‌కు కదలదు, ఎందుకంటే మదర్‌బోర్డులో భాగం.

కాబట్టి, మేము కొత్త చక్రాన్ని తిరిగి ఆవిష్కరించము. UEFI-అనుకూల సిస్టమ్‌లలో CSM గర్వించదగిన పేరును కలిగి ఉన్న, ఇప్పుడు లెగసీ/BIOS బూట్ అని పిలువబడే, మేము ఇప్పటికే రెడీమేడ్, టైమ్-టెస్ట్ చేసిన తాత బైక్‌ని కలిగి ఉన్నాము. మేము దానిని షెల్ఫ్ నుండి తీసివేస్తాము, దానిని ద్రవపదార్థం చేస్తాము, టైర్లను పంప్ చేస్తాము మరియు తడి గుడ్డతో తుడవడం చేస్తాము.

ఉబుంటు యొక్క డెస్క్‌టాప్ వెర్షన్ కూడా లెగసీ బూట్‌లోడర్‌తో సరిగ్గా ఇన్‌స్టాల్ చేయబడదు, కానీ ఇక్కడ, వారు చెప్పినట్లు, కనీసం ఎంపికలు ఉన్నాయి.

కాబట్టి, మేము హార్డ్‌వేర్‌ను సేకరించి, ఉబుంటు లైవ్ బూటబుల్ ఫ్లాష్ డ్రైవ్ నుండి సిస్టమ్‌ను లోడ్ చేస్తాము. మేము ప్యాకేజీలను డౌన్‌లోడ్ చేయాల్సి ఉంటుంది, కాబట్టి మేము మీ కోసం పని చేసే నెట్‌వర్క్‌ను సెటప్ చేస్తాము. ఇది పని చేయకపోతే, మీరు ముందుగానే ఫ్లాష్ డ్రైవ్‌లో అవసరమైన ప్యాకేజీలను లోడ్ చేయవచ్చు.

మేము డెస్క్‌టాప్ ఎన్విరాన్‌మెంట్‌లోకి వెళ్లి, టెర్మినల్ ఎమ్యులేటర్‌ను ప్రారంభించాము మరియు ఆఫ్ చేస్తాము:

#sudo bash

ఎలా…?పైన ఉన్న లైన్ సుడో గురించి హోలీవార్‌ల కోసం కానానికల్ ట్రిగ్గర్. సి బిоఎక్కువ అవకాశాలు వస్తాయి మరియుоఎక్కువ బాధ్యత. మీరు దానిని మీరే తీసుకోగలరా అనేది ప్రశ్న. సుడోను ఈ విధంగా ఉపయోగించడం కనీసం జాగ్రత్తగా ఉండదని చాలా మంది అనుకుంటారు. అయితే:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

ZFS ఎందుకు కాదు...?మేము మా కంప్యూటర్‌లో సాఫ్ట్‌వేర్‌ను ఇన్‌స్టాల్ చేసినప్పుడు, ఈ సాఫ్ట్‌వేర్ డెవలపర్‌లకు డ్రైవ్ చేయడానికి తప్పనిసరిగా మా హార్డ్‌వేర్‌ను అందజేస్తాము.
మేము ఈ సాఫ్ట్‌వేర్‌ను మా డేటా భద్రతతో విశ్వసించినప్పుడు, ఈ డేటాను పునరుద్ధరించడానికి అయ్యే ఖర్చుతో సమానమైన రుణాన్ని తీసుకుంటాము, దానిని మనం ఏదో ఒక రోజు చెల్లించాల్సి ఉంటుంది.

ఈ దృక్కోణం నుండి, ZFS అనేది ఫెరారీ, మరియు mdadm+lvm అనేది సైకిల్ లాంటిది.

సబ్జెక్టివ్‌గా, రచయిత ఫెరారీకి బదులుగా తెలియని వ్యక్తులకు క్రెడిట్‌పై బైక్‌ను అప్పుగా ఇవ్వడానికి ఇష్టపడతారు. అక్కడ, ఇష్యూ ధర ఎక్కువగా లేదు. హక్కుల అవసరం లేదు. ట్రాఫిక్ నిబంధనల కంటే సరళమైనది. పార్కింగ్ ఉచితం. క్రాస్ కంట్రీ సామర్థ్యం మెరుగ్గా ఉంటుంది. మీరు ఎల్లప్పుడూ సైకిల్‌కు కాళ్లను అటాచ్ చేసుకోవచ్చు మరియు మీరు మీ స్వంత చేతులతో సైకిల్‌ను రిపేరు చేయవచ్చు.

అలాంటప్పుడు BTRFS ఎందుకు...?ఆపరేటింగ్ సిస్టమ్‌ను బూట్ చేయడానికి, బాక్స్ వెలుపల Legacy/BIOS GRUBలో మద్దతిచ్చే ఫైల్ సిస్టమ్ అవసరం మరియు అదే సమయంలో ప్రత్యక్ష స్నాప్‌షాట్‌లకు మద్దతు ఇస్తుంది. మేము దానిని /boot విభజన కోసం ఉపయోగిస్తాము. అదనంగా, రచయిత ఈ FSని / (రూట్) కోసం ఉపయోగించడాన్ని ఇష్టపడతారు, ఏదైనా ఇతర సాఫ్ట్‌వేర్ కోసం మీరు LVMపై ప్రత్యేక విభజనలను సృష్టించవచ్చు మరియు వాటిని అవసరమైన డైరెక్టరీలలో మౌంట్ చేయవచ్చు అని గుర్తుంచుకోవడం మర్చిపోవద్దు.

మేము ఈ FSలో వర్చువల్ మిషన్లు లేదా డేటాబేస్‌ల చిత్రాలను నిల్వ చేయము.
ఈ FS సిస్టమ్‌ని ఆఫ్ చేయకుండా స్నాప్‌షాట్‌లను సృష్టించడానికి మాత్రమే ఉపయోగించబడుతుంది మరియు ఈ స్నాప్‌షాట్‌లను పంపడం/స్వీకరించడం ఉపయోగించి బ్యాకప్ డిస్క్‌కి బదిలీ చేస్తుంది.

అదనంగా, రచయిత సాధారణంగా హార్డ్‌వేర్‌పై కనీస సాఫ్ట్‌వేర్‌ను ఉంచడానికి ఇష్టపడతారు మరియు IOMMU ద్వారా KVMకి GPUలు మరియు PCI-USB హోస్ట్ కంట్రోలర్‌లను ఫార్వార్డ్ చేయడం వంటి వాటిని ఉపయోగించి వర్చువల్ మిషన్‌లలో అన్ని ఇతర సాఫ్ట్‌వేర్‌లను అమలు చేయడానికి ఇష్టపడతారు.

హార్డ్‌వేర్‌లో డేటా నిల్వ, వర్చువలైజేషన్ మరియు బ్యాకప్ మాత్రమే మిగిలి ఉన్నాయి.

మీరు ZFSని ఎక్కువగా విశ్వసిస్తే, సూత్రప్రాయంగా, పేర్కొన్న అప్లికేషన్ కోసం అవి పరస్పరం మార్చుకోగలవు.

అయినప్పటికీ, రచయిత ఉద్దేశపూర్వకంగా ZFS, BRTFS మరియు LVM కలిగి ఉన్న అంతర్నిర్మిత మిర్రరింగ్/RAID మరియు రిడెండెన్సీ లక్షణాలను విస్మరించారు.

ఒక అదనపు వాదనగా, BTRFSకి యాదృచ్ఛిక వ్రాతలను సీక్వెన్షియల్‌గా మార్చగల సామర్థ్యం ఉంది, ఇది HDDలో స్నాప్‌షాట్‌లు/బ్యాకప్‌లను సమకాలీకరించే వేగంపై అత్యంత సానుకూల ప్రభావాన్ని చూపుతుంది.

అన్ని పరికరాలను మళ్లీ స్కాన్ చేద్దాం:

#udevadm control --reload-rules && udevadm trigger

చుట్టూ పరిశీలిద్దాం:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


డిస్క్ లేఅవుట్

NVMe SSD

కానీ మేము వాటిని ఏ విధంగానూ గుర్తించము. అదే, మా BIOS ఈ డ్రైవ్‌లను చూడదు. కాబట్టి, వారు పూర్తిగా సాఫ్ట్‌వేర్ RAIDకి వెళతారు. మేము అక్కడ విభాగాలను కూడా సృష్టించము. మీరు "కానన్" లేదా "ప్రధానంగా" అనుసరించాలనుకుంటే, HDD వంటి ఒక పెద్ద విభజనను సృష్టించండి.

SATA HDD

ఇక్కడ ప్రత్యేకంగా ఏమీ కనిపెట్టాల్సిన అవసరం లేదు. మేము ప్రతిదానికీ ఒక విభాగాన్ని సృష్టిస్తాము. మేము విభజనను సృష్టిస్తాము ఎందుకంటే BIOS ఈ డిస్కులను చూస్తుంది మరియు వాటి నుండి బూట్ చేయడానికి కూడా ప్రయత్నించవచ్చు. మేము తర్వాత ఈ డిస్క్‌లలో GRUBని ఇన్‌స్టాల్ చేస్తాము, తద్వారా సిస్టమ్ అకస్మాత్తుగా దీన్ని చేయగలదు.

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

ఇక్కడే విషయాలు మనకు ఆసక్తికరంగా ఉంటాయి.

ముందుగా, మా డ్రైవ్‌లు 2 TB పరిమాణంలో ఉంటాయి. ఇది MBR కోసం ఆమోదయోగ్యమైన పరిధిలో ఉంది, దీనినే మేము ఉపయోగిస్తాము. అవసరమైతే, GPTతో భర్తీ చేయవచ్చు. GPT డిస్క్‌లు MBR-అనుకూల సిస్టమ్‌లు మొదటి 4 టెరాబైట్లలో ఉన్నట్లయితే మొదటి 2 విభజనలను చూసేందుకు అనుమతించే అనుకూల పొరను కలిగి ఉంటాయి. ప్రధాన విషయం ఏమిటంటే, ఈ డిస్కులలో బూట్ విభజన మరియు బయోస్_గ్రబ్ విభజన ప్రారంభంలో ఉండాలి. ఇది మిమ్మల్ని GPT లెగసీ/BIOS డ్రైవ్‌ల నుండి బూట్ చేయడానికి కూడా అనుమతిస్తుంది.

కానీ ఇది మా కేసు కాదు.

ఇక్కడ మేము రెండు విభాగాలను సృష్టిస్తాము. మొదటిది 1 GB పరిమాణంలో ఉంటుంది మరియు RAID 1 /boot కోసం ఉపయోగించబడుతుంది.

రెండవది RAID 6 కోసం ఉపయోగించబడుతుంది మరియు డ్రైవ్ చివరిలో కేటాయించని చిన్న ప్రాంతం మినహా మిగిలిన ఖాళీ స్థలాన్ని తీసుకుంటుంది.

ఈ గుర్తు తెలియని ప్రాంతం ఏమిటి?నెట్‌వర్క్‌లోని మూలాల ప్రకారం, మా SATA SSDలు 6 నుండి 78 గిగాబైట్‌ల పరిమాణంలో డైనమిక్‌గా విస్తరించదగిన SLC కాష్‌ను కలిగి ఉన్నాయి. డ్రైవ్ యొక్క డేటా షీట్‌లో “గిగాబైట్‌లు” మరియు “గిబిబైట్‌లు” మధ్య వ్యత్యాసం కారణంగా మేము 6 గిగాబైట్‌లను “ఉచితంగా” పొందుతాము. మిగిలిన 72 గిగాబైట్‌లు ఉపయోగించని స్థలం నుండి కేటాయించబడ్డాయి.

ఇక్కడ మనకు SLC కాష్ ఉందని గమనించాలి మరియు స్థలం 4 బిట్ MLC మోడ్‌లో ఆక్రమించబడింది. మనకు ప్రభావవంతంగా అంటే ప్రతి 4 గిగాబైట్‌ల ఖాళీ స్థలం కోసం మేము 1 గిగాబైట్ SLC కాష్‌ని మాత్రమే పొందుతాము.

72 గిగాబైట్‌లను 4తో గుణించండి మరియు 288 గిగాబైట్‌లను పొందండి. SLC కాష్‌ని పూర్తిగా ఉపయోగించుకోవడానికి డ్రైవ్‌లను అనుమతించడానికి మేము గుర్తించలేని ఖాళీ స్థలం ఇది.

ఈ విధంగా, మేము మొత్తం ఆరు డ్రైవ్‌ల నుండి 312 గిగాబైట్ల SLC కాష్‌ని సమర్థవంతంగా పొందుతాము. అన్ని డ్రైవ్‌లలో, రిడెండెన్సీ కోసం 2 RAIDలో ఉపయోగించబడుతుంది.

ఈ కాష్ మొత్తం నిజ జీవితంలో చాలా అరుదుగా వ్రాత కాష్‌కి వెళ్లని పరిస్థితిని ఎదుర్కొనేలా చేస్తుంది. ఇది QLC మెమరీ యొక్క విచారకరమైన లోపాన్ని బాగా భర్తీ చేస్తుంది - కాష్‌ని దాటవేస్తూ డేటా వ్రాయబడినప్పుడు చాలా తక్కువ వ్రాత వేగం. మీ లోడ్‌లు దీనికి అనుగుణంగా లేకుంటే, డేటా షీట్ నుండి TBWని పరిగణనలోకి తీసుకుని, అటువంటి లోడ్‌లో మీ SSD ఎంతకాలం కొనసాగుతుందనే దాని గురించి మీరు గట్టిగా ఆలోచించాలని నేను సిఫార్సు చేస్తున్నాను.

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


శ్రేణులను సృష్టిస్తోంది

మొదట, మేము యంత్రం పేరు మార్చాలి. హోస్ట్ పేరు mdadm లోపల ఎక్కడో శ్రేణి పేరులో భాగం మరియు ఎక్కడో ఏదో ప్రభావితం చేస్తుంది కాబట్టి ఇది అవసరం. అయితే, శ్రేణుల తర్వాత పేరు మార్చవచ్చు, కానీ ఇది అనవసరమైన దశ.

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

ఎందుకు -ఊహించండి-శుభ్రంగా...?శ్రేణులను ప్రారంభించడాన్ని నివారించడానికి. RAID స్థాయిలు 1 మరియు 6 రెండింటికీ ఇది చెల్లుబాటు అవుతుంది. కొత్త శ్రేణి అయితే ప్రతిదీ ప్రారంభించకుండానే పని చేయవచ్చు. అంతేకాకుండా, సృష్టిపై SSD శ్రేణిని ప్రారంభించడం TBW వనరు యొక్క వ్యర్థం. అసెంబుల్ చేయబడిన SSD శ్రేణులను "ప్రారంభించడానికి" సాధ్యమైన చోట మేము TRIM/DISCARDని ఉపయోగిస్తాము.

SSD శ్రేణుల కోసం, RAID 1 డిస్కార్డ్ బాక్స్ వెలుపల మద్దతు ఇస్తుంది.

SSD RAID 6 డిస్కార్డ్ శ్రేణుల కోసం, మీరు దానిని తప్పనిసరిగా కెర్నల్ మాడ్యూల్ పారామితులలో ప్రారంభించాలి.

ఈ సిస్టమ్‌లోని స్థాయి 4/5/6 శ్రేణులలో ఉపయోగించిన అన్ని SSDలు discard_zeroes_data కోసం పని చేసే మద్దతును కలిగి ఉంటే మాత్రమే ఇది చేయాలి. కొన్నిసార్లు మీరు ఈ ఫంక్షన్‌కు మద్దతు ఇస్తున్నట్లు కెర్నల్‌కు చెప్పే వింత డ్రైవ్‌లను చూస్తారు, కానీ వాస్తవానికి అది అక్కడ లేదు లేదా ఫంక్షన్ ఎల్లప్పుడూ పని చేయదు. ప్రస్తుతానికి, మద్దతు దాదాపు ప్రతిచోటా అందుబాటులో ఉంది, అయితే, పాత డ్రైవ్‌లు మరియు లోపాలతో ఫర్మ్‌వేర్ ఉన్నాయి. ఈ కారణంగా, RAID 6 కోసం డిఫాల్ట్‌గా DISCARD మద్దతు నిలిపివేయబడింది.

శ్రద్ధ, కింది ఆదేశం శ్రేణిని “సున్నాలు”తో “ప్రారంభించడం” ద్వారా NVMe డ్రైవ్‌లలోని మొత్తం డేటాను నాశనం చేస్తుంది.

#blkdiscard /dev/md0

ఏదైనా తప్పు జరిగితే, ఒక దశను పేర్కొనడానికి ప్రయత్నించండి.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

ఎందుకు అంత పెద్ద...?భాగం-పరిమాణాన్ని పెంచడం అనేది చంక్-సైజ్ కలుపుకొని బ్లాక్‌లలో యాదృచ్ఛిక పఠనం యొక్క వేగంపై సానుకూల ప్రభావాన్ని చూపుతుంది. సముచితమైన పరిమాణం లేదా చిన్నదైన ఒక ఆపరేషన్‌ను పూర్తిగా ఒకే పరికరంలో పూర్తి చేయడం వలన ఇది జరుగుతుంది. అందువల్ల, అన్ని పరికరాల నుండి IOPS సంగ్రహించబడింది. గణాంకాల ప్రకారం, 99% IO 512K మించదు.

RAID ప్రతి వ్రాతకి 6 IOPSని కలిగి ఉంది ఎల్లప్పుడూ ఒక డ్రైవ్ యొక్క IOPS కంటే తక్కువ లేదా సమానం. యాదృచ్ఛికంగా చదవబడినప్పుడు, IOPS ఒక డ్రైవ్ కంటే చాలా రెట్లు ఎక్కువగా ఉంటుంది మరియు ఇక్కడ బ్లాక్ పరిమాణం చాలా ముఖ్యమైనది.
RAID 6 బై-డిజైన్‌లో చెడుగా ఉన్న పారామీటర్‌ను ఆప్టిమైజ్ చేయడానికి ప్రయత్నించడంలో రచయిత పాయింట్‌ను చూడలేదు మరియు బదులుగా RAID 6 ఏది మంచిదో ఆప్టిమైజ్ చేస్తుంది.
NVMe కాష్ మరియు థిన్-ప్రొవిజనింగ్ ట్రిక్స్‌తో RAID 6 యొక్క పేలవమైన యాదృచ్ఛిక వ్రాతని మేము భర్తీ చేస్తాము.

మేము RAID 6 కోసం డిస్కార్డ్‌ని ఇంకా ప్రారంభించలేదు. కాబట్టి మేము ప్రస్తుతానికి ఈ శ్రేణిని "ప్రారంభించము". OSని ఇన్‌స్టాల్ చేసిన తర్వాత మేము దీన్ని తర్వాత చేస్తాము.

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

NVMe RAIDపై LVM

వేగం కోసం, మేము రూట్ ఫైల్ సిస్టమ్‌ను NVMe RAID 1లో ఉంచాలనుకుంటున్నాము, అది /dev/md0.
అయినప్పటికీ, స్వాప్, మెటాడేటా మరియు LVM-cache మరియు LVM-సన్నని మెటాడేటా వంటి ఇతర అవసరాల కోసం మనకు ఇప్పటికీ ఈ ఫాస్ట్ అర్రే అవసరం అవుతుంది, కాబట్టి మేము ఈ శ్రేణిపై LVM VGని సృష్టిస్తాము.

#pvcreate /dev/md0
#vgcreate root /dev/md0

రూట్ ఫైల్ సిస్టమ్ కోసం విభజనను క్రియేట్ చేద్దాం.

#lvcreate -L 128G --name root root

RAM పరిమాణం ప్రకారం మార్పిడి కోసం విభజనను క్రియేట్ చేద్దాం.

#lvcreate -L 32G --name swap root

OS సంస్థాపన

మొత్తంగా, సిస్టమ్‌ను ఇన్‌స్టాల్ చేయడానికి అవసరమైన ప్రతిదీ మా వద్ద ఉంది.

ఉబుంటు లైవ్ ఎన్విరాన్మెంట్ నుండి సిస్టమ్ ఇన్‌స్టాలేషన్ విజార్డ్‌ను ప్రారంభించండి. సాధారణ సంస్థాపన. ఇన్‌స్టాలేషన్ కోసం డిస్క్‌లను ఎంచుకునే దశలో మాత్రమే, మీరు ఈ క్రింది వాటిని పేర్కొనాలి:

• /dev/md1, - మౌంట్ పాయింట్ /boot, FS - BTRFS
• /dev/root/root (aka /dev/mapper/root-root), - మౌంట్ పాయింట్ / (రూట్), FS - BTRFS
• /dev/root/swap (aka /dev/mapper/root-swap), - స్వాప్ విభజనగా ఉపయోగించండి
• /dev/sdaలో బూట్‌లోడర్‌ను ఇన్‌స్టాల్ చేయండి

మీరు BTRFSని రూట్ ఫైల్ సిస్టమ్‌గా ఎంచుకున్నప్పుడు, ఇన్‌స్టాలర్ స్వయంచాలకంగా "@" అనే పేరుతో రెండు BTRFS వాల్యూమ్‌లను సృష్టిస్తుంది / (root), మరియు "@home" /home కోసం.

ఇన్‌స్టాలేషన్‌ని ప్రారంభిద్దాం...

బూట్‌లోడర్‌ను ఇన్‌స్టాల్ చేయడంలో లోపాన్ని సూచించే మోడల్ డైలాగ్ బాక్స్‌తో ఇన్‌స్టాలేషన్ ముగుస్తుంది. దురదృష్టవశాత్తూ, మీరు ప్రామాణిక మార్గాలను ఉపయోగించి ఈ డైలాగ్ నుండి నిష్క్రమించలేరు మరియు ఇన్‌స్టాలేషన్‌ను కొనసాగించలేరు. మేము సిస్టమ్ నుండి లాగ్ అవుట్ చేసి, మళ్లీ లాగిన్ చేసి, శుభ్రమైన ఉబుంటు లైవ్ డెస్క్‌టాప్‌లో ముగుస్తుంది. టెర్మినల్‌ని తెరిచి, మళ్లీ:

#sudo bash

ఇన్‌స్టాలేషన్‌ను కొనసాగించడానికి chroot వాతావరణాన్ని సృష్టించండి:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

chrootలో నెట్‌వర్క్ మరియు హోస్ట్ పేరును కాన్ఫిగర్ చేద్దాం:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

chroot వాతావరణంలోకి వెళ్దాం:

#chroot /mnt/chroot

అన్నింటిలో మొదటిది, మేము ప్యాకేజీలను పంపిణీ చేస్తాము:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

అసంపూర్తిగా ఉన్న సిస్టమ్ ఇన్‌స్టాలేషన్ కారణంగా వంకరగా ఇన్‌స్టాల్ చేయబడిన అన్ని ప్యాకేజీలను తనిఖీ చేసి, పరిష్కరిద్దాం:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

ఏదైనా పని చేయకపోతే, మీరు ముందుగా /etc/apt/sources.listని సవరించాలి

TRIM/DISCARDని ప్రారంభించడానికి RAID 6 మాడ్యూల్ కోసం పారామితులను సర్దుబాటు చేద్దాం:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

మన శ్రేణులను కొద్దిగా సర్దుబాటు చేద్దాం:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

అదేమిటి..?మేము ఈ క్రింది వాటిని చేసే udev నియమాల సమితిని సృష్టించాము:

• RAID 2020 కోసం బ్లాక్ కాష్ పరిమాణాన్ని 6కి సరిపోయేలా సెట్ చేయండి. డిఫాల్ట్ విలువ, Linux సృష్టించినప్పటి నుండి మారలేదు మరియు చాలా కాలం పాటు సరిపోలేదు.
• శ్రేణి తనిఖీలు/సమకాలీకరణల వ్యవధి కోసం కనీసం IOని రిజర్వ్ చేయండి. ఇది మీ శ్రేణులు లోడ్‌లో శాశ్వతమైన సమకాలీకరణ స్థితిలో చిక్కుకోకుండా నిరోధించడం.
• తనిఖీలు/శ్రేణుల సమకాలీకరణ సమయంలో గరిష్ట IOని పరిమితం చేయండి. SSD RAIDలను సమకాలీకరించడం/తనిఖీ చేయడం వలన మీ డ్రైవ్‌లు స్ఫుటంగా మారవు కాబట్టి ఇది అవసరం. ఇది ముఖ్యంగా NVMeకి వర్తిస్తుంది. (రేడియేటర్ గురించి గుర్తుందా? నేను జోక్ చేయలేదు.)
• APM ద్వారా స్పిండిల్ రొటేషన్ (HDD)ని ఆపకుండా డిస్క్‌లను నిషేధించండి మరియు డిస్క్ కంట్రోలర్‌ల కోసం నిద్ర సమయం ముగియడాన్ని 7 గంటలకు సెట్ చేయండి. మీ డ్రైవ్‌లు దీన్ని చేయగలిగితే మీరు APMని పూర్తిగా నిలిపివేయవచ్చు (-B 255). డిఫాల్ట్ విలువతో, డ్రైవ్‌లు ఐదు సెకన్ల తర్వాత ఆగిపోతాయి. అప్పుడు OS డిస్క్ కాష్‌ని రీసెట్ చేయాలనుకుంటోంది, డిస్క్‌లు మళ్లీ స్పిన్ అప్ అవుతాయి మరియు ప్రతిదీ మళ్లీ మళ్లీ ప్రారంభమవుతుంది. డిస్క్‌లు పరిమిత గరిష్ట సంఖ్యలో కుదురు భ్రమణాలను కలిగి ఉంటాయి. ఇటువంటి సాధారణ డిఫాల్ట్ చక్రం కొన్ని సంవత్సరాలలో మీ డిస్క్‌లను సులభంగా చంపగలదు. అన్ని డిస్క్‌లు దీనితో బాధపడవు, కానీ మాది “ల్యాప్‌టాప్”, తగిన డిఫాల్ట్ సెట్టింగ్‌లతో, RAIDని మినీ-MAID లాగా చేస్తుంది.
• డిస్క్‌లపై రీడ్‌హెడ్‌ను ఇన్‌స్టాల్ చేయండి (తిప్పడం) 1 మెగాబైట్ - రెండు వరుస బ్లాక్‌లు/చంక్ RAID 6
• శ్రేణుల్లోనే రీడ్‌హెడ్‌ని నిలిపివేయండి.

/etc/fstabని ఎడిట్ చేద్దాం:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
అది ఎందుకు..?మేము UUID ద్వారా /boot విభజన కోసం శోధిస్తాము. శ్రేణి నామకరణం సిద్ధాంతపరంగా మారవచ్చు.

మేము /dev/mapper/vg-lv సంజ్ఞామానంలో LVM పేర్లతో మిగిలిన విభాగాల కోసం శోధిస్తాము, ఎందుకంటే వారు విభజనలను చాలా ప్రత్యేకంగా గుర్తిస్తారు.

మేము LVM కోసం UUIDని ఉపయోగించము ఎందుకంటే LVM వాల్యూమ్‌ల UUID మరియు వాటి స్నాప్‌షాట్‌లు ఒకే విధంగా ఉండవచ్చు.మౌంట్ /dev/mapper/root-root.. రెండుసార్లు?అవును. సరిగ్గా. BTRFS యొక్క లక్షణం. ఈ ఫైల్ సిస్టమ్‌ను వివిధ సబ్‌వోల్‌లతో అనేకసార్లు మౌంట్ చేయవచ్చు.

ఇదే ఫీచర్ కారణంగా, సక్రియ BTRFS వాల్యూమ్‌ల LVM స్నాప్‌షాట్‌లను ఎప్పుడూ సృష్టించవద్దని నేను సిఫార్సు చేస్తున్నాను. మీరు రీబూట్ చేసినప్పుడు మీకు ఆశ్చర్యం కలగవచ్చు.

mdadm configని పునరుత్పత్తి చేద్దాం:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

LVM సెట్టింగ్‌లను సర్దుబాటు చేద్దాం:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

అదేమిటి..?ఆక్రమిత స్థలంలో 90% వాల్యూమ్‌లో 5%కి చేరుకున్న తర్వాత మేము LVM థిన్ పూల్స్‌ను ఆటోమేటిక్‌గా విస్తరించడాన్ని ప్రారంభించాము.

మేము LVM కాష్ కోసం గరిష్ట సంఖ్యలో కాష్ బ్లాక్‌లను పెంచాము.

LVM వాల్యూమ్‌ల (PV) కోసం శోధించకుండా మేము LVMని నిరోధించాము:

• LVM కాష్ (cdata)ని కలిగి ఉన్న పరికరాలు
• కాష్‌ను దాటవేస్తూ, LVM కాష్‌ని ఉపయోగించి కాష్ చేయబడిన పరికరాలు ( _కోరిగ్). ఈ సందర్భంలో, కాష్ చేయబడిన పరికరం ఇప్పటికీ కాష్ ద్వారా స్కాన్ చేయబడుతుంది (కేవలం )
• LVM కాష్ మెటాడేటా (cmeta)ని కలిగి ఉన్న పరికరాలు
• పేరు చిత్రాలతో VGలోని అన్ని పరికరాలు. ఇక్కడ మనం వర్చువల్ మిషన్ల డిస్క్ ఇమేజ్‌లను కలిగి ఉంటాము మరియు అతిథి OSకి చెందిన వాల్యూమ్‌లను హోస్ట్‌లో LVM సక్రియం చేయకూడదనుకుంటున్నాము.
• బ్యాకప్ పేరుతో VGలోని అన్ని పరికరాలు. ఇక్కడ మనకు వర్చువల్ మెషిన్ ఇమేజ్‌ల బ్యాకప్ కాపీలు ఉంటాయి.
• "gpv" (అతిథి భౌతిక వాల్యూమ్)తో ముగిసే అన్ని పరికరాలు

LVM VGలో ఖాళీ స్థలాన్ని ఖాళీ చేస్తున్నప్పుడు మేము డిస్కార్డ్ మద్దతును ప్రారంభించాము. జాగ్రత్త. ఇది SSDలో LVలను తొలగించడం చాలా సమయం తీసుకుంటుంది. ఇది ప్రత్యేకంగా SSD RAID 6కి వర్తిస్తుంది. అయితే, ప్లాన్ ప్రకారం, మేము సన్నని ప్రొవిజనింగ్‌ని ఉపయోగిస్తాము, కాబట్టి ఇది మాకు ఎటువంటి ఆటంకం కలిగించదు.

initramfs చిత్రాన్ని అప్‌డేట్ చేద్దాం:

#update-initramfs -u -k all

గ్రబ్‌ని ఇన్‌స్టాల్ చేసి కాన్ఫిగర్ చేయండి:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

ఏ డిస్కులను ఎంచుకోవాలి?sd* అయిన వారందరూ. సిస్టమ్ తప్పనిసరిగా ఏదైనా పని చేస్తున్న SATA డ్రైవ్ లేదా SSD నుండి బూట్ చేయగలగాలి.

os-proberని ఎందుకు జోడించారు..?అధిక స్వాతంత్ర్యం మరియు ఉల్లాసభరితమైన చేతుల కోసం.

RAIDలలో ఒకటి క్షీణించిన స్థితిలో ఉంటే అది సరిగ్గా పని చేయదు. ఈ హార్డ్‌వేర్‌పై నడుస్తున్న వర్చువల్ మిషన్‌లలో ఉపయోగించే విభజనలపై OS కోసం శోధించడానికి ఇది ప్రయత్నిస్తుంది.

మీకు అవసరమైతే, మీరు దానిని వదిలివేయవచ్చు, కానీ పైన పేర్కొన్నవన్నీ గుర్తుంచుకోండి. ఆన్‌లైన్‌లో కొంటె చేతులను వదిలించుకోవడానికి వంటకాల కోసం వెతకమని నేను సిఫార్సు చేస్తున్నాను.

దీనితో మేము ప్రారంభ సంస్థాపనను పూర్తి చేసాము. కొత్తగా ఇన్‌స్టాల్ చేసిన OSలోకి రీబూట్ చేయడానికి ఇది సమయం. బూటబుల్ లైవ్ CD/USBని తీసివేయడం మర్చిపోవద్దు.

#exit
#reboot

బూట్ పరికరంగా SATA SSDలలో దేనినైనా ఎంచుకోండి.

SATA SSDలో LVM

ఈ సమయంలో, మేము ఇప్పటికే కొత్త OS లోకి బూట్ చేసాము, నెట్‌వర్క్‌ను కాన్ఫిగర్ చేసాము, సముచితంగా, టెర్మినల్ ఎమ్యులేటర్‌ను తెరిచి, ప్రారంభించాము:

#sudo bash

ముందుకు సాగిద్దాము.

SATA SSD నుండి శ్రేణిని "ప్రారంభించు":

#blkdiscard /dev/md2

ఇది పని చేయకపోతే, ప్రయత్నించండి:

#blkdiscard --step 65536 /dev/md2
SATA SSDలో LVM VGని సృష్టించండి:

#pvcreate /dev/md2
#vgcreate data /dev/md2

మరి వీజీ ఎందుకు..?నిజానికి, మనకు ఇప్పటికే రూట్ అనే VG ఉంది. అన్నింటినీ ఒకే VGలో ఎందుకు జోడించకూడదు?

VGలో అనేక PVలు ఉంటే, VG సరిగ్గా సక్రియం కావాలంటే, అన్ని PVలు తప్పనిసరిగా ఉండాలి (ఆన్‌లైన్). మినహాయింపు LVM RAID, ఇది మేము ఉద్దేశపూర్వకంగా ఉపయోగించము.

RAID 6 శ్రేణులలో ఏదైనా వైఫల్యం (డేటా నష్టాన్ని చదవడం) ఉంటే, ఆపరేటింగ్ సిస్టమ్ సాధారణంగా బూట్ అవుతుంది మరియు సమస్యను పరిష్కరించడానికి మాకు అవకాశం ఇవ్వాలని మేము నిజంగా కోరుకుంటున్నాము.

దీన్ని చేయడానికి, సంగ్రహణ యొక్క మొదటి స్థాయి వద్ద మేము ప్రతి రకమైన భౌతిక "మీడియా"ని ప్రత్యేక VGగా వేరు చేస్తాము.

శాస్త్రీయంగా చెప్పాలంటే, వివిధ RAID శ్రేణులు వేర్వేరు “విశ్వసనీయత డొమైన్‌లకు” చెందినవి. మీరు వాటిని ఒక VG లోకి క్రామ్ చేయడం ద్వారా వారి కోసం అదనపు సాధారణ వైఫల్యాన్ని సృష్టించకూడదు.

"హార్డ్‌వేర్" స్థాయిలో LVM ఉండటం వలన వివిధ RAID శ్రేణుల ముక్కలను వివిధ మార్గాల్లో కలపడం ద్వారా వాటిని ఏకపక్షంగా కత్తిరించడానికి అనుమతిస్తుంది. ఉదాహరణకు - రన్ అదే సమయంలో bcache + LVM థిన్, bcache + BTRFS, LVM కాష్ + LVM థిన్, కాష్‌లతో కూడిన కాంప్లెక్స్ ZFS కాన్ఫిగరేషన్ లేదా అన్నింటినీ ప్రయత్నించి, సరిపోల్చడానికి ఏదైనా ఇతర పాపిష్ మిశ్రమం.

“హార్డ్‌వేర్” స్థాయిలో, మేము మంచి పాత “మందపాటి” LVM వాల్యూమ్‌లను తప్ప వేటినీ ఉపయోగించము. ఈ నియమానికి మినహాయింపు బ్యాకప్ విభజన కావచ్చు.

ఈ సమయానికి, చాలా మంది పాఠకులు ఇప్పటికే గూడు బొమ్మ గురించి ఏదో అనుమానించడం ప్రారంభించారని నేను అనుకుంటున్నాను.

SATA HDDపై LVM

#pvcreate /dev/md3
#vgcreate backup /dev/md3

మళ్లీ కొత్త వీజీ..?మేము డేటా బ్యాకప్ కోసం ఉపయోగించే డిస్క్ శ్రేణి విఫలమైతే, మా ఆపరేటింగ్ సిస్టమ్ సాధారణంగా పని చేస్తూనే, బ్యాకప్ కాని డేటాకు యధావిధిగా యాక్సెస్‌ను కొనసాగించాలని మేము నిజంగా కోరుకుంటున్నాము. కాబట్టి, VG యాక్టివేషన్ సమస్యలను నివారించడానికి, మేము ప్రత్యేక VGని సృష్టిస్తాము.

LVM కాష్‌ని సెటప్ చేస్తోంది

దానిని కాషింగ్ పరికరంగా ఉపయోగించడానికి NVMe RAID 1లో LVని సృష్టిద్దాం.

#lvcreate -L 70871154688B --name cache root

ఎందుకింత తక్కువ...?నిజానికి మా NVMe SSDలు కూడా SLC కాష్‌ని కలిగి ఉన్నాయి. 4-బిట్ MLCలో ఆక్రమించబడిన ఖాళీ స్థలం కారణంగా 18 గిగాబైట్‌ల “ఉచిత” మరియు 3 గిగాబైట్‌ల డైనమిక్. ఈ కాష్ అయిపోయిన తర్వాత, NVMe SSDలు కాష్‌తో మా SATA SSD కంటే చాలా వేగంగా ఉండవు. వాస్తవానికి, ఈ కారణంగా, LVM కాష్ విభజనను NVMe డ్రైవ్ యొక్క SLC కాష్ పరిమాణం కంటే రెండు రెట్లు పెద్దదిగా చేయడంలో మాకు అర్థం లేదు. ఉపయోగించిన NVMe డ్రైవ్‌ల కోసం, రచయిత 32-64 గిగాబైట్‌ల కాష్‌ని తయారు చేయడం సహేతుకమని భావించారు.

64 గిగాబైట్‌ల కాష్, కాష్ మెటాడేటా మరియు మెటాడేటా బ్యాకప్‌ని నిర్వహించడానికి ఇచ్చిన విభజన పరిమాణం అవసరం.

అదనంగా, డర్టీ సిస్టమ్ షట్‌డౌన్ తర్వాత, LVM మొత్తం కాష్‌ను డర్టీగా గుర్తించి, మళ్లీ సింక్రొనైజ్ చేస్తుందని నేను గమనించాను. అంతేకాకుండా, సిస్టమ్ మళ్లీ రీబూట్ అయ్యే వరకు ఈ పరికరంలో lvchange ఉపయోగించిన ప్రతిసారీ ఇది పునరావృతమవుతుంది. అందువల్ల, తగిన స్క్రిప్ట్‌ని ఉపయోగించి కాష్‌ను వెంటనే పునఃసృష్టించాలని నేను సిఫార్సు చేస్తున్నాను.

SATA RAID 6ని కాష్ చేసిన పరికరంగా ఉపయోగించడానికి LVని క్రియేట్ చేద్దాం.

#lvcreate -L 3298543271936B --name cache data

మూడు టెరాబైట్లే ఎందుకు..?కాబట్టి, అవసరమైతే, మీరు కొన్ని ఇతర అవసరాల కోసం SATA SSD RAID 6ని ఉపయోగించవచ్చు. సిస్టమ్‌ను ఆపకుండా, ఎగిరిపోతున్నప్పుడు, కాష్ చేయబడిన స్థలం యొక్క పరిమాణాన్ని డైనమిక్‌గా పెంచవచ్చు. దీన్ని చేయడానికి, మీరు కాష్‌ను తాత్కాలికంగా ఆపివేసి, మళ్లీ ప్రారంభించాలి, అయితే LVM-cache యొక్క ప్రత్యేక ప్రయోజనం, ఉదాహరణకు, bcache ఇది ఫ్లైలో చేయవచ్చు.

కాషింగ్ కోసం కొత్త VGని క్రియేట్ చేద్దాం.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

కాష్ చేయబడిన పరికరంలో LVని సృష్టిద్దాం.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

ఇక్కడ మేము వెంటనే /dev/data/cacheలో ఖాళీ స్థలాన్ని తీసుకున్నాము, తద్వారా అన్ని ఇతర అవసరమైన విభజనలు వెంటనే /dev/root/cacheలో సృష్టించబడతాయి. మీరు తప్పు స్థలంలో ఏదైనా సృష్టించినట్లయితే, మీరు దానిని pvmove ఉపయోగించి తరలించవచ్చు.

కాష్‌ని సృష్టించి, ఎనేబుల్ చేద్దాం:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

ఇంత చంక్‌సైజ్ ఎందుకు..?ఆచరణాత్మక ప్రయోగాల ద్వారా, LVM కాష్ బ్లాక్ పరిమాణం LVM థిన్ బ్లాక్ పరిమాణంతో సమానంగా ఉంటే ఉత్తమ ఫలితం సాధించబడుతుందని రచయిత కనుగొనగలిగారు. అంతేకాకుండా, చిన్న పరిమాణం, యాదృచ్ఛిక రికార్డింగ్‌లో కాన్ఫిగరేషన్ మెరుగ్గా పనిచేస్తుంది.

64k అనేది LVM థిన్ కోసం అనుమతించబడిన కనీస బ్లాక్ పరిమాణం.

జాగ్రత్తగా వ్రాయండి..!అవును. ఈ రకమైన కాష్ కాష్ చేయబడిన పరికరానికి రైట్ సింక్రొనైజేషన్‌ను వాయిదా వేస్తుంది. దీని అర్థం కాష్ పోయినట్లయితే, మీరు కాష్ చేయబడిన పరికరంలోని డేటాను కోల్పోవచ్చు. తరువాత, ఈ ప్రమాదాన్ని భర్తీ చేయడానికి NVMe RAID 1తో పాటుగా ఎలాంటి చర్యలు తీసుకోవచ్చో రచయిత మీకు తెలియజేస్తారు.

RAID 6 యొక్క పేలవమైన యాదృచ్ఛిక వ్రాత పనితీరును భర్తీ చేయడానికి ఈ కాష్ రకం ఉద్దేశపూర్వకంగా ఎంపిక చేయబడింది.

మనకు లభించిన వాటిని తనిఖీ చేద్దాం:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

/dev/data/cacheలో [cachedata_corig] మాత్రమే ఉండాలి. ఏదైనా తప్పు ఉంటే, అప్పుడు pvmove ఉపయోగించండి.

అవసరమైతే మీరు ఒక ఆదేశంతో కాష్‌ను నిలిపివేయవచ్చు:

#lvconvert -y --uncache cache/cachedata

ఇది ఆన్‌లైన్‌లో జరుగుతుంది. LVM కాష్‌ని డిస్క్‌కి సింక్ చేస్తుంది, దాన్ని తీసివేసి, క్యాచెడేటా_కోరిగ్‌ని తిరిగి క్యాచెడేటాగా మారుస్తుంది.

LVM థిన్‌ని సెటప్ చేస్తోంది

LVM థిన్ మెటాడేటా కోసం మనకు ఎంత స్థలం అవసరమో స్థూలంగా అంచనా వేద్దాం:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4 గిగాబైట్‌ల వరకు రౌండ్ చేయండి: 4294967296B

LVM PV మెటాడేటా కోసం రెండుతో గుణించి 4194304Bని జోడించండి: 8594128896B
LVM సన్నని మెటాడేటా మరియు వాటి బ్యాకప్ కాపీని ఉంచడానికి NVMe RAID 1లో ప్రత్యేక విభజనను సృష్టిద్దాం:

#lvcreate -L 8594128896B --name images root

దేనికోసం..?ఇక్కడ ప్రశ్న తలెత్తవచ్చు: LVM సన్నని మెటాడేటా ఇప్పటికీ NVMeలో కాష్ చేయబడి, త్వరగా పని చేస్తే విడిగా ఎందుకు ఉంచండి.

ఇక్కడ వేగం ముఖ్యమైనది అయినప్పటికీ, ఇది ప్రధాన కారణం నుండి దూరంగా ఉంది. విషయం ఏమిటంటే కాష్ వైఫల్యం యొక్క పాయింట్. దానికి ఏదైనా జరగవచ్చు మరియు LVM థిన్ మెటాడేటా కాష్ చేయబడితే, అది ప్రతిదీ పూర్తిగా కోల్పోయేలా చేస్తుంది. పూర్తి మెటాడేటా లేకుండా, సన్నని వాల్యూమ్‌లను సమీకరించడం దాదాపు అసాధ్యం.

మెటాడేటాను కాష్ చేయని, వేగవంతమైన వాల్యూమ్‌కి తరలించడం ద్వారా, కాష్ నష్టం లేదా అవినీతి జరిగినప్పుడు మేము మెటాడేటా భద్రతకు హామీ ఇస్తాము. ఈ సందర్భంలో, కాష్ నష్టం వల్ల కలిగే అన్ని నష్టం సన్నని వాల్యూమ్‌లలో స్థానీకరించబడుతుంది, ఇది పరిమాణం యొక్క ఆర్డర్‌ల ద్వారా రికవరీ విధానాన్ని సులభతరం చేస్తుంది. అధిక సంభావ్యతతో, ఈ నష్టాలు FS లాగ్‌లను ఉపయోగించి పునరుద్ధరించబడతాయి.

అంతేకాకుండా, ఒక సన్నని వాల్యూమ్ యొక్క స్నాప్‌షాట్ మునుపు తీసినట్లయితే, మరియు ఆ తర్వాత కాష్ కనీసం ఒక్కసారైనా పూర్తిగా సమకాలీకరించబడినట్లయితే, LVM థిన్ యొక్క అంతర్గత రూపకల్పన కారణంగా, కాష్ నష్టపోయిన సందర్భంలో స్నాప్‌షాట్ యొక్క సమగ్రత హామీ ఇవ్వబడుతుంది. .

థిన్-ప్రొవిజనింగ్‌కు బాధ్యత వహించే కొత్త VGని సృష్టిద్దాం:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
పూల్‌ని క్రియేట్ చేద్దాం:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
ఎందుకు -Z వైఈ మోడ్ వాస్తవానికి ఉద్దేశించబడిన దానితో పాటు - స్థలాన్ని పునఃపంపిణీ చేసేటప్పుడు ఒక వర్చువల్ మెషీన్ నుండి మరొక వర్చువల్ మెషీన్‌కు డేటా లీక్ అవ్వకుండా నిరోధించడానికి - 64k కంటే తక్కువ బ్లాక్‌లలో యాదృచ్ఛికంగా వ్రాసే వేగాన్ని పెంచడానికి జీరోయింగ్ అదనంగా ఉపయోగించబడుతుంది. మునుపు కేటాయించని సన్నని వాల్యూమ్ ప్రాంతానికి 64k కంటే తక్కువ వ్రాసే ఏదైనా కాష్‌లో 64K అంచుకు సమలేఖనం చేయబడుతుంది. ఇది కాష్ చేయబడిన పరికరాన్ని దాటవేస్తూ, పూర్తిగా కాష్ ద్వారా ఆపరేషన్ చేయడానికి అనుమతిస్తుంది.

LVలను సంబంధిత PVలకు తరలిద్దాం:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

తనిఖీ చేద్దాం:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

పరీక్షల కోసం సన్నని వాల్యూమ్‌ను క్రియేట్ చేద్దాం:

#lvcreate -V 64G --thin-pool thin-pool --name test images

మేము పరీక్షలు మరియు పర్యవేక్షణ కోసం ప్యాకేజీలను ఇన్‌స్టాల్ చేస్తాము:

#apt-get install sysstat fio

మీరు నిజ సమయంలో మా నిల్వ కాన్ఫిగరేషన్ ప్రవర్తనను ఈ విధంగా గమనించవచ్చు:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

మన కాన్ఫిగరేషన్‌ని ఈ విధంగా పరీక్షించవచ్చు:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

జాగ్రత్తగా! వనరు!ఈ కోడ్ 36 వేర్వేరు పరీక్షలను అమలు చేస్తుంది, ప్రతి ఒక్కటి 4 సెకన్ల పాటు నడుస్తుంది. సగం పరీక్షలు రికార్డింగ్ కోసం. మీరు 4 సెకన్లలో NVMeలో చాలా రికార్డ్ చేయవచ్చు. సెకనుకు 3 గిగాబైట్ల వరకు. కాబట్టి, వ్రాత పరీక్షల యొక్క ప్రతి పరుగు మీ నుండి 216 గిగాబైట్ల SSD వనరులను తినవచ్చు.

చదవడం మరియు రాయడం మిశ్రమంగా ఉందా?అవును. చదవడం, రాయడం పరీక్షలు విడివిడిగా నిర్వహించడం సమంజసం. అంతేకాకుండా, అన్ని కాష్‌లు సమకాలీకరించబడిందని నిర్ధారించుకోవడం అర్ధమే, తద్వారా గతంలో చేసిన రైట్ రీడ్‌ను ప్రభావితం చేయదు.

మొదటి ప్రయోగ సమయంలో ఫలితాలు మరియు కాష్ మరియు థిన్ వాల్యూమ్ నిండినందున తదుపరి వాటి ఫలితాలు చాలా మారుతూ ఉంటాయి మరియు చివరి ప్రయోగ సమయంలో నింపిన కాష్‌లను సిస్టమ్ సమకాలీకరించగలదా అనే దానిపై ఆధారపడి ఉంటుంది.

ఇతర విషయాలతోపాటు, స్నాప్‌షాట్ తీసిన ఇప్పటికే పూర్తి సన్నని వాల్యూమ్‌లో వేగాన్ని కొలవాలని నేను సిఫార్సు చేస్తున్నాను. మొదటి స్నాప్‌షాట్‌ను సృష్టించిన తర్వాత, ప్రత్యేకించి కాష్ ఇంకా పూర్తిగా నిండనప్పుడు, యాదృచ్ఛికంగా వ్రాసే రచనలు ఎంత వేగంగా వేగవంతం అవుతాయో గమనించే అవకాశం రచయితకు ఉంది. ఇది కాపీ-ఆన్-రైట్ రైట్ సెమాంటిక్స్, కాష్ యొక్క అమరిక మరియు సన్నని వాల్యూమ్ బ్లాక్‌ల కారణంగా జరుగుతుంది మరియు RAID 6కి యాదృచ్ఛికంగా వ్రాయడం RAID 6 నుండి యాదృచ్ఛిక రీడ్‌గా మారుతుంది, తర్వాత కాష్‌కు వ్రాయబడుతుంది. మా కాన్ఫిగరేషన్‌లో, RAID 6 నుండి యాదృచ్ఛిక పఠనం వ్రాయడం కంటే 6 రెట్లు (అరేలోని SATA SSDల సంఖ్య) వేగంగా ఉంటుంది. ఎందుకంటే CW కోసం బ్లాక్‌లు ఒక సన్నని పూల్ నుండి వరుసగా కేటాయించబడతాయి, తర్వాత రికార్డింగ్ చాలా వరకు సీక్వెన్షియల్‌గా మారుతుంది.

ఈ రెండు లక్షణాలను మీ ప్రయోజనం కోసం ఉపయోగించవచ్చు.

కాష్ "కోహెరెంట్" స్నాప్‌షాట్‌లు

కాష్ డ్యామేజ్/నష్టం జరిగినప్పుడు డేటా నష్టపోయే ప్రమాదాన్ని తగ్గించడానికి, ఈ సందర్భంలో వాటి సమగ్రతకు హామీ ఇవ్వడానికి స్నాప్‌షాట్‌లను తిప్పే పద్ధతిని పరిచయం చేయాలని రచయిత ప్రతిపాదించారు.

ముందుగా, సన్నని వాల్యూమ్ మెటాడేటా కాష్ చేయని పరికరంలో ఉన్నందున, మెటాడేటా స్థిరంగా ఉంటుంది మరియు డేటా బ్లాక్‌లలో సాధ్యమయ్యే నష్టాలు వేరుచేయబడతాయి.

కింది స్నాప్‌షాట్ భ్రమణ చక్రం కాష్ నష్టపోయినప్పుడు స్నాప్‌షాట్‌లలోని డేటా యొక్క సమగ్రతకు హామీ ఇస్తుంది:

1. <name> పేరుతో ప్రతి సన్నని వాల్యూమ్ కోసం, <name>.cached పేరుతో స్నాప్‌షాట్‌ను సృష్టించండి
2. మైగ్రేషన్ థ్రెషోల్డ్‌ను సహేతుకమైన అధిక విలువకు సెట్ చేద్దాం: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. లూప్‌లో మేము కాష్‌లోని డర్టీ బ్లాక్‌ల సంఖ్యను తనిఖీ చేస్తాము: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' మేము సున్నా పొందే వరకు. సున్నా చాలా కాలం పాటు తప్పిపోయినట్లయితే, తాత్కాలికంగా కాష్‌ని రైట్‌త్రూ మోడ్‌కి మార్చడం ద్వారా దీన్ని సృష్టించవచ్చు. అయినప్పటికీ, మా SATA మరియు NVMe SSD శ్రేణుల యొక్క వేగ లక్షణాలను, అలాగే వాటి TBW వనరును పరిగణనలోకి తీసుకుంటే, మీరు కాష్ మోడ్‌ను మార్చకుండానే క్షణాన్ని త్వరగా పట్టుకోగలరు లేదా మీ హార్డ్‌వేర్ దాని మొత్తం వనరులను పూర్తిగా తినేస్తుంది కొన్ని రోజులు. వనరుల పరిమితుల కారణంగా, సిస్టమ్ సూత్రప్రాయంగా, అన్ని సమయాలలో 100% వ్రాత లోడ్‌లో ఉండలేకపోతుంది. మా NVMe SSDలు 100% వ్రాత లోడ్‌లో ఉన్న వనరును పూర్తిగా ఖాళీ చేస్తాయి 3-4 రోజులు. SATA SSDలు రెండు రెట్లు ఎక్కువ కాలం మాత్రమే ఉంటాయి. అందువల్ల, చాలా వరకు లోడ్ పఠనానికి వెళుతుందని మేము ఊహిస్తాము మరియు వ్రాయడానికి సగటున తక్కువ లోడ్‌తో కలిపి చాలా ఎక్కువ కార్యాచరణ యొక్క స్వల్పకాలిక పేలుళ్లను కలిగి ఉన్నాము.
4. మేము సున్నాని పట్టుకున్న (లేదా చేసిన) వెంటనే, మేము <name>.cached <name>.committed అని పేరు మారుస్తాము. పాత <name>.committed తొలగించబడింది.
5. ఐచ్ఛికంగా, కాష్ 100% నిండి ఉంటే, దానిని స్క్రిప్ట్ ద్వారా మళ్లీ సృష్టించవచ్చు, తద్వారా దానిని క్లియర్ చేయవచ్చు. సగం ఖాళీ కాష్‌తో, సిస్టమ్ వ్రాసేటప్పుడు చాలా వేగంగా పని చేస్తుంది.
6. మైగ్రేషన్ థ్రెషోల్డ్‌ను సున్నాకి సెట్ చేయండి: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata ఇది కాష్‌ని ప్రధాన మీడియాకు సమకాలీకరించకుండా తాత్కాలికంగా నిరోధిస్తుంది.
7. కాష్‌లో చాలా మార్పులు పేరుకుపోయే వరకు మేము వేచి ఉంటాము #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' లేదా టైమర్ ఆఫ్ అవుతుంది.
8. మేము మళ్ళీ పునరావృతం చేస్తాము.

వలసల పరిమితితో ఇబ్బందులు ఎందుకు...?విషయం ఏమిటంటే, నిజమైన ఆచరణలో, "యాదృచ్ఛిక" రికార్డింగ్ వాస్తవానికి పూర్తిగా యాదృచ్ఛికం కాదు. మేము 4 కిలోబైట్‌ల పరిమాణం గల సెక్టార్‌కి ఏదైనా వ్రాసినట్లయితే, ఆ తర్వాతి రెండు నిమిషాల్లో అదే లేదా పొరుగున ఉన్న (+- 32K) సెక్టార్‌లలో ఒకదానికి రికార్డ్ చేయబడే అధిక సంభావ్యత ఉంది.

మైగ్రేషన్ థ్రెషోల్డ్‌ని సున్నాకి సెట్ చేయడం ద్వారా, మేము SATA SSDలో రైట్ సింక్రొనైజేషన్‌ను వాయిదా వేస్తాము మరియు కాష్‌లోని ఒక 64K బ్లాక్‌కి అనేక మార్పులను కలుపుతాము. ఇది SATA SSD యొక్క వనరును గణనీయంగా ఆదా చేస్తుంది.

కోడ్ ఎక్కడ..?దురదృష్టవశాత్తూ, రచయిత 100% స్వీయ-బోధన మరియు “గూగుల్” ఆధారిత అభివృద్ధిని అభ్యసిస్తున్నందున, బాష్ స్క్రిప్ట్‌ల అభివృద్ధిలో తనకు తగినంత సామర్థ్యం లేదని భావించాడు, అందువల్ల తన చేతుల్లో నుండి వచ్చే భయంకరమైన కోడ్‌ను ఎవరూ ఉపయోగించకూడదని అతను నమ్ముతాడు. లేకపోతే.

ఈ ఫీల్డ్‌లోని నిపుణులు అవసరమైతే పైన వివరించిన అన్ని తర్కాలను స్వతంత్రంగా వర్ణించగలరని నేను భావిస్తున్నాను మరియు రచయిత ప్రయత్నించినట్లుగా దీన్ని సిస్టమ్‌డ్ సేవగా అందంగా రూపొందించవచ్చు.

ఇటువంటి సాధారణ స్నాప్‌షాట్ రొటేషన్ స్కీమ్ SATA SSDలో నిరంతరం ఒక స్నాప్‌షాట్‌ను పూర్తిగా సమకాలీకరించడానికి అనుమతిస్తుంది, కానీ thin_delta యుటిలిటీని ఉపయోగించి, దాని సృష్టి తర్వాత ఏ బ్లాక్‌లు మార్చబడిందో తెలుసుకోవడానికి మరియు తద్వారా నష్టాన్ని స్థానికీకరించడానికి అనుమతిస్తుంది. ప్రధాన వాల్యూమ్‌లు, రికవరీని చాలా సులభతరం చేస్తాయి.

libvirt/KVMలో TRIM/డిస్కార్డ్

ఎందుకంటే డేటా నిల్వ KVM నడుస్తున్న libvirt కోసం ఉపయోగించబడుతుంది, అప్పుడు మా VM లకు ఖాళీ స్థలాన్ని తీసుకోవడమే కాకుండా, ఇకపై అవసరం లేని వాటిని ఖాళీ చేయడాన్ని కూడా నేర్పడం మంచిది.

వర్చువల్ డిస్క్‌లలో TRIM/DISCARD మద్దతును అనుకరించడం ద్వారా ఇది జరుగుతుంది. దీన్ని చేయడానికి, మీరు కంట్రోలర్ రకాన్ని virtio-scsiకి మార్చాలి మరియు xmlని సవరించాలి.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

అతిథి OSల నుండి ఇటువంటి విస్మరింపులు LVM ద్వారా సరిగ్గా ప్రాసెస్ చేయబడతాయి మరియు బ్లాక్‌లు కాష్‌లో మరియు థిన్ పూల్‌లో సరిగ్గా విడుదల చేయబడతాయి. మా విషయంలో, తదుపరి స్నాప్‌షాట్‌ను తొలగిస్తున్నప్పుడు ఇది ప్రధానంగా ఆలస్యంగా జరుగుతుంది.

BTRFS బ్యాకప్

దీనితో రెడీమేడ్ స్క్రిప్ట్‌లను ఉపయోగించండి తీవ్రమైన జాగ్రత్త మరియు ఒకరి స్వంత పూచీతో. రచయిత ఈ కోడ్‌ను స్వయంగా మరియు తన కోసం ప్రత్యేకంగా వ్రాసాడు. చాలా మంది అనుభవజ్ఞులైన Linux వినియోగదారులు ఇలాంటి సాధనాలను కలిగి ఉన్నారని నేను ఖచ్చితంగా అనుకుంటున్నాను మరియు మరొకరిని కాపీ చేయవలసిన అవసరం లేదు.

బ్యాకప్ పరికరంలో వాల్యూమ్‌ను క్రియేట్ చేద్దాం:

#lvcreate -L 256G --name backup backup

దీన్ని BTRFSలో ఫార్మాట్ చేద్దాం:

#mkfs.btrfs /dev/backup/backup

మౌంట్ పాయింట్లను సృష్టించి, ఫైల్ సిస్టమ్ యొక్క రూట్ ఉపవిభాగాలను మౌంట్ చేద్దాం:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

బ్యాకప్‌ల కోసం డైరెక్టరీలను క్రియేట్ చేద్దాం:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

బ్యాకప్ స్క్రిప్ట్‌ల కోసం డైరెక్టరీని క్రియేట్ చేద్దాం:

#mkdir /root/btrfs-backup

స్క్రిప్ట్‌ని కాపీ చేద్దాం:

చాలా భయానక బాష్ కోడ్. మీ స్వంత పూచీతో ఉపయోగించండి. రచయితకు కోపంతో లేఖలు రాయకండి...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


అది కూడా ఏం చేస్తుంది..?BTRFS స్నాప్‌షాట్‌లను సృష్టించడం మరియు BTRFS పంపడం/స్వీకరించడం ద్వారా వాటిని మరొక FSకి కాపీ చేయడం కోసం సాధారణ ఆదేశాల సమితిని కలిగి ఉంటుంది.

మొదటి ప్రయోగం చాలా పొడవుగా ఉంటుంది, ఎందుకంటే... ప్రారంభంలో, మొత్తం డేటా కాపీ చేయబడుతుంది. తదుపరి లాంచ్‌లు చాలా వేగంగా ఉంటాయి, ఎందుకంటే... మార్పులు మాత్రమే కాపీ చేయబడతాయి.

మేము క్రాన్‌లో ఉంచే మరొక స్క్రిప్ట్:

మరికొన్ని బాష్ కోడ్#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


ఇది ఏమి చేస్తుంది..?బ్యాకప్ FSలో జాబితా చేయబడిన BTRFS వాల్యూమ్‌ల ఇంక్రిమెంటల్ స్నాప్‌షాట్‌లను సృష్టిస్తుంది మరియు సమకాలీకరించబడుతుంది. దీని తర్వాత, ఇది 60 రోజుల క్రితం సృష్టించిన అన్ని చిత్రాలను తొలగిస్తుంది. ప్రారంభించిన తర్వాత, జాబితా చేయబడిన వాల్యూమ్‌ల యొక్క తేదీ స్నాప్‌షాట్‌లు /backup/btrfs/back/remote/ ఉప డైరెక్టరీలలో కనిపిస్తాయి.

కోడ్ అమలు హక్కులను ఇద్దాం:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

దాన్ని తనిఖీ చేసి, క్రాన్‌లో ఉంచుదాం:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVM సన్నని బ్యాకప్

బ్యాకప్ పరికరంలో సన్నని పూల్‌ని క్రియేట్ చేద్దాం:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

ddrescueని ఇన్‌స్టాల్ చేద్దాం, ఎందుకంటే... స్క్రిప్ట్‌లు ఈ సాధనాన్ని ఉపయోగిస్తాయి:

#apt-get install gddrescue

స్క్రిప్ట్‌ల కోసం డైరెక్టరీని క్రియేట్ చేద్దాం:

#mkdir /root/lvm-thin-backup

స్క్రిప్ట్‌లను కాపీ చేద్దాం:

లోపల చాలా బాష్...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


ఇది ఏమి చేస్తుంది...?సన్నని స్నాప్‌షాట్‌లను మానిప్యులేట్ చేయడానికి మరియు ddrescue మరియు blkdiscard ఉపయోగించి thin_delta ద్వారా మరొక బ్లాక్ పరికరానికి అందుకున్న రెండు సన్నని స్నాప్‌షాట్‌ల మధ్య వ్యత్యాసాన్ని సమకాలీకరించడానికి ఆదేశాల సమితిని కలిగి ఉంటుంది.

మేము క్రాన్‌లో ఉంచే మరొక స్క్రిప్ట్:

కొంచెం ఎక్కువ బాష్#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


ఇది ఏమి చేస్తుంది...?జాబితా చేయబడిన సన్నని వాల్యూమ్‌ల బ్యాకప్‌లను సృష్టించడానికి మరియు సమకాలీకరించడానికి మునుపటి స్క్రిప్ట్‌ని ఉపయోగిస్తుంది. స్క్రిప్ట్ జాబితా చేయబడిన వాల్యూమ్‌ల యొక్క క్రియారహిత స్నాప్‌షాట్‌లను వదిలివేస్తుంది, ఇవి చివరి సమకాలీకరణ నుండి మార్పులను ట్రాక్ చేయడానికి అవసరం.

ఈ స్క్రిప్ట్ తప్పనిసరిగా సవరించబడాలి, బ్యాకప్ కాపీలు తయారు చేయవలసిన సన్నని వాల్యూమ్‌ల జాబితాను పేర్కొంటుంది. ఇవ్వబడిన పేర్లు దృష్టాంత ప్రయోజనాల కోసం మాత్రమే. మీరు కోరుకుంటే, మీరు అన్ని వాల్యూమ్‌లను సమకాలీకరించే స్క్రిప్ట్‌ను వ్రాయవచ్చు.

హక్కులు ఇద్దాం:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

దాన్ని తనిఖీ చేసి, క్రాన్‌లో ఉంచుదాం:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

మొదటి ప్రయోగం చాలా పొడవుగా ఉంటుంది, ఎందుకంటే... ఉపయోగించిన ఖాళీ మొత్తాన్ని కాపీ చేయడం ద్వారా సన్నని వాల్యూమ్‌లు పూర్తిగా సమకాలీకరించబడతాయి. LVM థిన్ మెటాడేటాకు ధన్యవాదాలు, వాస్తవానికి ఏ బ్లాక్‌లు వాడుకలో ఉన్నాయో మాకు తెలుసు, కాబట్టి వాస్తవానికి ఉపయోగించిన సన్నని వాల్యూమ్ బ్లాక్‌లు మాత్రమే కాపీ చేయబడతాయి.

తదుపరి పరుగులు LVM థిన్ మెటాడేటా ద్వారా ట్రాకింగ్‌ని మార్చినందుకు డేటాను క్రమంగా కాపీ చేస్తుంది.

ఏమి జరిగిందో చూద్దాం:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


గూడు కట్టుకునే బొమ్మలకు దీనికి సంబంధం ఏమిటి?

చాలా మటుకు, LVM LV లాజికల్ వాల్యూమ్‌లు ఇతర VGల కోసం LVM PV ఫిజికల్ వాల్యూమ్‌లు కావచ్చు. LVM గూడు కట్టుకునే బొమ్మల వలె పునరావృతమవుతుంది. ఇది LVM విపరీతమైన సౌలభ్యాన్ని ఇస్తుంది.

PS

తరువాతి కథనంలో, హోమ్ డెస్క్‌టాప్‌లు, హోమ్ ఇంటర్నెట్ మరియు P2P నెట్‌వర్క్‌లను ఉపయోగించి అనేక ఖండాలలో రిడెండెన్సీతో జియో-డిస్ట్రిబ్యూటెడ్ స్టోరేజ్/vm ​​క్లస్టర్‌ను రూపొందించడానికి మేము అనేక సారూప్య మొబైల్ స్టోరేజ్ సిస్టమ్‌లు/KVMని ఉపయోగించడానికి ప్రయత్నిస్తాము.

మూలం: www.habr.com