Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Z minulého dílu máme v LVM jeden disk o velikosti 8 GB a oddíl video o velikosti 2 GB. Teď přidáme další disk o velikosti 6 GB a oddíl video zvětšíme na 10 GB (tedy na velikost větší, než je velikost největšího PV. Jak již bylo uvedeno minule, LVM řeší distribuci místa transparentně a není třeba se zabývat velikostí jednotlivých PV ve vztahu k logickým oddílům. (Předchozí informace není zcela správná pro zrcadlený oddíl, ale to si vysvětlíme později.) Směrodatné (pro velikost nového oddílu či zvětšení stávájícího) je volné místo ve skupině oddílů, které zjistíme pomocí vgdisplay "jméno skupiny"
.
Začneme tedy vytvořením fyzického oddílu na novém disku:
[root@centos ~]# pvcreate /dev/sdb Physical volume "/dev/sdb" successfully created
A přidáme tento oddíl do skupiny data. K tomu slouží příkaz vgextend
s parametry jména skupiny a diskovým zařízením.
[root@centos ~]# vgextend data /dev/sdb Volume group "data" successfully extended
Nyní už má skupina oddílů data velikost 8+6 = 14 GB, tedy volné místo 12 GB. Výpis z vgdisplay data
to potvrzuje:
[root@centos ~]# vgdisplay data --- Volume group --- VG Name data System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 7 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 13.99 GB PE Size 4.00 MB Total PE 3582 Alloc PE / Size 512 / 2.00 GB Free PE / Size 3070 / 11.99 GB VG UUID 5N1yvF-YMBO-301k-zBIg-ssY1-sLCC-kV8GwA
Zvětšení logického oddílu má na starosti příkaz lvextend
, parametrem je buď nová velikost velikost (--size 10G
), nebo přírůstek (--size +8G
) a samozřejmě také cesta k logickému oddílu, který chceme zvětšit. Konkrétně pro oddíl video z našeho příkladu:
[root@centos ~]# lvextend --size 10G /dev/data/video Extending logical volume video to 10.00 GB Logical volume video successfully resized
Následuje zvětšení systému souborů. Pro změnu velikosti ext3 slouží nástroj resize2fs
a zvětšení lze provést i s připojeným souborových systémem - celé zvětšení oddílu (tedy přidání fyzického oddílu, zvětšení skupiny, zvětšení oddílu i systému souborů) lze provést za běhu systému bez jakéhokoliv dopadu na běžící služby, což je velmi výhodné.
[root@centos ~]# resize2fs /dev/data/video resize2fs 1.39 (29-May-2006) Filesystem at /dev/data/video is mounted on /mnt; on-line resizing required Performing an on-line resize of /dev/data/video to 2621440 (4k) blocks. The filesystem on /dev/data/video is now 2621440 blocks long.
Souborový systém XFS umožňuje pouze zvětšení, a to pomocí prográmku xfs_growfs
. Souborový systém musí být připojený pro zápis.
[root@centos ~]# xfs_growfs /dev/data/video meta-data=/dev/data/video isize=256 agcount=8, agsize=65536 blks = sectsz=512 attr=0 data = bsize=4096 blocks=524288, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 524288 to 2621440
JFS nemá na zvětšení zvláštní nástroj, zvětšuje se pomocí parametrů připojení, což lze též udělat za běhu systému. Pro přehlednost si ukážeme celý postup zvětšení oddílu s JFS i s uvedením velikosti systému souborů:
[root@centos ~]# df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/mapper/data-video 2.0G 388K 2.0G 1% /mnt [root@centos ~]# lvextend --size 10G /dev/data/video Extending logical volume video to 10.00 GB Logical volume video successfully resized [root@centos ~]# mount /mnt -o remount,resize [root@centos ~]# df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/mapper/data-video 10G 1.4M 10G 1% /mnt
ReiserFS má pro zvětšení program resize_reiserfs
. Spuštěný bez parametrů zvětší velikost FS na velikost oddílu.
[root@centos ~]# resize_reiserfs /dev/data/video resize_reiserfs 3.6.19 (2003 www.namesys.com) resize_reiserfs: On-line resizing finished successfully.
Při zvětšování jsme nejprve zvětšili logický oddíl a poté souborový systém s tím, že nástroj pro zvětšení FS si velikost oddílu zjistil sám. Zmenšení je o něco komplikovanější. Nejprve je nutné zmenšit systém souborů (pokud to umožňuje - např. XFS zmenšení vůbec nepodporuje) a poté zmenšit oddíl. Zde je už nutné novou velikost uvádět.
Při zmenšení je třeba dávat pozor, aby logický oddíl nebyl menší, než je velikost souborového systému! Osobně postupuji tak, že souborový systém zmenším na velikost o něco menší než požaduji, poté zmenším oddíl na požadovanou velikost a následně nechám FS zvětšit na velikost oddílu (kterou už si ten příslušný nástroj zjistí sám). Doporučuji mít data ze souborového systému zálohovaná (toto by mělo být pravidlem při jakékoliv manipulaci se souborovým systémem).
V příkladech si ukážeme, jak zmenšit jednotlivé souborové systémy souborů na velikost 5 GB, poté zmenšíme logický oddíl video a nakonec ze skupiny odstraníme fyzický oddíl a tím vlastně i jeden disk.
Ke zmenšení velikosti souborového systému ext3 opět slouží resize2fs
s prvním parametrem uvádejícím cestu k oddílu a dále novou velikostí. Souborový systém nesmí být připojený a před samotným zmenšením je nutné souborový systém zkontrolovat (fsck.ext3 -f /dev/data/video
).
[root@centos ~]# resize2fs /dev/data/video 5G resize2fs 1.39 (29-May-2006) Resizing the filesystem on /dev/data/video to 1310720 (4k) blocks. The filesystem on /dev/data/video is now 1310720 blocks long.
Poznámka z praxe: Často je rychlejší vytvořit nový oddíl (pokud je dostatek místa) o požadované velikosti, data přesunout a starý oddíl zrušit. Kontrola 1TB oddílu (ext3) a následné zmenšení na 600 GB by trvalo déle, než by trval přesun 550 GB dat.
Opět (jako ke zvětšení) k němu slouží nástroj resize_reiserfs
, který je na CentOS 5.2 (v době psaní článku nejnovější) v repozitáři CentOSPlus ve verzi 3.6.19, a při pokusu o zmenšení souborového systému zobrazí varování, že zmenšení je zatím ve fázi testování.
Poznámka nikoliv pod čarou: Red Hat, ze kterého CentOS vychází, oficiálně podporuje pouze souborový systém ext3, neoficiálně lze použít i další právě z repozitáře CentOSPlus s použitím tamního jádra. Právě na tomto systému testuji postupy do této série článků.
ReiserFS tedy zmenšíme pomocí reiserfs_resize
s parametrem -s5G
, který určuje novou velikost. Výpis i s výše zmíněným varováním:
[root@centos ~]# resize_reiserfs -s5G /dev/data/video resize_reiserfs 3.6.19 (2003 www.namesys.com) You are running BETA version of reiserfs shrinker. This version is only for testing or VERY CAREFUL use. Backup of you data is recommended. Do you want to continue? [y/N]:y Processing the tree: 0%....20%....40%....60%....80%....100% nodes processed (moved): int 0 (0), leaves 1 (0), unfm 0 (0), total 1 (0). check for used blocks in truncated region ReiserFS report: blocksize 4096 block count 1310720 (2621440) free blocks 1302469 (2613149) bitmap block count 40 (80) Syncing..done resize_reiserfs: Resizing finished successfully.
XFS a JFS zmenšení nepodporují. Ostatně, zmenšení souborového systému je velice vyjímečná operace a vhodným rozvržením velikostí oddílů se jí lze vyhnout. Jak jsme si ukázali, zvětšení oddílu v LVM je velmi snadné a rychlé. Lze jej tedy provádět průběžně podle potřeby místa
Po zmenšení systému souborů už je možné zmenšit samotný oddíl. Zde je opravdu nutné dávat pozor na novou velikost oddílu, ta nesmí být menší, než je velikost souborového systému.
Ke zmenšení logického oddílu slouží lvreduce
s parametrem -- size
, který udává novou velikost. A samozřejmně také zmenšovaný oddíl:
[root@centos ~]# lvreduce --size 5G /dev/data/video WARNING: Reducing active logical volume to 5.00 GB THIS MAY DESTROY YOUR DATA (filesystem etc.) Do you really want to reduce video? [y/n]: y Reducing logical volume video to 5.00 GB Logical volume video successfully resized
Při odebrání fyzického oddílu (v tomto příkladu celého pevného disku), je nutné, aby byl daný PV prázdný. Pro přesun dat z fyzického oddílu jinam slouží příkaz pvmove
. Lze určit, na které konkrétní fyz. oddíly se mají data přesunout, nebo to nechat na LVM. Budeme odebírat disk /dev/sda
. Přesun je možno přerušit (např. při výpadku napájení apod.), další spuštění pvmove
bude plynule pokračovat v přesunu:
[root@centos ~]# pvmove /dev/sda Detected pvmove in progress for /dev/sda /dev/sda: Moved: 100.0%
Dalším krokem při odebírání fyz. oddílu je zmenšení skupiny oddílů příkazem vgreduce
s parametry jméno skupiny a cesta k fyzickému uddílu:
[root@centos ~]# vgreduce data /dev/sda Removed "/dev/sda" from volume group "data"
Zbývá už jen odstranit fyz. oddíl:
[root@centos ~]# pvremove /dev/sda Labels on physical volume "/dev/sda" successfully wiped
Tímto je odebrání fyzického oddílu hotové. Opět, jako většina operací v LVM, lze odebrat fyzický oddíl za běhu systému. Pokud konstrukce počítače umožnuje připojovat a odpojovat disky za běhu (hot-swap), lze takto jednoduše zvětšit diskový prostor odstraněním malého disku z LVM, jeho fyzickým vyjmutím, vložením většího disku, přidáním do skupiny oddílů a vytvořením nových (nebo zvětšením původních) logických oddílů.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Super článek, měl bych jen 2 poznámky ke zmenšování:
1. To, že data z disku pomocí pvmove a vgreduce přesunu pryč z /dev/sda, ještě neznamená, že tento disk můžu za chodu z mašiny vyrvat. Pokud je to SCSI/SATA/SAS disk, pak se musí ještě udělat:
cat "scsi remove-single-device x y z w" > /proc/scsi/scsi
kde x,y,z,w je SCSI adresa disku. Tímto řeknu jádru, co se právě snažím udělat. Pokud někdo či něco zařízení používá, tento příkaz selže a disk musím v mašině nechat!
2. Ke zmenšování ext3 - pokud jsme již oddíl předtím zmenšili ale už přesně nevíme o kolik, tak je vhodné zjistit si jeho skutečnou velikost (a to né příkazem df -m). Pomůže toto:
[root@dorado /]# dumpe2fs /dev/VolGroup00/LogVol01 | head -40 | grep Block
dumpe2fs 1.39 (29-May-2006)
Block count: 2359296
Block size: 4096
Blocks per group: 32768
Kde:
Block size je velikost bloku v bytech a Block count je počet bloků které FS využívá ... takže v našem případku je velikost filesystému 2359296*4096 bytů což je přesně 9Gb. Takže mohu bezpečně udělat:
lvresize --size 9G /dev/VolGroup00/LogVol01
pvremove
lze již disk fyzicky vyjmout, to rozhodně nejde. Rada ohledně zjištění přesné velikosti ext3 je velmi dobrá. Díky moc za doplnění.
heh, asi spíš echo "...." > ... zajímavý, že já v tom taky pravidelně chybuju :)
Jojo, to je ono. echo tam má bejt. Pardón.
Ahoj,
ano clanek je super. Je tam presne to co jsem vzdy potreboval a musel hledat pres Google. Pochvalen bud autor
Me by spise zajimalo, jesli nemuze mit velikost LVM nejaky spatny vliv na rychlost disku. Mam 3.5T (v ReiserFS) a je to strasne pomale. Ale jen kdyz se poprve prihlasim (po najeti KDE) nebo pri nejakych operacich.
LVM rychlost prakticky neovlivnuje (FS vytvořený nad LVM bude stejně rychlý jako FS přímo nad klasickou partišnou).
To je pravda jen napůl - pokud nepoužíváš snapshoty, tak je to pravda. Pokud ale snapshoty používáš, tak počítej s 10-20x zpomalením diskových operací. Tohle se málo ví, tak si to lidi uvědomte.
…počítej s 10-20x zpomalením diskových operací…To se tak velke zpomaleni projevuje uz s jednim snapshotem? Prijde mi to moc, ale nevyznam se v tom a tak se ptam. Btw nekde jsem slysel, ze LVM je navrzeno jen pro jeden snapshot na LV a pri vyssim poctu snapshotu je to kvuli zpomaleni nepouzitelne, takze by teoreticky nebyl problem ziskat s dostatecnym poctem snapshotu i vetsi zpomaleni nez 20x :).
Nn, nemam to v poli. Mam 3x 1T + 1x 500G nahazene primo do VG a vytvoreny jeden LV. Kdyz potrebuji misto, koupim novy disk a jen "prifouknu" to. Netusim jestli je problem v ReiserFS, mountuji ho s noatime, notail. Ale nekdo mi kdysi rikal, ze se pry musi opatchovat kernel, pokud se pouzivaji velke disky na 2T. Tak nevim. Prijde mi to divny. Mam dost naslapany PC a dost se to vlece. Je ale pravda, ze na tom LVM jsou v podstate jen BD filmy, takze soubory od 4-30G, ale to by snad nemel byt problem...
setkal jsem se s enormnim zpomalenim pri kritickem zaplneni disku. (tj. pod 10%) ext3 byl temer nepouzitelny reiser ale take vyrazne zpomalil.
nemuze to byt timto?
No to by mohlo byt ono. Mam z 3.5T volnych asi 300-200G jen Uz jsem si toho vsiml, kdyz mi dochazelo misto minule, pak jsem dokoupil 2T a o dost se to zrychlilo. Uz cekam na nove 2T disky od WD. Tak uvidime.
Díky za super články! Konečně jsem se dnes (na základě těhle článků) odhodlal překopat svůj domácí server na LVM a musím říct, že je to super .
Ahoj, jake jsou moznosti obnovy dat pri surovem cteni disku sector po sectoru? Obnovit smazany soubor obecne unix filesystemy moc neumoznuji.
Tedy jde mi o situaci: clovek ktery nezalohuje - {disk s LVM} - fs ext3 - si neco smaze a chce obnovit data primo z disku.
U FAT32 a NTFS pokud hned prestane s tim diskem pracovat, tak se pres ruzne nastroje ty data daji obnovit.
Už pod prvním dílem v diskuzi proběhlo, jestli je vhodné mít v jedné VG více disků - protože při poruše jednoho disku z VG ztratíme veškerá data v této VG.
Při vytváření LV je možné specifikovat konkrétní disk, resp. PV, pomocí posledního parametru lvcreate
. To jsem vyzkoušel na VG ze dvou disků a skutečně to tak funguje. Zároveň by LVM metadata měla být na všech discích (PV). Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Nenašel jsem ale možnost, jak vypsat podrobné informace o LV, kde by bylo vidět, na kterých PV její bloky leží - to je první dotaz.
Ptám se hlavně proto, že pvmove
, je možné použít jen v rámci jedné VG (už proto, že názvy zařízení jsou /dev/mapper/VG-LV). Pokud bych tedy kvůli bezpečnosti dat chtěl mít pro každý disk zvláštní VG, přijdu o možnost přesunu oddílu mezi disky. Bude ale možné alespoň přidat nový disk do VG a přesunout data na něj?
jak vypsat podrobné informace o LV, kde by bylo vidět, na kterých PV její bloky leží
lvdisplay --maps
Pokud bych tedy kvůli bezpečnosti dat chtěl mít pro každý disk zvláštní VG
Proč, když píšete:
Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Díky, to jsem neznal.
Proč, když píšete:
Takže při poškození disku nebudou přístupné jen LV, které leží celé, nebo částečně, na tomto disku.
Pravda, nenapsal jsem to úplně logicky. To bylo takové zamyšlení na základě diskuze pod prvním dílem článku:
musim upozornit, ze neni prilis vhodne davat vice disku do jedne VG, nebot pri rozbiti nektereho disku, jsou necitelna i data na ostatnich discich danne VG.
V diskusi se potom snad došlo k tomu, že to není pravda, ale chtěl jsem se ujistit. Myslím, že se v seriálu zatím nezmínila možnost volby PV u příkazu lvcreate
, která s tím souvisí.
Už pod prvním dílem v diskuzi proběhlo, jestli je vhodné mít v jedné VG více disků - protože při poruše jednoho disku z VG ztratíme veškerá data v této VG.
Nevím k čemu se dospělo, ale rozhodně to není pravda. Když vám odejde PV, tak před inicializací VG zavoláte vgreduce --removemissing. Pochopitelně přijdete o ty LV, které byť částečně ležely na ztracených PV, ale zbytek dál normálně funguje.