Fs kerestetik

Naplózó filerendszerek (journaling)

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.

  • 2289 megtekintés

( bazso | 2015. 10. 09., p – 06:59 )

Marmint az fs metaadatait? Mintha mondjuk a FAT tabla masik diszkre rakhato lenne? Mi a varhato nyeresege ennek?

( tompos v | 2015. 10. 09., p – 09:07 )

zfs, btrfs, xfs, ext4, de valoszinuleg a jfs is ilyen

Tovabba a distributed fs-ek legnagyobb resze ilyen.

ZFS
-----
zfs create tank mirror sda sdb mirror log sdc1 sdd1 cache sc2 sd2

A log es a cache hatarozza meg, wtf.

Bar a cache nem az, amit keresel, de azt is valoszinuleg be akarod allitani.

ext4
-----
-J journal-options
Create the ext3 journal using options specified on the command-line. Journal options are comma separated, and may take an argument using the equals ('=') sign. The following journal options are supported:

size=journal-size
Create an internal journal (i.e., stored inside the filesystem) of size journal-size megabytes. The size of the journal must be at least 1024 filesystem blocks (i.e., 1MB if using 1k blocks, 4MB if using 4k blocks, etc.) and may be no
more than 10,240,000 filesystem blocks or half the total file system size (whichever is smaller)

location=journal-location
Specify the location of the journal. The argument journal-location can either be specified as a block number, or if the number has a units suffix (e.g., 'M', 'G', etc.) interpret it as the offset from the beginning of the file system.

device=external-journal
Attach the filesystem to the journal block device located on external-journal. The external journal must already have been created using the command

mke2fs -O journal_dev external-journal

Note that external-journal must have been created with the same block size as the new filesystem. In addition, while there is support for attaching multiple filesystems to a single external journal, the Linux kernel and e2fsck(8) do not
currently support shared external journals yet.

Instead of specifying a device name directly, external-journal can also be specified by either LABEL=label or UUID=UUID to locate the external journal by either the volume label or UUID stored in the ext2 superblock at the start of the
journal. Use dumpe2fs(8) to display a journal device's volume label and UUID. See also the -L option of tune2fs(8).

Only one of the size or device options can be given for a filesystem.

Amugy a man-t olvasom..:)

De elgondolkoztam, mit is akarsz kulon tarolni? Milyen metaadatot?

Pont ezt kérdezem én is, hogy milyen metaadatról van is szó, mert a ZFS-nél a LOG és Cache külön SSD-re helyezése valóban javíthat a teljesítményen, de attól még az i-node tábla, meg a FS saját superblock-ja (ezek szerintem az igazi metaadatok), valamint a könyvtárfa (ezen már lehet vitatkozni, hogy belevesszük-e a metaadatok közé) azok ugyanott lesznek, ahol a fájl adatok. Valamint jelzem én is úgy tudom, hogy a jfslog rakható önálló diszkre - "mkfs.jfs -j /dev/izémizé ...". Valamint ezen kívül a XFS logja is rakható önálló diszkre (mkfs.xfs -l logdev=/dev/izémizé ... ), meg a ReiserFS-é is (mkfs.reiserfs --journal-device=/dev/izémizé ).

Szóval mire gondolt a költő?

Elolvastam és erős kétségeim támadtak. 50-300%-nyi teljesítménynövekedés az elterjedt linuxos FS-ekkel szemben mikro- és makro benchmarkok szerint. Ráadásul úgy, hogy az adat/metaadat terület lehet akár ugyanannak a diszknek 2 külön partíciója is. Ezt írják ők:

"And all this performance advantage is a direct result of the separation of the meta-data and data."

(Hangosan morfondír)
A klasszikus SystemV -os filerendszerek (S51K, S52K, stb) felépítése:
- diszkeleje superblock
- SB után inode-tábla
- i-node tábla után adat (amiben a könyvtárstruktúra is található)

No most, ez így egyben a diszken (de ha úgy tetszik, egy diszkpartíción).

Nehezen tudom elképzelni, hogy az a tény, hogy az i-node-tábla mögött húzunk egy vonalat, és azt mondjuk, hogy ami előtte van az egyik partíció, ami mögötte van az pedig egy másik partíció - szóval hogy az a vonal ott akkora hatással lenne a teljesítményre. Azaz nyilván a szétválasztás helyett sokkal inkább számít a belső struktúra, vagy épp a szabad területek előbányászásához használt algoritmus. Netán az, ami szintén szerepel, azaz hogy a metaadat területek kezelésénél spórolnak mindenféle I/O műveleteket.

Ha ehhez hozzáteszem azt, hogy a cikk szerint kb 2000-től 2007-ig ját^H^H^Hfejlesztették, és én (meg tán a többség) azóta se hallottam róla, nekem azt súgja, hogy valami bibi van. Pl:
- élesben nem úgy muzsikált, mint a benchmarkokban
- kiderült, hogy nem bírja ha törölnek benne
- az elméleti PB-os határral szemben gyakorlatban csak 2 GB-ig jó a teljesítménye
- stb

Szóval most már értem a felvetésed, de ha jobban megnézed, ennek nagy részét a jelenlegi FS-ek nyújtják: ha nem is az egészet, de a metaadatok egy jelentős részét (nevezzük "LOG"-nak :-) ) át tudod tenni másik diszkre, és ha ez egy sokkal gyorsabb SSD, mint amilyen lassú az adattárolásra használt HDD, akkor akár látványos teljesítményjavulást is el lehet érni.

Hozzáteszem, sose fejlesztettem fájlrendszert, ezt csak a józan paraszti ész mondatja velem - bárki nyugodtan megcáfolhat.

Jogosak a felvetéseid, bennem is fogalmazódtak meg kételyek. Sőt bennem az is felmerült, hogy beolvasztásra került valamelyik modern fs-be. Sajnos nem, legalább is egyenlőre nem találom.

Egyébként nem a lehetséges teljesítmény javulás birizgálta meg a fantáziámat (a modern fs-ek - mint írtad is - már nagyvonalakban kiaknázták ezt a lehetőséget), hanem security feature-t látok benne.