EXT4 formázás (filesystem create) sebessége

Naplózó filerendszerek (journaling)

Sziasztok,

egy csecsemőnek minden vicc új. OMV-t felraktam próbából 1 régi gépre. Ment bele egy 250 gigás SSD az OS-nek (elég pazarló, de ennél kisebb SSD-m nem volt kéznél). Storage-nak meg raktam bele egyelőre 1 db 2TB-os HDD-t. Formázáshoz kiválasztom azt EXT4-et (a ZFS 1 diszken lesz a következő próba, de a gyors előreolvasás alapján ez olyan speciális eset lehet amit talán ismernie kell az OS-nek is h. egyáltalán engedjen ilyet?)

Na itt elcsodálkoztam, h. miért tartott a 2TB-os EXT4 particiót vagy 10 percig létrehozni? A lassú progress bar megy szépen felfelé, a diszk folyamatosan világít tehát csinált valamit nagyon. Érzésre ez nem az a fajta lassúság, ami a teljes diszk terület írásából-visszaellenőrzéséből ered (windows-style full format), mert akkor az viszont lenne vagy 2-3 teljes óra ezen a diszken (kb. 100MB/sec-et bír írni max).Tényleg ilyen sok metaadatot "pazarol" az EXT4, aminek kell az a 10 perc mind kiírni? Vagy ez csak OMV-specifikus hülyeség, h. nem tud "quick format"-ot?

  • 1067 megtekintés

( Fisher v | 2025. 08. 01., p – 11:37 )

Az mkfs -t xfs volt azt, ami nekem feltűnt, hogy nem nagyon hasít, az a "Discarding blocks..." részen szöszmötöl sokat (vmware). Ha találgatni kellene, akkor trim/discard dolgokat művel.

( hnsz2002 v | 2025. 08. 01., p – 12:08 )

Nem tudom mi köze a benzinkútnak az ext4-hez...

De igen, ilyen lassú.

mkfs.xfs sokkal gyorsabb.

"Sose a gép a hülye."

( bzt | 2025. 08. 01., p – 12:47 )

Tényleg ilyen sok metaadatot "pazarol" az EXT4, aminek kell az a 10 perc mind kiírni?

Igen. Komolyan nem tűnt fel, ahogy formázáskor a blockgroup infókat irogatja a kimenetre?
2TB esetén már eléggé számottevő a metaadatmennyiség.

ezt egyebkent erdemes tweakelni. van egy keplet hogy az inode szamot hogyan szamolja ki a meretbol. ami normal felhasznalas mellett jo is lehet. ha azonban linux isok meg nagy fajlok vannak akkor felesleges akkora inode szam, lehet csokkenteni.

pl proxmox backup alatt, majdnem teljes disk:

~# df -h /srv/pbs
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/HDD20T-pbs   18T   18T  400G  98% /srv/pbs
~# df -i /srv/pbs
Filesystem                Inodes   IUsed     IFree IUse% Mounted on
/dev/mapper/HDD20T-pbs 595591168 7285517 588305651    2% /srv/pbs

majd egyszer kiszamolom mekkora helyet jelent ez a sok inode fenntartas.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

majd egyszer kiszamolom mekkora helyet jelent ez a sok inode fenntartas.

Leginkább fs létrehozás után azonnal a df megmutatja h. egy db user file nélkül is már mennyivel csökkent a teljes használható méret?

Hülye kérdés (ntfs-en szocializálódtam, szóval...) : ha fs létrehozáskor már firkált mindenféle inode adatokat a diszkre, akkor az azt jelenti h. fixen lefoglalta az összes metaadathoz szükséges helyet már a 0  napon? Azaz innentől kezdve nem lesz további helypazarlás metaadat miatt? Akkor sem ha a max inode mennyiségű fájl létrejön az fs-en?

Nem hülye kérdés. És engem is érdekelne a válasz. Sajnos ilyen mélységben nem ismerem a filerendszerek működését.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

A szuperblokkokat és az inode táblát létrehozza az mkfs, ebben időbélyegek, jogosultságok, stb. mind benne vannak.  Ja, és a helyfoglalási infó, blokkcímek, a legfontosabb.

A fájlnevek nincsenek benne az inode-ban, azok directory blokkokban lesznek majd létrehozáskor.

szerintem idióta tervezési hiba, hogy előre mondd meg, hogy hány file lesz az adott filerendszeren

Mivel kötött h. mennyi lehet a partición a max fájlok darabszáma, pl. 2^32-1, ezt nem fs létrehozáskor mondtad meg, hanem akkor amikor fs-t választottál. Fs létrehozáskor ezt a limitet csak lejjebb tudod állítani.

( Raynes v | 2025. 08. 01., p – 14:08 )

Igen, ez ilyen lassú. Én egy éve egy 4 terás HDD-t formáztam ext4-re, az is eltartott több percig. Jó, 10 perc talán nem volt, de jó pár perc. Ez ilyen. Nehogy azt hidd, hogy a többi fájlrendszer gyorsabb. A MS-nak az okádék NTFS-én szerintem jóval tovább tart, btrfs, ZFS-ről nem is beszélve. Lehet az XFS kicsit gyorsabb lesz, de az se annyival. Ez ilyen. Úgyse formázol ekkora fájlrendszereket minden nap.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A MS-nak az okádék NTFS-én szerintem jóval tovább tar

Nem tudom ezt honnan szeded: egy 18T-s NTFS partició formázása (quick) megvan ~5 másodpercen belül. A full format meg annyi, mint végigírni 18T-t 0-kkal.

Ext4-nek van quick format üzemmódja?

Ezt nehezen hiszem, mert nekem még kisebb adattárolókon is több volt 5 mp-nél. 18 teránál képzelem, hogy hosszabb lehet lényegesen.

Az ext4-nek csak quick format üzemmódja van. Nem is lehet vele olyan szektortesztelős, írásos-visszaolvasásos lassú formázást csinálni, mint NTFS-en. Ha ilyet akarsz, akkor ext4-nél előbb badblocks-ot kell futtatni, az, ha van hibás szektor, akkor kiírja melyek azok, azokat át kell irányítani fájlba, és azt a fájlt kell megetetni az mkfs.ext4 -l kapcsolóval (ez egy kis L, nem egy nagy i).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ha nagyon kíváncsi vagy rá, holnap lemérem egy 18TB-on. Lehet h. 6 másodperc lesz.

Update: lemértem: kb. 3-4 másodperc között volt.

 

Valamint némi stat:

Invoking defragmentation on 18TB (E:)...

        Analysis:  100% complete.
        Free Space Consolidation:  100% complete.

The operation completed successfully.

Post Defragmentation Report:

        Volume Information:
                Volume size                 = 16.37 TB
                Cluster size                = 16 KB
                Used space                  = 283.07 MB
                Free space                  = 16.37 TB

        Fragmentation:
                Total fragmented space      = 0%
                Average fragments per file  = 1.00

                Movable files and folders   = 21
                Unmovable files and folders = 4

        Files:
                Fragmented files            = 0
                Total file fragments        = 0

        Folders:
                Total folders               = 2
                Fragmented folders          = 0
                Total folder fragments      = 0

        Free space:
                Free space count            = 2
                Average free space size     = 16.37 TB
                Largest free space size     = 16.36 TB

        Master File Table (MFT):
                MFT size                    = 256.00 KB
                MFT record count            = 255
                MFT usage                   = 100%
                Total MFT fragments         = 1

        Note: File fragments larger than 64MB are not included in the fragmentation statistics.

----------

Ugyanerre a particióra:

NtfsInfo v1.2 - NTFS Information Dump
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Volume Size
-----------
Volume size            : 17166317 MB
Total sectors          : 35156619263
Total clusters         : 1098644351
Free clusters          : 1098629450
Free space             : 17166085 MB (99% of drive)

Allocation Size
----------------
Bytes per sector       : 512
Bytes per cluster      : 16384
Bytes per MFT record   : 0
Clusters per MFT record: 0

MFT Information
---------------
MFT size               : 0 MB (0% of drive)
MFT start cluster      : 196608
MFT zone clusters      : 196608 - 209440
MFT zone size          : 200 MB (0% of drive)
MFT mirror start       : 1

Meta-Data files
---------------
 

-----------

 

fsutil fsinfo ntfsinfo e:
NTFS Volume Serial Number :        0x2aa0a526a0a4fa09
NTFS Version      :                3.1
LFS Version       :                1.1
Total Sectors     :                35,156,619,263  (16.4 TB)
Total Clusters    :                 1,098,644,351  (16.4 TB)
Free Clusters     :                 1,098,629,574  (16.4 TB)
Total Reserved Clusters :                   3,340  (52.2 MB)
Reserved For Storage Reserve :                  0  ( 0.0 KB)
Bytes Per Sector  :                512
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                16384
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            256.00 KB
Mft Start Lcn  :                   0x0000000000030000
Mft2 Start Lcn :                   0x0000000000000001
Mft Zone Start :                   0x0000000000030000
Mft Zone End   :                   0x0000000000033220
MFT Zone Size  :                   200.50 MB
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :      E300D370-6F2A-11F0-BDE3-1C1B0D2E3DEE

----------

 

chkdsk e: /v
The type of the file system is NTFS.
Volume label is 18TB.

WARNING!  /F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
  256 file records processed.
File verification completed.
 Phase duration (File record verification): 6.00 milliseconds.
  0 large file records processed.
 Phase duration (Orphan file record recovery): 0.63 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 0.55 milliseconds.

Stage 2: Examining file name linkage ...
  278 index entries processed.
Index verification completed.
 Phase duration (Index verification): 2.70 milliseconds.
  0 unindexed files scanned.
 Phase duration (Orphan reconnection): 0.83 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 0.35 milliseconds.
  0 reparse records processed.
  0 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 0.92 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 2.23 milliseconds.
  12 data files processed.
 Phase duration (Data attribute verification): 0.37 milliseconds.
CHKDSK is verifying Usn Journal...
  1136 USN bytes processed.
Usn Journal verification completed.
 Phase duration (USN journal verification): 0.85 milliseconds.

Windows has scanned the file system and found no problems.
No further action is required.

  17166317 MB total disk space.
  52464704 KB in 8 files.
        96 KB in 13 indexes.
         0 KB in bad sectors.
    202431 KB in use by the system.
     65536 KB occupied by the log file.
  17114885 MB available on disk.

     16384 bytes in each allocation unit.
1098644351 total allocation units on disk.
1095352650 allocation units available on disk.
Total duration: 15.91 milliseconds (15 ms).

 

--> chkdsk alatt az az 52 GB 8 fájlban érdekes dolog, ezt nem tudom megfejteni

Kösz, hogy megnézted, elhiszem neked, ezek szerint ez tényleg ilyen gyors. Továbbra is tartom, hogy egy szar, de legalább ez előnyére írható akkor. Gondolom kevesebb metaadatot, naplót gyűjt az NTFS. Mondom, nekem nem nagy kérdés, én csak egyszer particionálok egy meghajtót, egyszer formázom a partíciót és utána nem nyúlok hozzá. Kivéve, ha sok évente egyszer Arch-ot telepítek újra, de az kisebb, 40 gigás ext4 root partíció és SSD-n van, az pár másodperc. A többi partícióhoz nincs nyúlva, minek. Ezt a szóban forgó 4 terás HDD-t se fogom többé particionálni, ez a HDD működik, amíg működik, csak külső meghajtónak van használva, n+1. archívumnak, ha megdöglik, így lesz kidobva. Még megsemmisíteni se kell, mert LUKS partíción van az ext4, így adattal nem tudnak róla visszaélni.

Nekem egyébként az összes egykutyának tűnik, ami unixlike fájlrendszer. Az XFS se formáz gyorsabban emlékeim szerint, próbáltam már ext2, ext3, f2fs, btrfs-t, OpenBSD alatt ffs2-őt, FreeBSD-n szintén ffs, meg ZFS, bár utóbbinál a telepítőben nem látszik, hogy mikor csinálja, akkor mekkora rész a formázás, meg ugye SSD-re nyomatom megint ezeket, így nem nagy időbeli tétel. Nekem eddig mindegyik kb. azonos sebességűnek tűnt ilyen téren. Vagy csak én nem voltam figyelmes, ki tudja. reisert, JFS-t, bcachefs-t, hammer2-őt még nem próbáltam, de meglepne, ha azok bármivel is gyorsabbak lennének ilyen téren.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( bzt | 2025. 08. 01., p – 15:22 )

majd egyszer kiszamolom mekkora helyet jelent ez a sok inode fenntartas

Én egyszer megnéztem, a legkissebb lehetséges EXT4 méret 128K, ennél 31K a meta (24%). Ez az arány a lemez méret növelésével csökken, 1G-nél már csak 12%, de hát 2T esetén még az alacsony arány is sok. (Ez az alapértelmezett blockgroupszám és inode mennyiség meghatározó függvény használata esetén.)

xfs ftw :)

Kicsivel rosszabb. A legkissebb méret XFS-nél 300M körüli, abból 85M-et eszik meg a meta (28%). 1G-nél már hasonló az arány az EXT4-hez, 120M, azaz 12%. Viszont nagyobb méretnél jobban skálázódik.

Érdekességképp, az általánosan használt fájlrendszerek közül:
- az örök vesztes a zfs, az pazarolja a legtöbb tárhelyet metára (az a sok zpool meg snapshot infó ugye)
- a btrfs is hasonló, kicsit rosszabb, mint az EXT4, de 1G-nél nagyságrendileg az is azonos, nincs túl nagy eltérés, kb. 12% körül van.
- az NTFS meglepően barátságos ebből a szempontból, 5% a meta egy 1G-s üres fájlrendszeren.
- a legjobb pedig a FAT32, ott a meta csak 2% és ez is skálázódik a legjobban (kétszeres méret esetén ez igényli a legkevesebb metanövekedést, de persze semmi sincs ingyen)

Általánosságban elmondható, hogy a fájlrendszer fícsöreinek számával exponenciálisan nő a metatárhelyigény, valamint hogy a lemezméret / meta arány csökken a lemez növelésével.

Viszont xfs-nél bármikor átállíthatod

Mindegyiknél bármikor állíthatod, sőt, mindegyiknél formázásnál kapcsolókkal befolyásolható. Nem véletlenül írtam oda, hogy alapértelmezett beállítások és méretszámítás mellett.

Egyébként meg szimplán szabadon hagyja azt a helyet (már ahogy én képzelem, most lusta vagyok hihető forrást túrni) amit nem használ.

Nem. A metaadatok számára fenntartott helyet sosem osztja ki felhasználói adatok számára, azaz azt tárhely szempontjából mindig foglaltnak tekinti, akkor is, ha metaadat szempontból nincs benne érvényes adat.
Az EXT4 spec úgy fogalmaz, hogy "statikusan allokált" (azaz az inode tábla akkor is helyet foglal, ha tele van üres inode rekeszekkel).

Egyébként az összes fájlrendszer ilyen (EXT4, XFS, NTFS, stb.), még az olyan extrém esetek is, mint pl. az LFS vagy a jffs2 (bár ezeknél elképzelhető, hogy amikor a körkörös írás körbefordul, legközelebb felhasználói adatnak allókálódik, ami korábban metaadatnak volt fenntartva).

Speiel az XFS kakukktojás, mert on-the-fly metaadatlétrehozást használ - azaz kb. sosem fogsz olyat tapasztalni, hogy 98 %-os adattelítettség mellett 2 %-os i-node telítettség lesz (mint itt fentebb valaki bedobta ext4-re). És igen, tudom, hogy a metaadat sokkal több mindent takar, mint az i-node-okat.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Speiel az XFS kakukktojás, mert on-the-fly metaadatlétrehozást használ

Nem, az is statikusan allokált: This space cannot be used for general user data including inodes, data, directories and extended attributes.

Ott is simán előfordul, hogy egy AG-ban betelik, ott annyival jobb csak a helyzet, hogy ilyenkor másik, kevésbé telített AG-ba tudja átcsoportosítani a metát.
As mentioned earlier, XFS filesystems are divided into a number of equally sized chunks called Allocation Groups.
Each AG can almost be thought of as an individual filesystem that maintains its own space usage.
The only global information maintained by the first AG (primary) is free space across the filesystem and total inode counts.

Akkor egy lépéssel hátrébb lépve:

 

Általában *X-világban használt natív fájlrendszereknek van valami kötelező metaadat területe. Ezt a legokosabb tervezéskor is "elpazarolja" az ember. Ilyen pl. a Szuperblokk (FS-tipus, méret, egyéb jellemzők tárolása.)

XFS esetén AG (Allocation Group) a neve annak az FS-objektumnak, amit amúgy (*BSD-n) UFS esetén CG-nek (Cylinder Group) hívnak (és mind a két esetben metaadatterület), és amelynek szerepe, hogy a fájlrendszeren levő adatokat (meta- és felhasználói egyaránt) szét lehessen szórni, kvázi párhuzamos diszkelérést biztosítva (van még pár egyéb funkciója). A lényegi különbség a kettő között, hogy a CG-kben valamely algoritmus szerint számolva fix mennyiségű i-node-nak szükséges metaadatot foglal le az mkfs, míg az AG-kben nem. Következésképpen UFS alatt elfogyhat a tárhely úgy, hogy allokálatlan i-node-ok pazarolnak tárhelyet, XFS-en pedig kb. egyszerre fog elfogyni, hisz amíg van hely, addig lehet mind a kettőt (i-node, adatblokk)  lefoglalnia az FS-rétegnek. Természetesen abban megegyezik a kétféle FS, hogy a létrehozás pillanatában az adott FS-méretének függvényében jön létre X vagy éppen Y db. AG (CG). És értelemszerűen ezek az AG-k, CG-k rendelkeznek saját belső struktúrával, tehát helyet visznek el a "hasznos" (felhasználói) adat elől. No most itt jutottunk el a probléma megoldásáig: ha valaki tudja, hogy egy FS kb. hogy működik, akkor akár előre is gondolkodhat. Kb. minden fájlrendszertípus esetén van néhány utólagos tuning lehetőség (valami tunefs-szerű paranccsal), és ami fontosabb: tuningolási lehetőség a létrehozás - az mkfs (newfs) - időpontjában, ilyen-olyan mkfs opciók formájában. Azaz pl. ha zavar, hogy az XFS túl sok helyet pazarol el az AG-k (metaadat) miatt, akkor helyből bele lehet neki ugatni az mkfs.xfs -d agcount=K (vagy épp -d agsize=U) paraméterrel. Mivel nekem volt már rá szükségem, ezért volt már életemben olyan, hogy beleugattam ezen allokációs egységek darabszámába - ha jól rémlik, egy floppy-diskre felrakott FS esetén. Így le tudtam szorítani a pazarlás nagyságát.

Én az AG-t (CG-t) ugyanúgy megkerülhetetlen részének tekintem az FS-nek, mint magát a szuperblokkot, és elfogadom, hogy a minimálisan szükséges darabszám az kell. (Ahogy elfogadom, hogy általában szoktak használni partíciós táblát is - MBR vagy GPT formájút, most mindegy; azaz ennyit "pazarol a rendszer. Ha kritikus, hogy ne pazarlódjon el, akkor nem csinálok ilyet - de jellemzően felkészülök az ebből adódó nehézségekre). Viszont ha kényes vagyok a pazarlásra, akkor sokszor ebbe a jellemzőbe bele tudok szólni.

E mellett XFS-nél nem kell baszakodni az i-node-ok ilyen-olyan darabszámával, a többi FS-nél meg igen. Ezért írtam, hogy metaadat-kezelésben az XFS némileg kilóg a sorból.

/OT

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ezért írtam, hogy metaadat-kezelésben az XFS némileg kilóg a sorból.

Nem, a különbség az, hogy XFS esetében az inode adatot nem értik bele az AG metába, lásd amit idéztem (legalábbis a Linux kernel doksiban nem értik bele). No meg az inode táblán kívül vannak még mindenféle allokációs bitmapek, stb. is. Én személy szerint beleértenék mindent a metaadatba, ami nem effektív felhasználói fájltartalom (még a könyvtárlistát is).

Az nem is vitás, hogy az XFS inode kezelése jobb, mint a többié, és jobb az inode kihasználtsága is, de ettől függetlenül simán előállhat olyan eset, hogy egy AG-n belül nincs már több szabad hely, de szabad inode rekesz mégis van. Mivel több AG-t kezel egyszerre (mindegyikben külön-külön inode táblával), ezért ez igazából nem okoz semmiféle gondot, észre sem veszed.

Tulajdonképpen érthetném úgy is, hogy nem ugyanarról beszélünk.

Létrehoztam egy 10G-s block device-ot, csináltam rá gyári beállítással xfst, az így 25%-ot ehetne metadatának, a df kimenetében látszik is, hogy lefoglalja és nem használható. Ja nem, nem látszik.

Átállítottam max 99%-ra, el is tűnt az összes szabad hely - ja, nem tűnt el - aztán odacsaptam valamit, hogy mégis, meddig fér, mert ugye 1% maradt!

Nahát, 9.9G... én erről beszélek. Mindegy hová tekered, a hely megmarad, legfeljebb létrehozhatsz borzasztó sok valamit, vagy kevésbé sok valamit.

Aztán hogy ez mennyire új implementáció, és hogy "az igazi" xfs az nem ilyen, meg egyébként is, azt rábízom arra, akinek van kézél XGI gépe.

root@s0:~# lvcreate  -L10G -n tvg vg00
  Logical volume "tvg" created.
root@s0:~# mkfs -t xfs /dev/vg00/tvg
meta-data=/dev/vg00/tvg          isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Discarding blocks...Done.
root@s0:~# mount /dev/vg00/tvg /mnt/
borg/    iso/     seedbox/
root@s0:~# mount /dev/vg00/tvg /mnt/iso
root@s0:~# df -h  /mnt/iso/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg00-tvg   10G  104M  9.9G   2% /mnt/iso
root@s0:~# /usr/sbin/xfs_growfs -m 99 /dev/mapper/vg00-tvg
meta-data=/dev/mapper/vg00-tvg   isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
inode max percent changed from 25 to 99
root@s0:~# df -h  /mnt/iso/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg00-tvg   10G  104M  9.9G   2% /mnt/iso
root@s0:~# dd=/dev/^C
root@s0:~# cat /dev/urandom > /mnt/iso/aaa
cat: write error: No space left on device
root@s0:~# du -sh /mnt/iso/aaa
9.9G    /mnt/iso/aaa

Ugyanitt: válasz az "az LVM vajon mire jó?!" kérdésre.

a df kimenetében látszik is, hogy lefoglalja és nem használható. Ja nem, nem látszik.

De látszik. Tárhelyméret - Avalailable oszlop.

Ugyanitt: válasz az "az LVM vajon mire jó?!" kérdésre.

Ugyanitt: az LVM-nek SEMMI köze a fájlrendszerhez (pont ezért tartom jobb megoldásnak, mint a zfs-t).

( dash | 2025. 08. 01., p – 19:21 )

-E lazy_itable_init=1,lazy_journal_init=1

Pontosan itt van az NTFS-nél (Windows-nál) felmagasztalt "quick-format" funkció. Ha a tempóval van a baj, akkor el lehet kenni a szükséges időt, lesz valami minimalista (és aztán a háttérben befejezi). Bár nekem azt mondja a manual, hogy kell mellé a -O uninit_bg, hogy működjön is.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?