Naplózó filerendszerek (journaling)

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

ricsip — Fri, 01 Aug 2025 09:13:26 +0000

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?

inode/x-corrupted type [már rájöttem]

bzs — Sat, 06 Apr 2024 17:35:28 +0000

Naplózó filerendszerek (journaling)

Sziasztok.

Egy nap arra keltem, hogy a Thunar és a GUI-s fájlkezelők mindegyike bizonyos könyvtárakat a tárgyban megadott

inode/x-corrupted type

típussal jellemezték. Parancssorban, mc alatt, saját szkriptekkel minden rendesen működik, de amint egy GUI-s program open dialogboxot vagy mentésnél egy fájllistázást végez, a könyvtárak már ismeretlen fájlként jelennek meg.

Nem értem a jelenséget, sosem volt nekem ilyen jó jelenségem.

(fájlrendszerekhez kategorizáltam a kérdésemet, ami lehet, hogy téves, ha a probléma inkább GUI-jellegű)

Mivel orvosolható?

22 TB -ra jó még az NTFS?

timi — Tue, 19 Sep 2023 15:03:39 +0000

Naplózó filerendszerek (journaling)

Röviden persze nem mert 16TB a max méret NTFS-nél, így eleve két partíció kell, egy 16 TB és mellette 6 TB. Vagy két 11 TB

Egyébként 10 TB felett van hátránya az NTFS-nek?

ext4-nél is 16 TB a felső limit, viszont Btrfsnél már 50 TB. De Btrfs már magával hozza a Linuxot is, és ezen a gépen egyelőre jó a Windows. Kivéve azt az esetet ha nagyon rosszul teljesítene az NTFS 10 TB felett például linuxos Btrfsel szemben. Ebben az esetben megfontolom a Linuxra váltást.

Inkább nagyobb fájlok fognak dominálni. Nem akarom elaprózni sok "kis" partícióra. Jó ide az NTFS vagy rendszerrel együtt jöjjön inkább Btrfs vagy esetleg ZFS?

[MEGOLDVA] zfs damaged, fileokat megmenteni

uid_4672 — Wed, 19 Oct 2022 11:17:04 +0000

Naplózó filerendszerek (journaling)

adott egy zpool, ami degraded. zpool import azt mondja rá, hogy

state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.

meg hogy:

cannot import 'mypool': I/O error
Destroy and re-create the pool from
a backup source.

kellenének a file-ok. valakinek ötlete?

A zpool az hardware raid-en volt (tudom, hogy zfs mirror kellett volna, de ilyen volt a hardver) és ott a hardware raiddel cseszték el.

szerk: zfs on linuxról van szó, debian 10

Alacsony memóriaigényű linuxos filerendszer

locsemege — Fri, 04 Feb 2022 21:57:44 +0000

Naplózó filerendszerek (journaling)

Egy 128 GB-os pendrive-on létrehoztam egyetlen partíciót, majd megformáztam f2fs-re. Bedugtam a kis szappantartó router-embe - 64 MB RAM-ja van - dugott USB hubba, majd megpróbáltam mount-olni. Tulajdonképpen sikerült, csak egy-egy parancsra alig reagált a router, majd kb. két perc elteltével össze is dőlt, nem natolt tovább.

A lényeg, hogy úgy tűnik, az f2fs driver RAM-ban akarta tartani a filerendszer leírókat, valami adminisztrációt, amihez kevés volt a RAM.

Milyen filerendszert válasszak, ami nem eszi meg a RAM-ot, s lehetőleg kíméli az USB mass-storage flash device-t, azaz a pendrive-ot, lehetőleg kezeli a linuxos jogosultságokat, valamint naplózott?

ZFS mozgatás másolás nélkül

zoldnap — Thu, 07 Oct 2021 18:48:47 +0000

Naplózó filerendszerek (journaling)

Sziasztok,

Kezdő ZFS felhasználóként a következőket tettem: két régi, kisebb HDD-ről egy nagy SSD-re másoltam anyagokat.

Ezt úgy tettem, hogy az ssd_pool/root datasetbe tettem a hdd1 anyagait, a ssd_pool/root/hdd2-be pedig a hdd2 anyagait, hogy miért az már lényegtelen, így sikerült send/recv-elni a régi HDDkról.

A kérdésem, hogy miképpen tudom megszüntetni az ssd_pool/root/hdd2-t, azáltal, hogy a rajta található fájlokat az ssd_pool/root-be szeretném átmozgatni.

Amikor megpróbáltam, akkor észrevettem, hogy ez fizikai másolással jár, amit nem igazán értek, hiszen a mozgatás még ext4-nél is egy gyors művelet volt, csak áttette a bejegyzést egy másik könyvtárba és kész.

Van eset, amikor az egyszerű mv is másolás nélkül megy ZFS-en? Beállításokon, a datasetek elrendezésén múlik? (tekintve, hogy szülő-gyerek módon vannak a datasetek, főleg nem kellene akadály legyen ez..)

Valami más mód amivel tudok másolásmentesen mozgatni? (clone?)

Azért érdekel, mert egyrészt nem szeretném az SSD-t feleslegesen írni, másrészt mi történik, ha nincs annyi szabad hely, hogy egy adott fájl kétszer is elférjen mielőtt törölné az eredetit?

Nekem idáig úgy tűnt, hogy a pool az, ami a fizikai hardverrel van közelebbi kapcsolatban, a datasetek inkább logikai elválasztást jelentenek. De több helyen is azt olvastam, hogy mozgatás szempontjából két dataset az mint két önálló fájlrendszer funkcionál.

Valaki légyszives homályosítson fel! :)

F2FS diszk használat

wowbagger — Thu, 20 May 2021 11:59:57 +0000

Naplózó filerendszerek (journaling)

Most migrálom az adataimat a régi gép SSD-jéről a másikra, és ezt látom az újon:

root@XXX-mobile:/home# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-home--lv      320G  308G   13G  97% /home
root@XXX-mobile:/home# du -sh *
267G    XXX

Ez hogy lehet? Azért a ~40 GB eltérés elég combos. F2FS alatt nincs root-nak fentartott százalék, és amúgy is, root-ként annak nem kéne látszania.

Hogy lehet megtudni fájlok méretét btrfs-en?

gee — Thu, 06 May 2021 10:20:09 +0000

Naplózó filerendszerek (journaling)

Elkezdtem kb. két hete btrfs-t használni a NAS-ban, és ugyan tetszik és elégedett vagyok vele, de hozott magával pár buktatót.

A NAS tartalmáról több kisebb külső hdd-re készítek mentést időnként. Régen ez úgy ment, hogy a NAS-on hardlinkekkel és törléssel csökkentettem a duplikációt, és rsync-kel ment a másolás a backup diszkekre. Mindegyik backup diszkhez tartozott egy rsync parancs, ami néhány könyvtárat átmásolt (és közben figyelt a hardlinkekre).

Btrfs-en a blokk szintű deduplikációt próbálom belőni (még nincs kialakítva a végleges megoldás).

Azt észrevettem, hogy az rsync ezt nem kezeli, így vagy azt csinálom, hogy a backupra dedup nélkül másolok mindent, vagy rsync helyett mást használok. Erre mondta valaki, hogy btrfs send/receive.

send/receive-hez subvolume kell, nem tudok csak random könyvtárakat megadni, mint eddig. Ezzel csak az a gond, hogy subvolume-ok nem osztoznak az inode-okon (ibögökön :-D ), ezért hardlink nem megy mindenen át.

OK, akkor a subvolume-ok kialakítása után, de még az oda tartozó könyvtárak átmásolása előtt lekérdezem, hogy vannak-e olyan hardlinkek, amik ezeken a könyvtárakon kívül vannak, és amiket a mv eltörne. OK, ezeket akkor cp --reflink módon helyettesíteni tudom. Így nem nő meg az eddigi helyfoglalásom.

De most meg abba a problémába futottam bele, hogy 1) a du-nak fogalma sincs arról, hogy fájlok megosztoznak blokkokon, szóval egy reflinkkel másolt fájlt kétszer simán megszámol, és aztán behazudja nekem, hogy pl.

root@bananapi:/srv/dev-disk-by-id-dm-name-nas/gee/to-backup# du -h reflinktest/
316G    reflinktest/

Miközben valójában a könyvtárban ugyanaz az egy darab 158G-s fájl van meg kétszer. Ami egyébként a könyvtáron kívül is megvan. Szóval nekem az lenne jó, ha ezt a könyvtárat kérdezem, akkor 158G-t mondjon, ha meg mondjuk egy könytár struktúrát számolok rekurzívan, akkor ha már egyszer megszámolta ezt a fájlt máshol, akkor ezt a könyvtárat 0-nak vegye.
Ahogy ezt hardlinkek esetén a du ügyesen le is kezeli.

Szóval egyfelől ha valaki tudja, hogy tudom egy fájl, egy könyvtár hierarchia vagy egy subvolume on-disk méretét lekérdezni, annak örülnék.

2) Ha reflinkkel másoltam egy fájlt, nem tudom, hogyan tudom meg róla, hogy osztozik blokkokon más fájlokkal - és ha igen, melyik fájlokkal. Illetve nem tudom, hogy van-e egyáltalán ilyen funkció, remélem, hogy igen.

Erre tud valaki megoldást?

Illetve ha van ötletetek, hogy lehetne ezt jobban, hatékonyabban vagy egyszerűbben csinálni, az is jöhet.

Egyelőre most ott tartok, hogy dobom az egész subvolume és btrfs send/receive koncepciót, mert sokat kell pl. az eltört hardlinkek egyenkénti kézzel helyettesítésével vacakolni, és akkor még jön a többi; megtartom, ami eddig volt, hardlinkek és rsync csak néhány könyvtárra, és ugyan a NAS-on lesz blokk szintű deduplikálás, a biztonsági másolatoknál nem, csak a hardlinkek lesznek, mert csak rsync-kel másolok. Így továbbra is tudom a du-t használni és látom előre, hogy belefér-e a kisebb backup hdd-re az, amit oda akarok másolni. Cserébe kb. 1TB-tal több tárhely kell a backup diszkeken, mint amennyit a NAS foglal majd a dedup után. :-(

[DUPLÁN MEGOLDVA] [C/C++] ZFS + VPS + Ext4 = Corrupted InnoDB

davies007 — Fri, 30 Apr 2021 02:49:20 +0000

Naplózó filerendszerek (journaling)

Két dolog miatt szánok egy kis szösszenetet a sztorinak.

Az egyik oka, hogy igencsak meglepődtem, hogy ilyen meg tud történni a másik oka, mert készült is rá egy megoldás melyet örömmel szeretnék megosztani a közösséggel.

Nagy vonalakban a sztori, hogy egy ZFS storage -el ellátott VPS (KVM alapú) anyagépen, egy tucat Linux VPS -ből az egyik, ext4 fájlrendszere egyik pillanatról a másikra eldobta magát.

ZFS checksum ON, hiba nincs.
ext4 naplózott, nem volt hirtelen halál, ac loss, igazából nagyjából ilyen féléves uptime -ját ünnepelte maga a VPS, 1,5 évvel ezelőtt volt bővítve a fájlrendszer, amúgy Virt-IO.

A történet sajnálatos eredménye, hogy az innoDB .ibd fájlait szépen elkorruptálta, tehát I/O Error -t írt ha másolni, megnyitni akartam, éppen ezért a mySQL vagy el sem indult, vagy nagyon rövid időn belül "felakasztotta magát".

Szóval én láttam már sok mindent, de ilyet nem, mármint VPS esetén:

[23563.216403] blk_update_request: I/O error, dev vda, sector 960227912
[23563.356236] blk_update_request: I/O error, dev vda, sector 960227912
[23563.527275] blk_update_request: I/O error, dev vda, sector 960227912
[23563.805136] blk_update_request: I/O error, dev vda, sector 960227912
[23564.244561] blk_update_request: I/O error, dev vda, sector 960227912
[23564.375360] blk_update_request: I/O error, dev vda, sector 960227912
[23567.440755] blk_update_request: 12 callbacks suppressed
[23567.440781] blk_update_request: I/O error, dev vda, sector 960227912
[23567.520537] blk_update_request: I/O error, dev vda, sector 960227912
[23567.587946] blk_update_request: I/O error, dev vda, sector 960227912
[23568.054547] blk_update_request: I/O error, dev vda, sector 960227912
[23568.075419] blk_update_request: I/O error, dev vda, sector 960227912
[23568.077621] blk_update_request: I/O error, dev vda, sector 960227912
[23568.078390] blk_update_request: I/O error, dev vda, sector 960227912
[23568.079057] blk_update_request: I/O error, dev vda, sector 960227912
[23568.080408] blk_update_request: I/O error, dev vda, sector 960227912
[23568.081079] blk_update_request: I/O error, dev vda, sector 960227912
[23572.441857] blk_update_request: 7307 callbacks suppressed
[23572.441881] blk_update_request: I/O error, dev vda, sector 960227920
[23572.443353] blk_update_request: I/O error, dev vda, sector 960227920
[23572.444023] blk_update_request: I/O error, dev vda, sector 960227920
[23572.444575] blk_update_request: I/O error, dev vda, sector 960227920
[23572.445979] blk_update_request: I/O error, dev vda, sector 96022792

Tehát mégegyszer az "underlaying storage" (ZFS) rendben van, a diszkek is.
qemu-img check nem talált hibát, fsck force lefutott rendben.
qemu-nbd -vel felcsatoltam anyagépen, ott se volt hiba, egészen addig míg nem léptem bele egy "badsector" -ba.

Na erre mondjon valaki okosat nekem.

A másik oldala a dolognak, hogy ám az adatbázis rohadtúl kellett és nem találtam az interneten olyan programot amivel kimondottan csak 1-1 fájlt, helyre lehessen állítani gyorsan és az sem baj ha véres marad, illetve minimálisan testreszabható legyen a visszaállítás, ezért készítettem egyet és a helyzet az, hogy megmentette a napot.

Az ötlet onnan született, hogy van egy fájl ami 500MB, 384MB -nál I/O Error -t dob... Gondoltam, hogy most maximum 512KB -ot nem tud kiolvasni, de a többi részét meglehetne menteni, csak hogy I/O errornál minden belefut az END_OF_FILE -ba és hibával kilép, én meg maradtam egy 384MB -os fájlal amit biztos nem fog megenni a mySQL.

Ami megoldást találtam az a dd és a ddrescue volt,

dd if=./file1 of=./file1.fix bs=512 conv=noerror,sync iflag=fullblock

De ezzel az volt a probléma, hogy kellett egy olyan feature is, hogy ne 0x00 -val írja ki a hiányzó részeket, mert pont bekavar az innoDB -nek és nem igazán találtam megfelelő dokumentációt ennek a működéséről és rengeteg helyen kinullázott dolgokat.

Aztán született egy saját megoldás, ami ezt megoldja azzal, hogy ugyanúgy továbblépteti és a hiányzó adatokat tetszőleges karakterrel helyettesíti, és bájtonként halad a recovery része így viszont kaptam egy ugyanakkora méretű fájlt mint az eredeti, csak 1-1 helyen pár kilobájt éppenséggel killett nullázva vagy pont más karakterrel lett behelyettesítve, a visszaállítás sebessége is felülmúlta az alternatívákat.

Ennek köszönhetően, elindult az adatbázis, viszont ahogy belefutott a problémás részbe, "Buffer overflow" -al meg is döglött, létezik egy varázstrükk, ez pedig az `innodb_recovery_mode`, ezt 6 -osra állítva simán adott egy mysqldumpot, ráadásul úgy, hogy egy bájt adat nem hiányzott.

Ja és ECC RAM meg modern környezet.

A program végezetül ami mentett egy nagyott, szó szerint.
https://github.com/DaVieS007/Partial-File-Recovery

BTRFS kezdő subvolume kérdés

gee — Wed, 28 Apr 2021 13:10:32 +0000

Naplózó filerendszerek (journaling)

Egy másik topicban felmerült ez, és most kérdéseim vannak.

A felállás ez: Van egy NAS, benne egy nagyobbacska hdd, btrfs.

Van több kisebb hdd, amikre szeretnék a NAS-on tárolt adatokból backupot készíteni.

Ahogy olvasom, ha készítek egy snapshotot a NAS-on, akkor utána egy btrfs-send --full paranccsal mindent át tudok küldeni egy másik btrfs fájlrendszerre. Remélem, ezt eddig jól értem.

Viszont úgy tűnik, hogy ez a teljes subvolume-ot vinné át és nincs mód arra, hogy mondjuk csak adott könyvtárakat másoljak.

Ha jól sejtem, erre az lenne a megoldás, hogy létrehozok subvolume-okat, a jelenlegi könyvtárakat beléjük mozgatom és így a külön backupolni kívánt könyvtárak külön subvolume-ban lennének.

Ahogy olvasom, minden subvolume-nak külön inode tere lesz, szóval az eddig használt hardlinkekkel vigyáznom kell.

Van valami más, amire oda kell figyelnem?

ZFS részleges send helyreállítása

Darkfish — Sat, 06 Mar 2021 08:24:24 +0000

Naplózó filerendszerek (journaling)

Nagyobb méretű datasetet (több tera) replikálok -s opcióval.

A send még tart, de ha valamiért megszakad, vajon bármilyen módon hozzáférhetek a félig áttöltődött datasetben lévő adatokhoz?

Ki foglalja a mit foglal a hol foglalja? - Nem létező fájl létező ballaszt üzemmódban

wladek1 — Fri, 19 Feb 2021 08:31:41 +0000

Naplózó filerendszerek (journaling)

Adott egy kiszolgalo, fejlesztestamogatasra hasznaljuk, a kovetkezot jatssza:

135G szabad hely tegnaprol mara elfogyott (aszongya, hogy nincs u"r az eszkozon), tehat a df szerint elfogyott a hely; du szerint a foglaltsag osszesen (rekurzivan) konstans 25G korul van, magyarul valami fog egy(?) fajlt es veszettul irja, de nem sikerul megallapitani, mi. Tipikusan hasonlot a $TMPDIR vagy valamelyik !syslog altal hasznalt log directory eseten tapasztaltam - ezek jol behatarolhato processzek voltak - ; de jo lenne, ha sikerulne megallapitani, ilyenkor mi fogja a melyik filedescriptort.

Van arra valami hasznalhato tool, hogy megallapitsam, mik az elhagyott file-k, amik mikozben latszolag nem leteznek, folyamatosan hiznak, majd reboot utan visszaall a normalis foglaltsag az erintett (donto reszben/jelenleg ext4) fajlrendszerben?

Remelem, ertelmesen meg tudtam fogalmazni, mit szeretnek elerni. :D

Koszi! :)

udisks2 automount ro

pink — Thu, 17 Dec 2020 13:12:15 +0000

Naplózó filerendszerek (journaling)

Sziasztok!

Adott:

RPi 4B+ 8GB
Raspbian Lite (Buster)

Erre telepítve egyebek mellett:

. Kodi Leia
. udisks2

kodi-standalone indulásakor szépen felmountolja a rádugott USB eszközöket (vinyók) az udisks2 által.
De akármit csinálok, mindig rw lesz az összes mount.

Próbálkoztam:

/etc/udisks2/udisks2.conf
/etc/udisks2/mount_options.conf

[defaults]
defaults=ro
allow=noexec,ro,...

Hiába veszem ki allow-ból is az rw-t, mégis rw lesz minden mount.
Tudom, hogy udev rules-ban felül lehetne bírálni, de érdekel, hogy az udisks miért disrespecteli a konfigomat.

Mit rontok el?

Mivel egyébként sincs szükség rw hozzáférésre (ha mégis, akkor ssh-n remountolom), így igyekszem elejét venni a fájlrendszer korrumpálódásának, ha pl. valaki umount nélkül kihúzza.

Arra van mód, hogy az ro-ként mountolt eszköz kihúzásakor az udisks2 felismerje mi történt és eltakarítsa a romokat? (adjon egy lazy umount-ot mondjuk, hogy kikerüljön az eszköz a mount táblából).

EXT4 -> BTRFS migráció

drobert82 — Sat, 17 Oct 2020 15:02:27 +0000

Naplózó filerendszerek (journaling)

Otthona konfigom Fedora31 külön /boot, /boot/efi, /, és /home partíciókkal EXT4-ekkel.
BTRFS-ről pedig azt olvastam, még korábban, hogy elég lesz 1 BTRFS partíció mindenre és ez - the way it meant to be played.
OK.
Majd egy évvel később újratelepítéssel frissítem a Fedora 33-at.
EXT4 esetén formáznám a /boot és / partíciókat, de mi a scenario BTRFSsel?

CEPH size/data min_size

vasla_ — Tue, 18 Aug 2020 20:32:10 +0000

Naplózó filerendszerek (journaling)

Ha jól értem Size / data min_size 3/2 értékénél 3 lemez 3 osd esetén 1 lemeznyi szabad helyem lesz a poolban?

És a 33% legjobb érték, a többi "értelmes" érték ennél kevesebb.