Naplózó filerendszerek (journaling)

btrfs miért nem tömörít?

Sziasztok!

BTRFS-sel kísérletezek, most 4.4-es Linux kernel felett. Régebben ha mount opcióként az fstab-ban compress-force=zlib szerepelt, akkor gzip-pel tömörítette az inode-okat. Az utóbbi idők Linux disztribúcióiban ezt nem tapasztalom.

Ha össze akarom tömöríteni, akkor
btrfs filesystem defragment -czlib -r /mountpoint
hatására tömörödik csak össze.

Az okát keresem, mit rontok el vagy mi változott a kernelben? Netán nem elég az fstab-ban mount opcióként, hanem kell kernel boot paraméter is?

ext4 lazy itable initialization

Üdv mindenkinek,

CloudLinux 7.2 Rendszer telepítése után szembesültem az Ext4 új tulajdonságával. Hogy csökkentsék a fájlrendszer létrehozási időt egy lusta inicializálási mód szerint jön létre a fájlrendszer.

Reduced mke2fs time via lazy itable initialization in conjunction with the uninit_bg feature

Ez a gyakorlatban azt jelenti, hogy a fájlok/könyvtárak létrehozásának ütemében "készül el" a fájlrendszer _a_fájlrendszer_használata_közben_. Ennek hatásaként az írási sebesség a töredékére (~900MByte/s => ~30MByte/s) esik amikor az üres fájlrendszerre történik a fájlok/könyvtárak írása.

KÉP

Van valamilyen mód arra, hogy a fájlrendszer ismételt elkészítése (mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root) vagy a fájlrendszer teleírás nélkül kikényszerítsük (fsck.ext4 -v -f -y nem hatásos) a teljes fájlrendszer létrejöttét?

Announcing: Veeam Backup for Linux

http://www.veeam.com/blog/announcing-linux-server-backup.html

"Veeam does not leverage LVM snapshots. Instead, it has implemented a proprietary volume snapshot provider that does not suffer from the same limitations as LVM snapshots. This allows Veeam to take block-level snapshots on a vast range of file systems while storing snapshot data on the designated storage device, instead of on the actual volume you are backing up! And what’s more important, the solution can take a consistent snapshot of the server’s storage by using only the built-in functionality of Veeam Backup for Linux."

Fs kerestetik

Létezik olyan használható és karbantartott fs amiben az adatokat és a metaadatokat szeparáltan lehet tárolni?

Pontosítás:
Metaadat = minden adat ami a file tartalmán felül keletkezik. Tehát ha van egy 1 kB-os file-om akkor a data eszközre kerüljön felírásra 1 kB és csak annyi, minden egyéb sallang (név, könyvtárfa, i-node, log, cache, stb) kerüljön a metaadat eszközre.

milyen fs jó pendrive-ra?

A kérdés röviden: van egy 64G méretű, <1 éves pendrive, linux alól használnám, nem gyakran. Milyen fs-t tegyek rá?

Rendes linux alól használható fs kéne rá, ami nem irkál rá feleslegesen. Szóval kell kisbetű nagybetű, kellenek posix jogok, kell felhasználó, group, symlink, minden ilyesmi. Access time frissítés nem kell.

Journal nem kell, ha összekuszálódik a fájlrendszer, leformázom és backupból visszatöltöm rá az egészet.

Laptopon ext4-et használok, ehhez illeszkedő valamit szeretnék. Mivel journal nem kell, magamtól az ext2 jutott az eszembe. Van esetleg más, ami jobb (régebben voltak ilyesmik, amik a blokkok egyenletes elhasználására is figyeltek, hogy ne dögöljön meg túl hamar a pendrive, ha egy fájlt (könyvtárat) sokszor írok. De nem figyeltem a témát, nem tudom, hogy ezek mostanában is kellenek-e még vagy már meghaladta ezt az egészet a modern tudomány

Még nem döntöttem, melyiket használom erre a célra, van egy USB2-es Kingston DT Micro darab (ez igen lassú), és egy USB3-as Sandisk. Feltételezem, csak a sebesség számít, kb. ugyanazt tudják.

[Megoldva] Memdiskhez fájl rendszer.

Hi mindenki!

Kérdezném a közösséget, hogy van-e olyan fájl rendszer, ami zramra telepíthető és (most jön a neheze), ha törlik róla az adatokat, akkor visszazsugorodik minimális (eredeti) méretére.
Próbáltam hagyományos FS-eket (ext2, ext4, btrfs,) és flash alapút is (F2FS).
De mindegyiknél ugyanaz a probléma: induláskor még jó a memfoglalás, írok rá -> elfoglal annyit amennyi szükséges, de miután törlöm a rá felmásolt adatot (tehát üres a "meghajtó") marad a memfoglalás ugyanannyi. Nem szabadítja fel önmagán a keletkezet helyet.
Tehát: egy dinamikusan növekvő/csökkenő fájl rendszert keresek memdisk-re.

Kösz mindenkinek. Üdv.

zfs helyett milyen fájlrendszert?

Sziasztok!

Eddig zfs-t használtam, de sajnos az egyik gépemen sikerült egy vissza-visszatérő problémába belefutnom, abban meg nem nagyon bízom, hogy a fejlesztők épeszű időn belül kijavítanák.

Szóval keresek egy fájlrendszert zfs helyett.
Ami miatt eddig zfs volt:
- minden adat checksumolva, scrub esetén helyreállítja a replikákból
- nem kell bajlódni a raid-lvm-fs vonalon, egyben minden, átlátható
- ssd mint cache
- lz4 tömörítés

Talán a btrfs áll még ehhez legközelebb, de az nem annyira tetszik (lz4 helyett lzo, ssd cache nincs, nem annyira átlátható mint zfs) meg a fejlődését sem látom.

Szóval ha valakinek van valami ötlete, kérem ossza meg! (centos7-hez kell)
Köszi
S

Hibás ext4 életre lehelése

Sziasztok,

1tb hdd 2x500Gb ext4 partícióval banana pi sata portján. Második partíció mentés, aminek az eredetijét sokésszel letöröltem. (Kell a hdd, úgyis van mentés. Na innen még két napot ment)

Amit eddig tudok:

A HDD-nek semmi baja.
cfdisk és fdisk -l szerint is ott vannak a partíciók ahol lenniük kell.
mount /dev/sdb(1|2) /akarhova szerint bad superblock...
fsck.ext4 /dev/sdb(1|2) szerint bad superblock...
dumpe2fs /dev/sdb(1|2) szerint nem ext filerendszer, így nem is ad backup superblockokat.
file -s /dev/sdb(1|2): block special
Kevésbé fontos partíción próbáltam egy mkfs.ext4 -S -et, uána kb egy órán keresztül olvashatatlan sebességgel pörgött az fsck mire beláttam hogy nem ez lesz a megoldás.

Photorec látszólag nagyon jó aránnyal hoz vissza dolgokat, nyilván filenév és mappa információk nélkül.

Van valami módszer, sw, akármi amivel ebből az állapotból viszonylag rendezett adathalmazt hoz vissza, esetleg életet lehet az ext4 partícióba? Egyáltalán hogy érdemes elkezdeni kutatni, hogy mi a fene történt a filerendszerekkel? Ráadásul kettővel egyszerre?

Előre is köszönöm a segítséget!

[megoldva] Btrfs tömörítés - felvilágosítanátok?

Sziasztok!

Szóval mind a rendszer, mint a /home partícióm ext4 és nincs velük semmi gond. Viszont egy HUP-os ajánlás alapján a torrent partíciómon bevállaltam a btrfs-t, mivel állítólag erre a célra elég jó. (egyebek mellet) Valóban, kifogástalanul működik és sosem volt bajom a teljesítménnyel. Néha ráengedek egy kis online defragot is, az is tök jól működik.

Na most olvastam, hogy a btrfs képes tömörítésre. Gondolom ez hasonló, mint az NTFS-féle tömörítés.

Viszont kérdéseim vannak ezzel kapcsolatban.
● Mennyire érezhető ez az írási/olvasási teljesítményt tekintve?
● Azt értem, hogy a partíción tömörítve vannak. De ha átmásolom/átrakom máshová, akkor ott is tömörítve lesznek, vagy ez csak a partíción való tárolásra vonatkozik?
● Mennyire hat ki negatívan a teljesítményre?
● Otthoni felhasználáshoz érdemes bekapcsolni? Nyernék vele annyi helyet, hogy megérje?

Ha számít, a konfig ez:
Linux Mint 17 x86_64 /w Cinnamon
ASUS M2N
AMD Athlon64 X2 6400+ @ 3.2GHz
2x2GB DDR2-800MHz CL5
GeForce GT610
WD10EZEX-00BN5A0 a torrentes diszkem

ext* fájlrendszerek fragmentálódás

Sziasztok

Igaz a következő linken lévő bejegyzés? https://www.redhat.com/archives/ext3-users/2009-January/msg00026.html

Eddig mindig olyan kijelentésekkel találkoztam, hogy az ext* fájlrendszereket nem kell töredezettség-mentesíteni. Ezt elvégzik maguk automatikusan, így nem tud kialakulni a windowsnál megszokott töredezettség.

A link szerint csak bizonyos megkötés mellett igaz.
Tényleg így van? Az 5% többek között erre is kell? Szinte mindig 0%-t állítok be. Nem éreztem különösebben hátrányát.