Naplózó filerendszerek (journaling)

Azt mondja hogy 3.5-ös verziójú kerneltől felfelé működik a fallocate mondjuk sshfs-sel:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?…

Ennek ellenére, 3.9.6-1 Debian testing kernellel és 2.9.2-4 verziójú fuse-val az alábbi hibaüzenetet kapom az aria2c nevű programtól:

Exception: [AbstractDiskWriter.cc:496] errNum=95 errorCode=17 fallocate failed. cause: Operation not supported

Mi kellene még ahhoz hogy menjen a dolog? A prealloc-ot szeretném lecserélni.Verziószámok:

Az experimentalban lévő changelog szerint a 2.9.1-es verziójú utility-ben már szerepel a képesség:

fuse_2.9.3-3_amd64.deb/deb://CONTENTS/usr/share/doc/fuse

2012-07-19  Miklos Szeredi <miklos@szeredi.hu>

        * Released 2.9.1

2012-07-19  Miklos Szeredi <miklos@szeredi.hu>

        * Fix crash caused by freeing a stack address.  Reported by Itay
        Perl

2012-07-04  Miklos Szeredi <miklos@szeredi.hu>

        * Fix install of mount.fuse from out-of-tree build.  Patch by
        Olivier Blin

        * Fix build with automake >= 1.12.1.  Patch by Olivier Blin

2012-04-24  Miklos Szeredi <miklos@szeredi.hu>

        * Add fallocate operation.  Only works on linux kernels 3.5 or
        later.  Patch by Anatol Pomozov

Az unstable-ban is elérhető:

# aptitude changelog fuse
fuse (2.9.1-1) unstable; urgency=low

  * Merging upstream version 2.9.1.

 -- Daniel Baumann <mail@daniel-baumann.ch>  Fri, 21 Sep 2012 19:07:33 +0200

Az upstream kiadás szintén a 2.9.1 NEWS fájljában tesz először említést róla:

Add fallocate operation (linux kernel 3.5 or newer)

http://sourceforge.net/projects/fuse/files/fuse-2.X/

Sziasztok,

adott egy 160G sata hdd, amin windows 7 lakott.
Fogtam, szépen lementettem dd-vel az egészet cakk-pakk, és utána instaláltam rá egy linuxot.
Most úgy néz ki, hogy amire lementettem a windowst winyó, haldoklik és nem nagyon tudok semmit kezdeni vele.
Milyen toolal áljak neki megpróbálni visszatúrni a ntfs alatt fileokat arról a winyóról amit újratelepítettem (ha lehet)?

Köszi, Andris

Udv!

Akadt egy HW- hibam a jelen laptoprol irt vinyomon. Eloszor a grub nem bootolt be, es ez maradt is, de boot cd- rol bebootolva azt tapasztaltam, hogy az sda1 particiom masodik 4K- s blokkja nem olvashato, az osszes tobbi igen (legalabbis az elso 1 gigaban). Az egesz particiora a cfdisk azt mondja, hogy 57529.08 MB nagy, ezenkivul csak egy extended swap particio van sda5 neven 2479.89 merettel (miert ilyen nagy?).

Nos, a kerdesem az lenne, hogy az adataimat hogyan tudnam errol a vinyorol megmenteni. Az elso 4K- s blokkot le tudom menteni, es a 3. 4K- s blokktol is mindent, de mi a helyzet a masodik blokkal? Ext3- rol van szo, nem ismerem a fajlrendszer felepiteset, de feltetelezem ennyire az elejen meg metaadatok vannak, vagy valami hasonlo, ami nagyon kell :- ).

Koszi a valaszokat!

Üdv!

Készítek egy backup szervert Debian alapon amin a zfs-t ki akarom próbálni.
Telepítettem forrásból.
Létrehoztam a pool-t 3 disk ből raidz vel.

Létrehoztam rajta "al-poolt" és felcsatoltam a /nfsbackup könyvtárba
a poolban újraindulás után az egyik disk nem jött fel (a régebben volt egy szoft raid és az bekavart ) így a tömb degradált lett , de működött.
Másolgattam rá mind rendben volt.
Rsnapshottal este csináltam egy mentést a szerverekről.
A mentések rendben lefutottak.

zfs list
NAME USED AVAIL REFER MOUNTPOINT
backup-pool 256G 1,49T 192K /backup-pool
backup-pool/nfsbackup 255G 1,49T 255G /nfsbackup
backup-pool/nfsxenimage 181K 1,49T 181K /backup-pool/nfsxenimage

látható hogy a tömbön 255G hely foglalt
viszont a a /nfsbackup ; /backup-pool ; /backup-pool/nfsxenimage könyvtárak üresnek látszanak.

azóta volt egy reboot reggel (a rsnapshot futása után)
és a hiányzó disk is visszajött és reszinkronizált

a hely továbbra is foglalt csak a mentés nem található.

zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
backup-pool 2,58T 305G 2,28T 11% 1.26x ONLINE -


A zfs-hez értőket kérdezném hol mehetett félre a dolog, Zfs hiba ?

Üdv Robit

Tisztelt fs guruk !
A problémám vszleg nem ext3 specifikus, de hátha.

Egyszer hiba miatt a diszken az ext3 fs erroros lett.
Ezért aztán következő bootnál lefut az fsck.
(... contains a filesystem with errors, stb.)
Végigrágja a diszket, aztán tovább megy a boot.
Viszont a következő bootnál megint ugyanígy lefut.

Megcsináltam, hogy ctrl-C-t nyomok, mikor kezdi az fsck-t, ekkor kér egy root pw-t és r/o módba mountolva kapok egy root shellt.
Abban futtattam egy
tune2fs -l /dev/sda1
-et.
Filesystem status: clean.
(és a mount countok meg max idő az fsck között ki van kapcsolva.)

Ezután kézzel lefuttattam az fsck-t:
fsck.ext3 -p azaz auto repair. Lefut, exit státusz 0.

Ha utána újra futtatom, akkor kapásból leáll, mert az fs státusza clean.

Nézegettem az S10checkroot.sh scriptet, ami ezt csinálja. Abban van lehetőség az fsck skippelésére, ha létezik a /fastboot file v. fastboot kernel command line param, illetve a mindenképp fsck-ra, ha van egy /forcefsck file v. kernel param. De egyik sincs, legalábbis az fsck futtatásakor nem leltem.

Amit nem értek:
Ha a tune2fs szerint clean a partíció, akkor az fsck miért minősíti hibásnak ?
Ill. hogy lehet lebeszélni róla, hogy mindig lefusson ?

A google nem segített, scriptet írni viszont nincs kedvem, mert túl bonyolultnak tűnik a probléma fontosságához képest. Úgy érzem, mégis egyszerű lesz a megoldás.

Van egy xfs fájlrendszerem, amin nincs beállítva a 'noatime' flag. Ezen a fájlrendszeren egy könyvtárban van néhány száz fájl, amiket egy zárt forrású program a futása idején olvasásra megnyithat, lezárhat, majd akár újra megnyithat (írás nincs). Egyszerre több fájl is lehet nyitott. Egy-egy fájl megnyitási gyakorisága általam nem jósolható meg. Létezhet olyan, hogy a futás alatt valamely fájl sosem kerül megnyitásra.

Hogyan tudnám megoldani, hogy a program futása alatt összeszámolódjon, melyik fájl hányszor került megnyitásra? Strace szerintem ágyúval verébre, de ha nincs más...

Solution: inotifywait command.

milyen lehetosegei vannak az embernek ma linuxon (akar 13.04 is erdekel mar), ha szeretne dedup/compressiont?

blokk szinten lenne a legjobb (LVM voluemokon, amiket iSCSI-n kiajanlok, vagy akar alatta, a PV-n), de erdekelne FS szinten is.

tenyleg csak btrfs vagy fuse-zfs jon szoba?

régóta fut egy winchesteremen bad block check, és a százalékos értékből úgy látom, hogy még több óra kell, hogy végezzen. sajnos meg kellene bootolnom a gépet rövidesen. legjobb tudomásom szerint read-only checket végzek (fsck.ext4 -c), és így biztonságosan megszakítható. a neten mindenféle érdekeset lehet olvasni, de sehogyan sem áll össze nekem konzisztens egésszé.

röviden tehát: a 'fsck.ext4 -c' command megszakítható-e biztonságosan?

Sziasztok

Érdekes gondom van, egy rég elfeledett szerver rég elfeledett winyojáról kellett volna előszednem egy kis anyagot.
a winyot mikor uj helyére betettem néhány könyvtár (nagyrészt pont azok amik kellenének) kb igy néznek ki:
d????????? ? root root ? ??? ?? ??:??:?? ezkellnekem1
gondoltam kicsit sérült a winyó ezért ráküldtem a e2fsck-t ami minden ilyen könyvtárat benyomott a lost+found-ba szépen elnevezve 1-99999999-ig de ha keresgélek köüzöttük akkor nem találom ami kell nekem (ez egyszerü mert *.DB kiterjesztés egy sincs)
kérem valaki mondja meg mi ez és hogy tudom esetleg még visszahozni.
Előre is köszönöm

Immaron majdnem egy hete hasznalok a Fedora Linux 17-et futtato laptopom kozos tarhelyen ZFS-t. Mukodik is, teljesen jol, minden faja, egy gondom van: borzalmasan lassu az olvasas rajta. Mintha nem lenne mogotte meg disk cache sem.

Jelenleg egy 2.10GHz -re hitelesitett i3-mal es 4G RAM-mal ellatott Lenovo G570-en fut egy Samsung winyon a cucc, es erzesre ket-haromszor lassabb olvasasom van rajta, akkor is, ha olyan fajlokat olvasok fel, amiket mar egyszer felolvastam. Konkretan: most par napig egy darab Rails projekten dolgoztam, relative keves fajlt modositva (a betoltott fajlok szamahoz kepest keveset), es a konzol meg ket egymas utani inditasnal is bunlassu volt, pedig tapasztalatbol tudom, hogy altalaban a masodik inditasra mar nem kell szinte egyaltalan varni ra.

Igazabol nem tudom, mit merjek, hogy teszteljem a dolgot. Azt tudom, hogy a disk, ami benne van, nem egy gyors darab - de hat elvben errol szolna a disk cache, hogy ezt megoldja, nem?

Mas: van olyan verzio a ZFS-bol ami tamogatja az inotify-t? Egy kazal minden epitene erre a kernelszolgaltatasra, de minden csak nyivakol, hogy ezt a fajlrendszert o nem ismeri, es nem is tudja rajta elerni az inotify szolgaltatast.