Mindig így szoktam csinálni a fájlrendszer csökkentést, ahogy lejjebb mutatom. Eddig nem volt gond. Ez így hülyeség, és eddig csak szerencsém volt? Vagy ez most véletlen egybeesés, és ne törődjek vele? (A második fsck által talált hibák bizonytalanítottak el).

Mennyire eletkepes gondolat egy Linux alapu servert pendrivera installalni, es arrol mukodtetni, hogy megmaradjanak a SATA csatlakozok a RAIDnek ?
Gondolok itt arra, hogy mekkora esellyel hibasodik meg a pendrive, vagy megy tonkre a mukodestol.

Igaz az, hogy erdemes ext2-vel hasznalni, vagy ezt is csak mondogatjak, de nem tamasztja ala bizonyitek ? (Allitolag a journaling nem tesz jot a flasnek, de a Google is ext4re valtotta az jffs-t a telefonjain, nem tudom mit gondoljak ezutan)

Elég 512Mb ram Btrfs-nek? Vagy inkább Ext3?

A kérdés adott, arra lennék kiváncsi, hogy lehetséges e egy Ext4-es partíciót adatvesztés nélkül NTFS partícióvá konvertálni?
Egyrészt idő megspórolása miatt lenne érdekes, másrészt pedig azért, mert nincs helyem biztonsági mentést csinálni.

Köszi!

Attila

Sziasztok,

az egyik ügyfelem egy partícióját, amin korábban is ugyanúgy ext3 volt, véletlenül újraformázta és írt rá pár fájlt.

Szerintetek van esély valahogy visszaszerezni a korábbi fájlok maradékát?

Elindítva úgy érzem, a testdisk kevés lesz ehhez, olvasgattam ilyeneket:

http://www.linuxquestions.org/questions/linux-software-2/recover-formatted-ext3-partition-631592/

http://www.cgsecurity.org/wiki/Advanced_Find_EXT2_EXT3_Backup_SuperBlock

Ma estére szeretnék a közösség erejével jutni vele valamire. TI hogy állnátok neki?

Sziasztok!

a minap feltettem ce'l-debiant (voyage) egy alix.6e1-re. 4gigas cf-kartya'ra. a /var bizonyos resze es a /tmp tmpfs-kent vannak fent (/var/tmp, /var/run, /var/log, kb.), igy most az `lsof` szerint egy futo rendszerben nincs csak irasra nyitott file a / alatt. a / maga egy ext2 particio hogy journal commit ne legyen. ezzel az egesz konfiggal merul(t) fel par dilemma, ha valakinek van otlete/tapasztalata, azt megkoszonne'm!

tehat, ezek:

Hello

Most hogy penteken megjelent a ZFS Linuxra (mint a fooldalon a hirek kozott olvashato), mikent lehet azt a gepunkre varazsolni ? Mert a ceg oldalan tovabbra is csak a betara valo regisztracio lehetoseget talaltam.

Illetve mennyire stabil megvalositas ez vajon ? Varhato hogy esetleg a jovoben fabrikaljak, es az adataim elvesznek emiatt ?
Szoval mennyire stable ez a "stable" ?

BIGFILE egy 3.5G-s file. A következő jelenséget produkálja. (Más, kisebb (1G) fileokkal is könnyen reprodukálható a jelenség ... ) Mi lehet a gond? Disk? Memória?

[code]

SERVER:/tmp# md5sum BIGFILE
b42c7584c2af4cd8396d831e0e4bbb59 BIGFILE

SERVER:/tmp# md5sum BIGFILE
cbcec11bb82bb983a26615c7863bf793 BIGFILE

SERVER:/tmp# md5sum BIGFILE
7fddcbc38cbf17c7235726cb476d3c49 BIGFILE

SERVER:/tmp# md5sum BIGFILE
85fdfdd74dec330cad58b636c9bf9bfc BIGFILE

SERVER:/tmp# echo "1" >/proc/sys/vm/drop_caches
SERVER:/tmp# md5sum BIGFILE

Egy ideje használok Btrfs fájlrendszert:

/dev/disk/by-id/ata-TOSHIBA_MK2546GSX_97PKF24HS-part6 /home                btrfs      defaults,noatime 1 2

Elvileg van szabad hely:

Fájlrendszer          1K-blokk   Foglalt    Szabad Fo.% Csatl. pont
/dev/sda6             12578860  10702400   1876460  86% /home

Átmásolnék rá egy fájlt:

# ls -l /tmp/test.zip
-rw-r--r-- 1 auth.gabor users 190165248 2009 dec 15 /tmp/test.zip
# cp /tmp/test.zip /home/
cp: ”/home/test.zip” írása: Nincs több hely a lemezen

Adott egy fájlrendszer, amin van több, mint 15 millió apró fájl. Jelenleg ext3, mert bevált és stabil.

Éjszakánként azonban rákergetek egy rsync-et, backupolás céljából. Mivel a fájlok többsége nem változik, így tényleges másolás szinte alig történik, viszont a könyvtárlista készítése (fstat) több óráig is eltart, amíg veszettül seekel a diszk.

Ha van valakinek valami ötlete, hogy hogyan lehetne optimalizálni ezt a folyamatot, akkor nosza, mondja!

Oké, nyilván, az SSD egyfajta megoldás, mert nem kell rajta fejet pozícionálni :)

Szeretnék áttérni freebsdre (7.x-stable), de az adatokat ugyanúgy el akarom érni később linuxról is (gentoo, 2.6.30), szóval kell egy fs az adatoknak, amit mindkettő visz. Elsőre xfs, nfs jutott eszembe, amit mindkettő visz, de az xfsről azt hallottam, hogy hw hibákra és crashekre érzékeny, könnyen eltűnnek olyankor az adatok a cache-elés miatt, de nem tudom, lehet-e gyakoribb syncelésre állítani, van-e értelme egyáltalán annak. NFS pedig inkább végső megoldás lenne, mert nem megosztani akarom, így lehet, hogy felesleges tököléssel járna.

Sziasztok,

van egy friss telepitesu rendszerem, amin a df -h es mount nem latjak a a raid1 tombot. Debian stable, ext3, mdadm. A df -h /dev/md0-ra a /dev jelenik meg. Egy merevlemezen van a /boot, / es swap, 2x2TB merevlemezen meg a raid1 /home. Az mdadm --detail helyesen latja a particio meretet. A kerdesem az lenne, hogy ez a 2TB-nak koszonheto-e, valamint hogyan lehet a helyzeten segiteni. Egyelore nem talaltam tul sok hasznosat.

Koszonom.

Teszteli valaki közben Debian testing ágban a Btrfs-t?

Kíváncsi lennék hogyan áll megbízhatóság terén. Compression és dedup miatt lenne érdekes, meg úgy egyébként.

szerk.: közben benéztem a wiki-ben és látom hogy a deduplication még csak tervben van.

szerk2.: az ext4 wiki oldalán található infó szerint:

Transparent compression No
Transparent encryption No
Data deduplication No

egyik ext4 partíción eltűnt minden szabad hely, pedig a valóságban lennie kellene.
Fájlrendszer Méret Fogl. Szab. Fo.% Csatl. pont
...
/dev/sdb9 776G 737G 0 100% /media/sdb9

umount/remount, ill fsck.ext4 -f /dev/sdb9 majd reboot után is ugyanez a helyzet.
mit lehet tenni? vagy itt csak a backup&format segít?

Update,
nem ez az első ilyen eset.

Van valami megoldás linux alatt a fenti (ring-buffer, circular-buffer) fájlrendszerre?
Ha nem létezik ilyen, valami más megoldás arra, hogy van egy kötet, amibe folyamatosan
kerüölnek bele a fájlok, és ha a kötet mérete közelít a maximálishoz, akkor a régebbi fájlokat törli?

Köszi

(ez esetleg megfelel erre a célra?: LinLogFS - http://www.complang.tuwien.ac.at/czezatke/lfs.html)

Nincs szerencsem a naplozo fs-ekkel :) Jopar eve ext2-rol ext3-ra valtva nem naplozott, akkor reiserfs ment fel, ott a nagy file-ok mozgatasanal elofordult, hoyg lefagyott es se a celhelyen, se a forrashelyen nem votl meg a file.
Aztan jott az etch ext2 fs-t atallitom ext3-ra: http://hup.hu/node/67652

Ismeri valaki? Esetleg van valakinek, aki segítene megmenteni egy 100 és egy 300 GB-os adathalmazból, amit lehet?

Sziasztok,

van olyan linuxos fájlrendszer, amely ntfs-hez hasonló acl-ekkel rendelkezik?

A cél a következő lenne: egy linuxos storaget szeretnénk építeni, amely továbbosztaná a többi gépnek a tárterületet (nfsv4-en a linuxos szervereknek, sambán a win2k8-as szervernek). A gond ott van, hogy a win2k8-as szerveren roaming profile-ok vannak, amelyek igényelnek néhány spéci ntfs-es jogosultságot (jelenleg openafs-t használunk samba-val kiegészítve, de az openafs tudtommal csak az alap linuxos acl-eket támogatja - posix acl kiegészítés nélkül -, így nem jó).

érdemes új winchesterre ext4 fájlrendszert feltenni?
általában reiserfs volt amit használok. eddig meg voltam elégedve vele. bár a BKL néha zavaró. kérdés, hogy 1Tb méretű partícióknál is optimális e még? vagy inkább ext4? esetleg jfs? vagy xfs?
régebben használtam xfs fájlrenszert is. remek olvasási teljesítményt nyújtott, a fájltörlés viszont lassú volt. a nagyobb hibája pedig az volt, hogy nagyon rosszul tolerálta az "áramszünetet" és a "takarítónénit":)