Az LVM megeszi a szabad helyet.

Linux-haladó

Sziasztok!

Egy olyan problémával szembesültem hogy, a rendszerben lvm kötetek ugrásszerűen megnönnek ha másolok rájuk adatot például egy 150M fájl után 15G fogllaltságot jelezz. Ez alapvetően azókra a lvm kötetekre igaz amelyekre ACL volt beállítva, kikapcsoltam de még mindig fenáll a probléma.

Probáltam találni rá megoldást de sajnos semmi,van-e valakinek valami ötlete hogy merre kellenne elindulni.
Köszi előre is.

  • 2202 megtekintés

( Czo v | 2018. 08. 09., cs – 13:19 )

Tehat azt allitod, hogy az az lvm-es kotet, amit letrehoztal pl. 30G meretunek, az egyszercsak 45G meretuve valik? Vagy csak letrehoztal valamilyen filerendszert ezen a koteten es ramasoltal 150M mennyisegu allomanyt es ez 15G helyfoglalasnak latszik? Nem lehet, hogy nagyon-nagyon aprok az allomanyok? Hol, milyen paranccsal latod ezeket? Kerhetnenk egy kicsivel tobb infot?

---
Apple iMac 27"
áéíóöőúüű

Ez az lvm egy samba share része és egy másik gépről felmásoltam egy weboldal tartalmát ami igen sok kis fájl tartalmaz, alaból egy kb. 150M méretű és utána megnő 15G-ra megnő a foglaltság. Az lvm kötetben van egy share mappa ami van megosztva sambán keresztül, erre definiáltam ACL-t.

Mivel kérdezed le a foglaltságot? Minek a foglaltságát nézed? A fájlrendszerét (df), a foglalt méretet (du - pl. 150M keresztbe kasult symlinkelt izé, a samba másolás közben eltűnnek a symlinkek és újra- és újra felmásolja őket) vagy a VG-n levő helyet (pl. thin provisioned lvm)?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

df -h
/dev/mapper/vgserver1-backup 99G 619M 94G 1% /home/backup

du /home/backup
16 /home/backup/lost+found
626508 /home/backup

a kérdés hogy miért van 3-4G különbség df-nél az lvm mérete 100G van rajta egy 619M méretű fájl, és mégis 94G szabad hely van, valahol elvesztődik 3G mindenkéépen.

tune2fs -l /dev/vgserver1/backup
tune2fs 1.43.4 (31-Jan-2017)
Filesystem volume name: backup
Last mounted on: /home/backup
Filesystem UUID: 67419f59-7fec-4c82-8e9f-f3008df58dfb
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6246400
Block count: 26214400
Reserved block count: 1050556
Free blocks: 25599363
Free inodes: 6246387
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 109
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7808
Inode blocks per group: 488
Flex block group size: 16
Filesystem created: Mon Aug 6 21:10:16 2018
Last mount time: Thu Aug 9 12:05:06 2018
Last write time: Thu Aug 9 12:05:06 2018
Mount count: 12
Maximum mount count: -1
Last checked: Mon Aug 6 21:10:16 2018
Check interval: 0 ()
Lifetime writes: 888 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: cf3625ed-045e-4af7-aff4-9953913c9729
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x77359996

Hiába válaszolt a kérdező, még mindig nem igazán tudtuk meg, hogy mi az igazi probléma.
Szerintem a megoldás az általad említett thin provisioned lvm körül keresendő. Tippem szerint a kérdező azt várná, hogy ha egy ilyen kötetre 150M adatot rámásol, akkor kb. ennyivel nőjön a kötet tényleges helyfoglalása, de nem ezt tapasztalja. Az ok pedig az, hogy a sok apró fájlt szétszórja az fs, így sok esetben egy teljes blokkot le kell foglalnia az lvm-nek, miközben az javarészt üres marad.

Igen azt várnám hogy ha 150M meretű fájlokat felmásolok akkor kb annyi is legyen ott. Amit észrevettem hogy ez a probléma legfőképpen SAMBA-n keresztül jeletkezik.
Most probálkozom a következő beállítással: allocation roundup size = 4096
Ha például csak sinám ssh/winscp kerestült feltöltöm ugyanazt a fájl akkor jól számolja.

Ha a block size 4096 bájt, és feltöltesz összesen 150 MB-nyi (512 bájtos blokkméret mellett), átlagosan 100 bájtos fájlokat, akkor az kb. 6 GB-ot fog elfoglalni a lemezen.

De csak találgatunk. Ha egyértelműen leírnád, hogy kb. hány darab fájlról van szó, valamint a fájlok mérete átlagosan mennyi, akkor többet tudnánk mondani.

( zeller | 2018. 08. 09., cs – 16:17 )

Ennek speciel a Linux-kezdőben lenne a helye... Plusz a kérdezőnek javaslom elolvasni ezt a doksit is.

( Zahy v | 2018. 08. 10., p – 16:49 )

Valaki elárulhatja, hogy honnan tudjuk, hogy milyen FS van azon az LVM-en, milyen paraméterekkel létrehozva. Pl. vegyünk egy olyan fájlrendszert, amely blokk/töredékblokk alapú, a block-size 256 MB, a töredékblokk méret 32 MB (betartjuk a fragment = blocksize / 8 szabályt), ott egy 1 bájtos fájl is 32 MB-ot fog elvinni.
(Igem tudom, hogy valahogy beesett már egy tune2fs, tehát ext-valamiről van szó nagy eséllyel, meg hogy a szokásos módon a kérdező nem hallott a root számára fenntartott adatterületről, de könyörgöm valaki észrevehetné, hogy miközben állítólag LVM-ről beszélünk, de közben df-fel kérdezünk le adatokat. Az egyik *kötetkezelő*, a másik meg *fájlrendszer*-tool. Hacsak nem btrfs/zfs, akkor ez két külön szint a diszkkezelésben. És nem az, hisz lvm.)

Igen, péntek is van, meleg is van.

( locsemege v | 2018. 08. 10., p – 17:28 )

Az LVM fölött még van egy filerendszer is, ezek nem azonos rétegek. Tippre azt mondanám, LVM nélkül is hasonló lenne a tapasztalás ugyanabban a filerendszerben. Hacsak nincs valami snapshot, vagy egyéb okosság.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE