A rendszerünket, programjainkat, adatainkat alapvetően valamilyen háttértárolón tároljuk. Ezek kezdetekben valamilyen lemezes eszközök voltak, és noha manapság az SSD-kben már nem találkozunk ilyen lemezekkel, ezeknek a háttértáraknak a kezelését még most is lemezkezelésnek nevezzük.
Blokkos eszközök
A Linux lemezkezelés középpontjában a blokkos eszközök állnak. A blokkos eszközök a rendszer olyan adattároló eszközei, amelyek az adatokat blokkokban kezelik. A későbbiek során látni fogjuk, hogy ezek az egyben kezelt adategységek több szinten is megjelennek. Tipikusan ilyen eszközök a merevlemezek, SSD-k, az USB meghajtók. Ezeket a blokkos eszközöket speciális eszközfájlokon keresztül érhetjük el, melyeket a /dev könyvtárban találunk.
A blokkos eszközök kilistázására számos parancs áll rendelkezésünkre. Az egyik közülük az lsblk:
root@server:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1.8G 0 part /boot
└─sda3 8:3 0 18.2G 0 part
└─ubuntu--vg-ubuntu--lv 253:0 0 10G 0 lvm /
sr0 11:0 1 1024M 0 rom
A későbbiek során majd megismerjük a parancsban megjelenő valamennyi információ jelentését, számunkra most csak annyi fontos, hogy két blokkos eszköz van a rendszerben, az sda (disk) és az sr0 (cdrom).
Az fdisk paranccsal még más információt is lekérhetünk:
root@server:~# fdisk -l
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
...
A parancs kimenetén láthatjuk, hogy az adott eszközön 512 byte méretű szektorokban tárolják az információt. A szektor a blokkos eszköz fizikai adattárolási egysége. Felvetődhet a kérdés, hogy mi a különbség a fizikai és a logikai szektorméret között? A válasz most röviden csak annyi, hogy a régebbi merevlemezeken 512 byte-os, míg az újabbakban 4kByte-os szektorokban tárolták az adatokat. A régebbi operációs rendszerek viszont nem tudták kezelni ezt az új szektorméretet, ezért számukra a 4k-s szektorokat logikailag 512 byte-os szektorokra osztották.
A partíciók
Alapok
A szektorok mérete túl kicsi ahhoz, hogy önállóan tudjunk rajtuk fájlokat létrehozni. Valahogy nagyobb egységekbe kell azokat szervezni. A blokkos eszközökön így először partíciókat hozunk létre, melyek fizikailag egymást követő szektorok sorozatából állnak. De fordítva is gondolkodhatunk. Adott egy akár több TB-os fizikai lemezterület. Ha az egészet egyben kezelnénk, akkor olyan helyzet állhatna elő, mint amikor egy irodában mindenki egyetlen légtérben dolgozik, nincsen senki senkitől és semmitől elválasztva. Elképzelhetjük, hogy mennyire rugalmatlan ez a kialakítás. Ennek elkerülésére a teljes tárterületet egymástól független kisebb részekre, azaz partíciókra osztjuk. A rendszeren viszont valahogy tárolni kell, hogy a partíciók hogyan helyezkednek el. Erre több módszer is született.
Az egyik legrégebbi az MBR (Master Boot Rekord) tárolási mód. Az MBR a merevlemez legelején található, és egy úgynevezett partíciós táblában tárolja az eszközön található partíciók adatait. Hogy jobban megértsük, tudnunk kell, hogy a partícióknak alapvetően háromféle típusát különbözteti meg:
- elsődleges (primary) partíciók
- kiterjesztett (extended) partíciók
- logikai (logical) prtíciók
A partíciós táblának négy sora van, melyek mindegyike egy-egy elsődleges vagy kiterjesztett partíciót írhat le. Mivel kiterjesztett partícióból csak 1-nek van értelme, így az elsődleges partíciók száma maximum 3 (ha van kiterjesztett partíció) vagy 4 (ha nincsen kiterjesztett partíció). A kiterjesztett partíció logikai partíciókra osztható fel, de ezeknek az adatai már nem a partíciós táblában vannak tárolva.
Az MBR-t meghaladta az idő, számos korláttal rendelkezik. A partíciók korlátozott száma és mérete (max. 2 TB) és az indítókód túlságos egyszerűsége mellett a redundancia hiánya is gondot jelent, vagyis ha megsérül a partíciós tábla, az egész rendszer veszélybe kerül.
Egy sokkal korszerűbb módja a partíciók leírásának a GPT (GUID Partition Table). Itt minden egyes partícióhoz egy GUID-t (Globally Unique Identifier) rendelnek, amely egy 128 bites egyedi azonosító. A GPT minden bejegyzése egy partíciót ír le részletesen, és ezeknek a bejegyzéseknek a száma nincsen korlátozva. Egy partíció mérete a millió terrabájtot is elérheti, és mind az indítókódban, mind a partíciós táblában redundanciával biztosítja a megbízhatóságot.
Bárhogyan is tároljuk, a lemezkezelés első lépése, hogy a blokkos eszközön ki kell alakítanunk a partíciókat. Erre parancssoros felülete a régebbi fdisk, vagy az újabb, több opcióval rendelkező parted parancsot használhatjuk.
Az fdisk program
Ahhoz, hogy különösebb kockázat nélkül kezelhessük a partíciókat, adjunk a géphez egy új merevlemezt (virtuális környezetben ez elég egyszerű), és ezen az eszközön próbáljuk ki a particionálást. Az fdisk futtatásához meg kell adnunk azt az eszközt, amelyen a partíciókat kezelni szeretnénk. Legyen ez most az sdb:
root@server:~# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x384373f2.
Command (m for help): m
Help:
DOS (MBR)
a toggle a bootable flag
b edit nested BSD disklabel
c toggle the dos compatibility flag
Generic
d delete a partition
F list free unpartitioned space
l list known partition types
n add a new partition
p print the partition table
t change a partition type
v verify the partition table
i print information about a partition
Misc
m print this menu
u change display/entry units
x extra functionality (experts only)
Script
I load disk layout from sfdisk script file
O dump disk layout to sfdisk script file
Save & Exit
w write table to disk and exit
q quit without saving changes
Create a new label
g create a new empty GPT partition table
G create a new empty SGI (IRIX) partition table
o create a new empty DOS partition table
s create a new empty Sun partition table
Az írás terjedelme nem teszi lehetővé a program részletes ismertetését. Nézzük meg csak azt, milyen lépésekben hozhatunk létre egy 10GB méretű elsődleges partíciót: Az n (add a new partition) menüpont választása után megadjuk, hogy elsődleges partíciót akarunk létrehozni (p – primary) 1-es sorszámmal és 2048-as első szektorral, +10GB-os mérettel. Végül változtatásokat kiírjuk a lemezre (w – write table to disk and exit).
Command (m for help): p
Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcd5e782f
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-41943039, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-41943039, default 41943039): +10GB
Created a new partition 1 of type 'Linux' and of size 9.3 GiB.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
A parted program
A parted program használata nem ilyen egyértelmű, de sokkal több lehetőséget ad. Használhatjuk interaktív módban és parancssorosan is, és lehetőség van partíciók létrehozás és törlése mellett, méretük megváltoztatására is.
A használatából csak annyit nézzünk meg, hogyan kell a korábban létrehozott 10GB-os partíció után egy új 5GB-os partíciót létrehozni:
root@server:~# parted /dev/sdb
GNU Parted 3.4
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdb: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 10.0GB 10.0GB primary
(parted) mkpart primary 10GB 15GB
(parted) print
Model: VMware, VMware Virtual S (scsi)
Disk /dev/sdb: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 10.0GB 10.0GB primary
2 10.0GB 15.0GB 4999MB primary lba
(parted) quit
Látható, a print paranccsal jelenítjük meg partíciós táblát, az mkpart paranccsal hozzuk létre az új 5GB-os elsődleges partíciót 10GB-os határtól kezdve.
Fontos tudni, hogy habár a parancsok használatakor lehetőségünk van a partíciók típusának (ez nem a primary és az extended!) a megadását, ez nem jelenti azt, hogy ilyen típusú fájlrendszerek létre is jönnének automatikusan. Ez csupán jelzi a rendszer számára, hogy milyen jellegű az adott partíció.
A partíciók kilistázása
Nézzünk meg még egy lehetőséget a partíciók listázására:
root@server:~# cat /proc/partitions
major minor #blocks name
11 0 1929660 sr0
8 0 20971520 sda
8 1 1024 sda1
8 2 1857536 sda2
8 3 19110912 sda3
8 16 20971520 sdb
8 17 9765888 sdb1
8 18 4881408 sdb2
253 0 10485760 dm-0
Ez a lista számunkra azért érdekes, mert tartalmazza a major és a minor számokat, melyek a Linux-ban az egyes eszközöket azonosítják. A major számmal az eszköz csoportját, míg a minor szám a csoporton belül azonosítja az eszközt. A Linux-on belül minden eszöznek, így a partícióknak is egyedi major-minor azonosító számpárja van. A listából még kiolvasható a partíció neve és blokkokban a mérete. (Az sr1 egy DVD-ROM, míg a dm-0 egy logikai blokk-eszköz, mely az LVM-hez (Logical Volume Manager) szükséges. Erről később majd még szó lesz.)
Javasolt partíciók
Feltehetjük magunknak a kérdést, hogy miért osszuk fel a teljes tárolónkat több partícióra, miért ne csak egyetlen nagyot használjunk? A válaszhoz képzeljük el, hogy otthon nem lennének a lakásnak különböző helységei, minden egy nagy tér lenne, és mindenki mindenkivel közösködve élné az életét. A Linux rendszerünkre ezt lefordítva mi lenne, ha a felhasználók home könyvtárai és a rendszer ugyanazon a partíción lenne? Ha valamelyik felhasználó olyan mennyiségű adatot másolna a könyvtárába (mert nem kapcsoltuk be a kvótát), hogy elfogy az összes szabad hely? A rendszer indulása is problémás lenne. De ugyanígy beszélhetnénk a naplóállományok méretének kontrollálatlan növekedéséről. Egy szó mint száz, mindig érdemes a teljes tárolóterületet partíciókra osztani. A mai Linux disztribúciók telepítéskor ezt már automatikusan megteszik, de ha speciális feladatokra építünk egy-egy szervert, akkor célszerű ezt a folyamatot a saját kezünkbe venni.
Az egyes disztribúciók mindig javaslatot tesznek a szerintük ajánlott partíciós felosztásra, de felhívják a figyelmet, hogy ez nagyban függ a felhasználás jellegétől. Általános elveket azonban alkalmazhatunk. Általában 3 partíciót mindig érdemes létrehozni:
- virtuális memória (swap): A modern operációs rendszerek a fizikai memóriát virtuális memóriával egészítik ki, melynek mérete a RAM 50-100%.
- gyökérkönyvtár (root): A gyökérkönyvtárban van telepítve a teljes Linux. Bizonyos részeit szükség esetén ki lehet helyezni más partíciókra. Kiindulásként az adott disztribúció dokumentációjában ajánlott mérettel dolgozhatunk, de soha nem a minimumra állítsuk be.
- felhasználói könyvtárak (home): Itt kerülnek tárolásra a felhasználók könyvtárai. Fontos, hogy kvótát állítsunk be, hiszen valahogy korlátozi kell a felhasználók tárhelyigényét. Azért is fontos ennek a könyvtárnak külön partíción történő elhelyezése, mert így sokkal könnyebb biztonsági mentést készíteni ezekről az adatokról, illetve a rendszer újratelepítésekor is könnyen megoldható, hogy a felhasználók adatai ne kerüljenek veszélybe.
Logikai fájlrendszer kialakítása
Alapok
A partíciók önmagukban csak a partíciós táblázat által leírt egymástól független használatra kijelölt fizikai terület, ahol valamilyen típusú adatokat akarunk tárolni. Az adatok viszont nem csak tárolni kell, hanem azokat el is kell tudnunk érni, így szükség van egy (vagy több) adminisztrációs területre és egy logikára, amely ezen feladatok mögött állnak. A logikai fájlrendszer kialakításával éppen ezt érjük el. Amennyiben egy partíción létrehozzunk egy fájlrendszert, akkor már a kötet (volume) elnevezést használjuk rá.
A Linux (és a különböző más operációs rendszerek) fejlődése során a különböző fájlrendszereknek is egyre korszerűbb, nagyobb tudású verzióit fejlesztették ki. Mivel egy adott operációs rendszer más rendszerek által kezelt adattárolókról is el kell érje az adatokat (gondolhatunk itt az ugyanazon háttértárolóra telepített különböző operációs rendszerekre, vagy akár a hordozható adattárolókra), felmerülhet a kérdés, hogy egy operációs rendszer képes-e egy másik által létrehozott logikai fájlrendszert kezelni (írni, olvasni). Szerencsére ma már széleskörűen képesek egymás rendszereit használni a virtuális fájlrendszer használatával.
A virtuális fájlrendszer absztrakció réteget biztosít az operációs rendszer és a fizikai fájlrendszerek között, ami lehetővé teszi az egységes fájlkezelési műveleteket, függetlenül attól, hogy a fájlrendszer FAT, NTFS, ext4 vagy más típusú.
Fogalmak
Ismerjünk meg pár, a fájlrendszerek tulajdonságainak leírásához használt fogalmat:
- metadata: A fájlrendszerek célja az adatok tárolása, elérése, szervezése. Ehhez pótlólagos információk tárolására van szükség. (Gondoljunk csak egy könyv tartalom- vagy ábrajegyzékére, szószedetére.) Ezen feladatok ellátásához szükséges adatokat egységesen meta-adatoknak (metadata) nevezzük. Amikor egy fájlrendszer teljesítményéről beszélünk, általában ezeknek a metadatoknak, és a mögöttük álló logika hatékonyságára gondolunk. Nagyon fontos, hogy ezeket a metaadatokat biztonságosan tároljuk, hiszen amennyiben megsérülnek, az adataink is elérhetetlenné válhatnak.
- inode: Az adatokat fájlokban tároljuk. Ezekről a fájlokról az inode-okban tárolunk olyan információkat, mint a fájl egyedi azonosítója, neve, mérete, tulajdonosa, mely adatblokkokban található meg a tárolóeszközön, valamint olyan időbélyegek, mint létrehozásának, módosításának, hozzáférésének időpontjai.
- journal: A journal (naplózás) a fájlrendszerek egy olyan szolgáltatása, amelyen keresztül a rendszer egy journal nevű adatszerkezetben rögzíti a fájlrendszeren végzett, illetve egy adott művelet miatt elvégezni tervezett műveleteket. Ezáltal ha bármilyen fájlművelet megszakad, könnyen nyomon követhető a már végrehajtott műveletek, és lehetőség van az eredeti helyzet helyreállítására, vagy a művelet folytatására, nagymértékben megnövelve ezzel a fájlrendszer biztonságát.
Fájlrendszerek típusai
Nézzük át a Linux által használt néhány híresebb fájlrendszereket:
- Ext2: (Second Extended File System) Ugyan mára már elavult fájlrendszer (eLődje az Extended File System, melyet 1992-ben vezették be), de meg kell emlékeznünk róla, mivel az egyik legnépzserrűbb fájlrendszer volt hosszú időn keresztül. Használata a Linux kezdeti korszakára nyúlt vissza 1993-as bevezetésével. Tulajdonságai közé tartozott az inode alapú struktúra, a blokkos adattárolás, a hard-linkek támogatása. Sajnos még nem tartalmazott naplózást, nem nyújtott adatintegritás ellenőrzést, így egy rendszerleállás könnyen adatvesztést eredményezhetett. Bevezettek mellé egy e2fsck nevű programot, mellyel ezekben a helyzetekben lehetett a fájlrendszer hibáit megkeresni, és amennyiben lehetséges volt, kijavítani.
- Ext3 (Third Extended File System): Az Ext3-at közvetlenül az Ext2-ből fejlesztették ki úgy, hogy megvalósították benne a naplózást, így drasztikusan csökkent a fájlrendszer meghibásodásának az esélye. Mivel elődje az Ext2 volt, nagyon könnyen lehetett frissíteni rá. (Míg egy Ext2 → XFS migrálást már jóval bonyolultabb volt megvalósítani.) 2001-es bevezetésével gyakorlatilag azonnal leváltotta elődjét.
- Ext4 (Fourth Extended File System): A fejlesztés nem állt le, és 2006-ban bevezették az Ext4-et, amely jelentős előrelépést jelentett a nagyméretű partíciók és fájlok kezelésében, jobb teljesítményt nyújtott a párhuzamos műveletek támogatásával, valamint továbbfejlesztették a naplózási funkcióit. Néhány Btrfs funkciót is beépítettek (pl. kiterjesztett attribútumok, tömörítés), így ezek használatához nem kellett teljesen áttérni a Btrfs-re. Természetesen visszafele kompatibilis az Ext2-vel és az Ext3-mal. Még ma is sok rendszernek ez az alapételmezett logikai fájlrendszere.
- XFS (Extended File System): Az XFS 1993-ban a Silicon Graphics által különösen nagy méretű partíciók és fájlok támogatására lett kifejlesztve. Lehetőséget az adatok integritásának az ellenőrzésére, valamint a pillanatfelvételek készítésére, melyek alkalmasak a rendszer-helyreállítások végrehajtására. Nagy teljesítményű naplózási szolgáltatásokat nyújt.
- Btrfs (B-tree fájlrendszer): A Btrfs közvetlenül a Linux-hoz lett tervezve 2009-ben, célja az adatintegritás, a skálázhatóság, a megbízhatóság és a könnyű kezelhetőség biztosítása. Olyan specialitásokkal rendelkezik, mint például ha módosítani kell egy fájlt, akkor ezek a módosítások nem közvetlenül azokon a blokkokon hajtódnak végre, ahol a fájl eredetileg tárolásra került, hanem egy másolaton, vagyis új adatblokkokban, és csak a művelet sikeres befejeztekor véglegesítik azt. Ezzel lehetővé teszik a korábbi állapotok egyszerű és gyors visszaállítását (snapshotok készítése). Ellenőrző összegek és akár futás közbeni önellenőrzések használatával biztosítja az adatintegritás megőrzését. Lehetőséget ad az adatok automatikus tömörítésére, beépített RAID támogatással rendelkezik, és támogatja az alkötetek használatát.
- ZFS (ZettaByte File System): A ZFS-t kifejezetten nagy teljesítményű adattárolásra és adatvédelemre fejlesztette ki 2005-ben a Sun Microsystems. Nagy hangsúlyt fektet az adatintegritásra és a megbízhatóságra, az automatikus hibajavításra. A pillanatképeken keresztül támogatja korábbi állapotok visszaállítását, vagy egy állapot alapján a rendszer klónozását. Több lemezegység között RAID funkciókat valósít meg, a beépített tömörítési algoritmusok segítségével pedig hatékonyan kezeli a tárterületeket. Olyan integrált eszközöket tartalmaz, melyekkel például dinamikusan képes a fájlrendszer méretének módosítására vagy kiterjesztésére más merevlemezekre. Eredetileg csak licenszelve lehetett használni, de a Common Development and Distribution License (CDDL) alatt elérhetővé vált a Linux alatt. (Bár a legtöbb disztribúciónál külön kell telepíteni, nincsen a rendszerbe építve.) Az OpenZFS projekt aktívan fejleszti.
Természetesen ez csak pár fájlrendszer, sok más is kifejlesztésre került. Térjünk át most arra, hogy az előző lépésben létrehozott partíciókon hogyan hozunk létre fájlrendszereket. Mivel ebben az írásban alapvetően az Ubuntu disztribúcióval dolgozunk, az Ubuntu alapértelmezett Ext4-es fájlrendszerét fogjuk használni.
Fájlrendszer létrehozása
A fájlrendszer kialakítására szolgáló parancs az mkfs, használata igen egyszerű: Írjuk be a parancssorba az mkfs. karaktersorozatot, majd 2x nyomjuk meg a TAB-ot, így megkapjuk, hogy a rendszerünk milyen fájlrendszerek létrehozását támogatja.
root@server:~# mkfs.
mkfs.bfs mkfs.cramfs mkfs.ext3 mkfs.minix mkfs.xfs
mkfs.btrfs mkfs.ext2 mkfs.ext4 mkfs.ntfs
A megfelelő formátumnak megfelelő parancs kiválasztása után már csak a partíciónk eszközét kell megadni. Készítsünk ext4-es fájlrendszert a /dev/sdb1 partíción:
root@server:~# mkfs.ext4 /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 2441472 4k blocks and 610800 inodes
Filesystem UUID: 4699aab6-d909-4ba7-8647-19aa6809cd12
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
A parancs sikeres futtatásával a partícióból kötetet készítettünk. A parancs kimenetéből a következő információkat olvashatjuk ki: A fájlrendszert létrehozó program verziója (1.46.5). A partíción összesen 2441472 db. 4kbyte-os blokk jött létre összesen 610800 inode bejegyzéssel. Az UUID a fájlrendszer azonosítója. Fontos, hogy UUID csak akkor van egy partícióhoz (vagy RAID esetén egy lemezhez) rendelve, ha már létrehoztunk rajta egy fájlrendszert. Alatta a szuperblokk-ok helye van felsorolva. (A szuperblokkokban a fájlrendszer kritikus információi kerülnek redundánsan eltárolásra. Ilyen információk például az inode tábla mérete és helye, a szabad inode szám, a szabad blokkok száma, a blokkméret, a fájlrendszer állapota, különböző időbélyegek, stb.) A parancs kimenet még jelzi, hogy sikeresen elkészítette a blokkcsoport és az inode táblák-at. Az ext4 a blokkokat csoportosítva kezeli, melynek előnye abból adódik, hogy minden csoportban a blokkok közel vannak egymáshoz, így hatékonyabb blokk-foglalást, blokk-felszabadítást, blokk-hozzáférést lehet elérni, és a fregmentáció mértékére is kedvezően hat. Korábban már olvashattuk, hogy mi az inode feladata, az inode tábla ezeket az információkat tartalmazza. Ezeket a táblákat a megbízhatóság érdekében több példányban is tárolja a rendszer. Az utolsó sor jelzi, hogy szuperblokkok és a naplózási információk kiírásra kerültek.
Fájlrendszer információinak lekérdezése
A létrehozott fájlrendszerünkről a későbbiekben is lekérhetők ezek az információk a dumpe2fs paranccsal. A parancs futtatásához a kötetet le kell csatolnunk (a következő fejezetben fogunk a kötetek csatolásával foglalkozni), ha valaki eddig ebben a sorrendben végezte el a műveleteket, az sdb1 kötet még nincsen felcsatolva. Annak érdekében, hogy a parancs helyes információkat írjon ki, érdemes előtte a fájlrendszer esetleges hibáit kijavítani az e2fsck paranccsal.
root@server:~# e2fsck /dev/sdb1
e2fsck 1.46.5 (30-Dec-2021)
/dev/sdb1: clean, 11/610800 files, 63958/2441472 blocks
A dumpe2fs nagyon sok információt ír ki. Az alábbi példában csak az első pár sort jelenítettük meg:
root@server:~# dumpe2fs /dev/sdb1
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 4699aab6-d909-4ba7-8647-19aa6809cd12
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
...
Ha konkrét információra vagyunk kíváncsiak, akkor azt le tudjuk szűrni. Például ha a fájlrendszer készítésének dátumára vagyunk kíváncsiak:
root@server:~# dumpe2fs /dev/sdb1 | grep created
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem created: Wed Jul 5 15:09:05 2023
A parancs kimenete minden blokkcsoportról is tartalmaz információ. Egy adott blokkcsoport információi így jeleníthetők meg: (A grep -A 8 kapcsolója azt jelenti, hogy a találat után még 8 sort jelenítsen meg.)
root@server:~# dumpe2fs /dev/sdb1 | grep -A 8 "Group 0"
dumpe2fs 1.46.5 (30-Dec-2021)
Group 0: (Blocks 0-32767) csum 0x30b8
Primary superblock at 0, Group descriptors at 1-2
Reserved GDT blocks at 3-1026
Block bitmap at 1027 (+1027), csum 0x5b328108
Inode bitmap at 1043 (+1043), csum 0xce791993
Inode table at 1059-1567 (+1059)
23559 free blocks, 8133 free inodes, 2 directories, 8133 unused inodes
Free blocks: 9209-32767
Free inodes: 12-8144
A parancs kimenet az eddigiek szerint részben már érthető. Számunkra itt a Block bitmap jelentése az érdekes. A block bitmap tartalmazza, hogy melyik blokk szabad illetve foglalt az eszközön. Az inode bitmap ugyan ez az inode-okra nézve.
Fájlrendszer létrehozása lemezképen
Meg kell jegyeznünk, hogy fájlrendszert nem csak partíción, hanem egy lemezképen is létre tudunk hozni. Ennek módja a következő:
Először a dd paranccsal a /dev/zero eszközből olvasva létrehozunk egy lemezképet. A mérete legyen 100MB. A /dev/zero eszköz egy végtelen hosszú 0 byte-okkal teleírt eszközt szimulál. Ebből másol a dd parancs 100 db. 1 MB-os blokkot a képfájlba:
root@server:~# dd if=/dev/zero of=filesystem.img bs=1M count=10
Ezután hozzuk rajta létre az ext4 fájlrendszert a korábban látott módon:
root@server:~# mkfs.ext4 filesystem.img
Most már ennek a lemezképnek is lekérdezhetjük az információit:
root@server:~# dumpe2fs filesystem.img
Kötetek manuális felcsatolása, lecsatolása
Ahhoz, hogy az előző szakaszban létrehozott kötetet használni tudjuk, fel kell azt csatolni az operációs rendszer könyvtárstruktúrájába. Először létre kell hoznunk azt a könyvtárat, amelybe becsatoljuk, majd elvégezhetjük a műveletet a mount paranccsal:
root@server:~# mkdir /mnt/adatok1
root@server:~# mount /dev/sdb1 /mnt/adatok1
Listázzuk ki, hogy milyen kötetek vannak már felcsatolva. Ehhez kapcsolók nélkül kell a mount parancsot kiadnunk:
root@server:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1927152k,nr_inodes=481788,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=397092k,mode=755,inode64)
/dev/mapper/ubuntu--vg-ubuntu--lv on / type ext4 (rw,relatime)
...
Nem csoda, ha meglepődünk a lista hosszúságán. Itt juthat eszünkbe, amit talán már sok helyen olvashattunk, hogy “A Linux-ban minden egy fájl…”. Ennek a mondat szakszerűbben úgy hangzik, hogy a Linux-ban minden egy fájlon keresztül érhető el. Ha jobban megnézzük az egyes sorokat, akkor nem csak ext4 típusú fájlrendszereket látunk felcsatolva, hanem olyan típusokat olvashatunk, mint sysfs, proc, devtmpfs, devpts, tmpfs, securityfs és így tovább. Természetesen az ext4 is ott van köztük. A különböző típusú fájlrendszerek speciális feladatokat látnak el. A procfs például nem adatokat tárol, hanem szöveges fájlban tárolt adatok formájában mutat meg olyan információkat, mint például a CPU tulajdonságai (/proc/cpuinfo), a memóriahasználattal kapcsolatos információk (/proc/meminfo), vagy a kl beállításait és paramétereit (/proc/kernel). A gépünkben használt CPU tulajdonságai így egy egyszerű cat paranccsal megjeleníthetők:
root@server:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 140
model name : 11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz
stepping : 1
microcode : 0xffffffff
cpu MHz : 3110.402
cache size : 8192 KB
...
De térjünk vissza eredeti témánkhoz. Listázzuk ki csak az ext4 típusúakat. Ehhez a mount parancs -t kapcsolóját használhatjuk. Láthatjuk az imént felcsatolt kötetet.
root@server:~# mount -t ext4
/dev/mapper/ubuntu--vg-ubuntu--lv on / type ext4 (rw,relatime)
/dev/sda2 on /boot type ext4 (rw,relatime)
/dev/sdb1 on /mnt/adatok1 type ext4 (rw,relatime)
A kötetet lecsatolni az umount paranccsal kell. Ilyenkor a rajta található adatok természetesen nem vesznek el, de nem lesznek elérhetőek a fájlkezelő művelettel. Sok esetben, ha ellenőrzünk vagy hibát javítunk egy fájlrendszeren, először le kell csatolni azt.
root@server:~# umount /dev/sdb1
A lecsatolás történhet a csatolási könyvtár megadásával is:
root@server:~# umount /mnt/adatok1
Ha csak olvasható módban szeretnénk a kötetet felcsatolni, használjuk a -r kapcsolót. Próbáljunk egy így felcsatolt köteten egy új fájlt létrehozni, az üzenetből látható, hogy nem sikerül.
root@server:~# mount -t /dev/sdb1 /mnt/adatok1
root@server:~# touch /mnt/adatok1/adat.txt
touch: cannot touch '/mnt/adatok1/adat.txt': Read-only file system
Felmerülhet a kérdés, hogy lehet-e egy kötetet több helyre is becsatolni? A válasz igen, de jobb ha nem. Hogy is van ez? Ha azt akarjuk, hogy ugyanaz a kötet több helyről is elérhető legyen, akkor vagy a -R kapcsolóval csatoljuk a gyökérkönyvtárát az új helyre, vagy szimbolikus linkeket hozzunk létre hozzá. (A rendszer megengedi az újbóli felcsatolást, de ez bizonyos esetekben adatvesztéssel járhat, így ne használjuk.) Ha például az előző /mnt/adatok1 könyvtár tartalmát a /mnt/adatok2-n és a /mnt/adatok3-on keresztül is el akarjuk érni, akkor ezekkel a lehetőségekkel éljünk:
root@server:~# mkdir /mnt/adatok2
root@server:~# mount -R /mnt/adatok1 /mnt/adatok2
root@server:~# ln -s /mnt/adatok1 /mnt/adatok3
Látható, itt már nem a kötettel dolgozunk, csak azzal a könyvtárral, amelyikbe eredetileg felcsatoltuk.
Lehetőségünk van arra is, hogy az adatok1 könyvtárat csak olvasható módon csatoljuk fel az adatok2-be. Így az adatok1 könyvtáron keresztül írható/olvasható a fájlrendszer, míg az adatok2-n keresztül csak olvasható.
A felcsatolt kötetek automatikusan megjelennek a /etc/mtab fájlban. A mount az mtab-ba úgy jegyzi fel a műveletet, mintha magát az sdb1 eszközt csatoltuk volna fel másodszor is.
root@server:~# cat /etc/mtab | grep sdb1
/dev/sdb1 /mnt/adatok1 ext4 ro,relatime 0 0
/dev/sdb1 /mnt/adatok2 ext4 ro,relatime 0 0
Amennyiben lecsatoláskor az eszközt adjuk meg (umount /dev/sdb1), akkor az utoljára felcsatolt kerül először lecsatolásra. A csatolási könyvtár megadásával persze tetszőleges sorrendben tudjuk a műveletet végrehajtani.
Térjünk vissza a felcsatoláshoz. A mount parancs megpróbálja automatikusan megállapítani a fájlrendszer típusát (emlékezzünk vissza, hogy a partíciók létrehozásakor is explicit megadtuk), de ezt mi is előírhatjuk a -t kapcsolóval. Természetesen csak a valóságos típust írhatjuk be. Például egy ext4-es fájlrendszert nem lehet ext3-ként becsatolni:
root@server:~# mount -t ext3 /dev/sdb1 /mnt/adatok1
mount: /mnt/adatok1: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
Ebben a példában fordítva lehetne (persze csak ha elkészítenénk egy ext3 típusút), mivel az ext4 felülről kompatibilis az ext3-mal.
Kötetek automatikus felcsatolása (/etc/fstab)
Ha újraindítjuk a rendszerünket, azt tapasztaljuk, hogy bizonyos kötetek automatikusan felcsatolásra kerülnek, bizonyosak nem. Az általunk létrehozott /dev/sdb1 nem. Hogyan lehetne elérni, hogy minden rendszerinduláskor megjelenjen a könyvtárstruktúrában. Erre való a /etc/fstab állomány. Ez a fájl tartalmazza azokat a köteteket, melyek rendszerinduláskor automatikusan felcsatolhat a Linux. Minden sor egy kötet felcsatolásának módját írja elő. Nézzünk meg egy példát:
root@server:~# cat /etc/fstab
/dev/sda1 / ext4 defaults 0 1
/dev/sdb1 /mnt/adatok1 ext4 defaults 0 2
Ez a minta fstab 2 kötet automatikus felcsatolását írja elő: A /dev/sda1 a gyökérkönyvtárba, míg a /dev/sda2 a /home könyvtár alá. Mindkettő ext4 típusú, és az alapértelmezett opciókkal kerülnek felcsatolásra. (Ezekről mindjárt részletesen szó lesz.) Az utolsó két szám jelentése a következő: Az első előírja, hogy a fájlrendszerről a dump parancs készítsen-e automatikus mentést. (Ez manapság szinte mindig 0, mert a korszerű rendszerek már nem a dump-ot használják biztonsági mentésként.) Az utolsó szám neve a pass. Ez előírja, hogy a fájlrendszer automatikusan leellenőrzésre kerüljön-e rendszerindításkor. Ha az értéke 0, akkor nem lesz leellenőrizve, ha nem 0, akkor igen. A nem 0 számok az ellenőrzés sorrendjét jelölik, vagyis először az 1-es sorszámú fájlrendszerek kerülnek ellenőrzésre, azután a 2-es sorszámúak, és így tovább. Ez a sorrend azért van, mert bizonyos fájlrendszerek ellenőrzésének sikeres volta függ más fájlrendszerek ellenőrzésétől.
Mit jelentenek az opciók? A mount parancsot a következő, gyakrabban használt opciókkal egészíthetjük ki a -o kapcsoló után vesszővel elválasztva.
- auto: A kötetet automatikusan fel kell csatolni
- noauto: A kötetet nem kell automatikusan felcsatolni
- nouser: Csak root jogosultsággal lehet felcsatolni.
- user: Minden felhasználó fel tudja csatolni
- exec: A kötetről engedélyezett a végrehajtható fájlok futtatása
- noexec: A kötetről nem engedélyezett a végrehajtható fájlok futtatása
- ro: A kötet csak olvasható módon kerül felcsatolásra
- rw: A kötet írhat/olvasható módon kerül felcsatolásra
- sync: A ki-/bemeneti műveletek szinkronizált módon kerülnek végrehajtásra
- async: A ki-/bemeneti műveletek aszinkron módon kerülnek végrehajtásra
A következő példa a /dev/sdb1 számára azt írja elő, hogy csak olvasható módon lehessen felcsatolni úgy, hogy ne lehessen róla végrehajtani programokat vagy szkripteket:
/dev/sda2 /home ext4 noexec,ro 0 2
Ugyanezt parancssorból így érjük el:
mount -t ext4 -o noexec,ro /dev/sdb1 /mnt/adatok1
Láthatjuk, van olyan opció, amit kapcsolóval is megadhatunk, és opcióként a -o kapcsoló után. (Például a -r és a -o ro ugyanazt a csak olvasható csatolást jelenti.)
Mit jelent az automatikus vagy nem automatikus felcsatolás? A noauto opcióval rendelkező fájlrendszerek a rendszerinduláskor nem fognak automatikusan felcsatlakozni, ezeket nekünk kell manuálisan megtennünk. (Hiába szerepelnek az fstab-ban.) Ezen felül, ha kiadjuk a mount -a parancsot, akkor a parancs minden olyan fájlrendszert felcsatol, amelyek az fstab-ban felsorolásra kerültek, és rendelkeznek az auto opcióval, míg a noauto opcióval rendelkezőket kihagyja.
A szinkronizált mód azt jelenti, hogy a rendszer az írási műveleteket azonnal végrehajtja az eszközön, és meg is várja, hogy az adatok kiíródjanak, vagyis olvasáskor mindig érvényes adatok kerülnek a folyamatokhoz. Aszinkron mód esetében az írás a háttérben történik, miközben a rendszer fut tovább, és lehet, hogy még régi adatokat olvas vissza.
Feltehetjük azt a kérdést, hogy minek szerepeltessünk az fstab-ban egy olyan csatolást, amely a noauto opcióval van ellátva, vagyis a rendszer indulásakor nem kerül automatikusan felcsatolásra? Ez azért van, mert a mount parancsot lehet úgy használni, hogy nem adjuk meg azt a könyvtárat. Ilyenkor az fstab-ból nézi meg a parancs, hogy melyik könyvtárba csatolja be.
Tegyük be az fstab-ba a /dev/sdb1 csatolását. Indítsuk újra a rendszert, és nézzük meg, hogy automatikusan felcsatolódott-e. (Vigyázzunk arra, hogy ha bármilyen hibát vétünk (például kihagyjuk a fájlrendszer típusának a megadását), a rendszer indulása megakad.)
/dev/sdb1 /mnt/adatok1 ext4 defaults 0 1
Ha most lecsatoljuk az eszközt, akkor már elég a monut /dev/sdb1 a visszacsatolásához, hiszen az fstab-ból látja, hogy melyik könyvtár van hozzárendelve.
A korábban elkészített filesystem.img állományunkat is ilyen egyszerű becsatolni egy könyvtárba.
root@server:~# mount /root/filesystem.img /mnt/img
Természetesen nem csak a saját magunk által készített fájlokat tudjuk felcsatolni. Töltsük le az Ubuntu mini ISO állományát, és csatoljuk be a rendszerünkbe. A mount parancs jelzi, hogy az iso állomány csak olvasható.
root@server:~# wget https://cdimage.ubuntu.com/ubuntu-mini-iso/daily-live/20230705/mantic-mini-iso-amd64.iso
root@server:~# mount /root/mantic-mini-iso-amd64.iso /mnt/miniiso
mount: /mnt/miniiso: WARNING: source write-protected, mounted read-only.
Kötetek címkézése
A kötethez címke rendelhetők, mellyel a későbbiekben könnyebben nyomon követhetjük a feladatát. A címke beállítására az e2label parancs szolgál az EXT2, EXT3 és EXT4 fájlrendszerek esetében, melynek először a kötet eszközét, majd a címke szövegét adjuk meg:
root@server:~# e2label /dev/sda1 BOOT
A címkét lekérdezni például az lsblk paranccsal tudjuk:
root@server:~# lsblk -o name,label /dev/sda1
NAME LABEL
sda1 BOOT
Hasznos lemezkezelő parancsok
Nézzünk át most pár olyan parancsot, melyekkel különböző információkat tudunk lekérdezni a rendszerünkről. Amennyiben nem érnénk el valamelyiket telepíteni szükséges a parancs nevével megegyező csomagot. (Ahol más a csomagnév, ott jelezzük.) Ennek a fejezetnek nem az egyes parancsok használatának részletes bemutatása a célja, hanem csak az, hogy tudjunk róluk. Ha valamelyik parancs felkeltette a figyelmünket, a megfelelő oldalakon megtaláljuk a részletes bemutatásukat.
lsblk
Az lsblk -f paranccsal olyan információkat jeleníthetünk meg a lemezeinkről, mint a fájlrendszerük típusa, csatolási pontjuk, címkéjük, stb.
root@server:~# lsblk -f /dev/sdb
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdb
├─sdb1 LVM2_member LVM2 001 mD02ps-u3TY-41J1-yf98-vu4L-yleK-nQzs7W
│ └─data_vg-data_01 ext4 1.0 e088f36d-ee10-4218-9173-93ebc89bee72 23.2G 0% /mnt/adatok1
├─sdb2 LVM2_member LVM2 001 Gsx1qo-sJ8J-59AN-GV1W-UXGa-czO3-SJNdTs
│ └─data_vg-data_02 ext4 1.0 a83ae6c8-c38c-4f52-8f7d-68b963d3378a 9.2G 0% /mnt/adatok2
├─sdb3 LVM2_member LVM2 001 Qm2UBi-6KVH-ehF1-vF9Q-BqSC-SFFm-KNGzVc
│ └─data_vg-data_02 ext4 1.0 a83ae6c8-c38c-4f52-8f7d-68b963d3378a 9.2G 0% /mnt/adatok2
└─sdb4 LVM2_member LVM2 001 Iyjsc5-eymt-080f-uwae-WemP-BjXI-uHEeqC
└─data_vg-data_01 ext4 1.0 e088f36d-ee10-4218-9173-93ebc89bee72 23.2G 0% /mnt/adatok1
dh
Ha csak a rendelkezésre álló szabad helyet szeretnénk megjeleníteni, használjuk a dh parancsot. (Az LVM cikkben majd megismerjük ezt az eszközt.)
root@server:~# df -h /dev/mapper/data_vg-data_01
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/data_vg-data_01 25G 28K 24G 1% /mnt/adatok1
df
Kevesen gondolnak arra, hogy nem csak a szabad hely fogyhat el, hanem a rendelkezésre álló szabad inode-ok is. Minden inode egy fájlt vagy könyvtárat azonosít. Ha elfogynak az inode-ok, hiába van szabad hely, nem tudunk több fájlt vagy könyvtárat létrehozni. Az inode-okról szintén a df paranccsal kapunk információt:
root@server:~# df -i /dev/mapper/data_vg-data_01
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/data_vg-data_01 1638400 12 1638388 1% /mnt/adatok1
du
Ha arra vagyunk kíváncsiak, hogy egy könyvtár tartalma mekkora helyet foglal el a lemezen, akkor a du parancsot használhatjuk:
root@server:/var# du -sh /root
103M /root
pydf
A pydf parancs ezen felül látványosan is jelzi, hogy mennyi helyet használtunk már el az adott köteten.
root@server:~# pydf
Filesystem Size Used Avail Use% Mounted on
/dev/ubuntu--vg-ubuntu-/lv 10G 2841M 6611M 28.5 [######................] /
/dev/sda2 1748M 130M 1512M 7.4 [##....................] /boot
/dev/data_vg/data_01 25G 28k 23G 0.0 [......................] /mnt/adatok1
/dev/data_vg/data_02 10G 28k 9451M 0.0 [......................] /mnt/adatok2
inxi
Összesítve a teljes tárolóterületet egyéb információkkal együtt az inxi parancs írja ki.
root@server:~# inxi
CPU: 2x 1-core 11th Gen Intel Core i5-11300H (-SMP-) speed: 3110 MHz
Kernel: 5.15.0-76-generic x86_64 Up: 12h 39m Mem: 559.2/3877.8 MiB (14.4%)
Storage: 140 GiB (2.2% used) Procs: 211 Shell: Bash inxi: 3.3.13
stat
Egyetlen fájlról vagy könyvtárról a stat paranccsal tudunk olyan információkat lekérni, mint a mérete, csoportja, eszköze, a rámutató linkek száma és az időbélyegei:
root@server:/var# stat /etc/fstab
File: /etc/fstab
Size: 629 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 131601 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-07-13 06:00:11.073640230 +0000
Modify: 2023-07-06 19:33:29.482998167 +0000
Change: 2023-07-06 19:33:29.482998167 +0000
Birth: 2023-07-03 13:09:32.989418914 +0000
cfdisk
A cfdisk parancs egy olyan interaktív programot indít el, amellyel könnyedén tudjuk a partícióinkat kezelni, törölni, átméretezni, típust váltani:
Disk: /dev/sda
Size: 20 GiB, 21474836480 bytes, 41943040 sectors
Label: gpt, identifier: 89DA43C6-E027-4818-9200-059187EC106B
Device Start End Sectors Size Type
>> /dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 3719167 3715072 1.8G Linux filesystem
/dev/sda3 3719168 41940991 38221824 18.2G Linux filesystem
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│Partition UUID: 0316750B-4EF0-49BE-9C93-E6ABE70778E5 │
│Partition type: BIOS boot (21686148-6449-6E6F-744E-656564454649) │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
[ Delete ] [ Resize ] [ Quit ] [ Type ] [ Help ] [ Write ] [ Dump ]
iostat
Amennyiben a háttértárunk használatáról szeretnénk információt kapni, használjuk az iostat parancsot. (Használatához a sysstat csomagot kell telepíteni.)
root@server:~# iostat -p sdb
Linux 5.15.0-76-generic (server) 07/13/23 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.06 0.00 26.08 0.41 0.00 73.44
Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd
sdb 0.02 0.70 0.07 0.00 33710 3400 0
sdb1 0.00 0.12 0.02 0.00 6040 822 0
sdb2 0.01 0.20 0.02 0.00 9733 878 0
sdb3 0.00 0.10 0.02 0.00 4896 822 0
sdb4 0.01 0.22 0.02 0.00 10453 878 0
smartctl
A merevlemezek számára még az IBM fejlesztette ki a S.M.A.R.T. (Self-Monitoring Analysis and Reporting Technology) önellenőrző technikát, melynek feladata a merevlemez állapotának folyamatos figyelése. Ez a funkció az SSD-kben is megtalálható. A smartctl parancs segítségével a S.M.A.R.T. által összegyűjtött információkat tudjuk lekérni az adott eszközről. (A parancs a smartmontools csomag része.) Most a parancs kimenetének csak egy részét jelenítjük meg. (A többi információ azért is nem releváns, mert egy virtuális gép virtuális merevlemezének adatait kérdezzük le…)
root@server:~# smartctl -a /dev/sdb1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-76-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: VMware,
Product: VMware Virtual S
Revision: 1.0
User Capacity: 21,474,836,480 bytes [21.4 GB]
Logical block size: 512 bytes
Rotation Rate: 15000 rpm
Device type: disk
Local Time is: Thu Jul 13 08:52:23 2023 UTC
SMART support is: Unavailable - device lacks SMART capability.
=== START OF READ SMART DATA SECTION ===
...
