Nagyobb méretű datasetet (több tera) replikálok -s opcióval.
A send még tart, de ha valamiért megszakad, vajon bármilyen módon hozzáférhetek a félig áttöltődött datasetben lévő adatokhoz?
Adott egy kiszolgalo, fejlesztestamogatasra hasznaljuk, a kovetkezot jatssza:
135G szabad hely tegnaprol mara elfogyott (aszongya, hogy nincs u"r az eszkozon), tehat a df szerint elfogyott a hely; du szerint a foglaltsag osszesen (rekurzivan) konstans 25G korul van, magyarul valami fog egy(?) fajlt es veszettul irja, de nem sikerul megallapitani, mi. Tipikusan hasonlot a $TMPDIR vagy valamelyik !syslog altal hasznalt log directory eseten tapasztaltam - ezek jol behatarolhato processzek voltak - ; de jo lenne, ha sikerulne megallapitani, ilyenkor mi fogja a melyik filedescriptort.
Van arra valami hasznalhato tool, hogy megallapitsam, mik az elhagyott file-k, amik mikozben latszolag nem leteznek, folyamatosan hiznak, majd reboot utan visszaall a normalis foglaltsag az erintett (donto reszben/jelenleg ext4) fajlrendszerben?
Remelem, ertelmesen meg tudtam fogalmazni, mit szeretnek elerni. :D
Koszi! :)
Sziasztok!
Adott:
Erre telepítve egyebek mellett:
kodi-standalone indulásakor szépen felmountolja a rádugott USB eszközöket (vinyók) az udisks2 által.
De akármit csinálok, mindig rw lesz az összes mount.
Próbálkoztam:
[defaults]
defaults=ro
allow=noexec,ro,...
Hiába veszem ki allow-ból is az rw-t, mégis rw lesz minden mount.
Tudom, hogy udev rules-ban felül lehetne bírálni, de érdekel, hogy az udisks miért disrespecteli a konfigomat.
Mit rontok el?
Mivel egyébként sincs szükség rw hozzáférésre (ha mégis, akkor ssh-n remountolom), így igyekszem elejét venni a fájlrendszer korrumpálódásának, ha pl. valaki umount nélkül kihúzza.
Arra van mód, hogy az ro-ként mountolt eszköz kihúzásakor az udisks2 felismerje mi történt és eltakarítsa a romokat? (adjon egy lazy umount-ot mondjuk, hogy kikerüljön az eszköz a mount táblából).
Otthona konfigom Fedora31 külön /boot, /boot/efi, /, és /home partíciókkal EXT4-ekkel.
BTRFS-ről pedig azt olvastam, még korábban, hogy elég lesz 1 BTRFS partíció mindenre és ez - the way it meant to be played.
OK.
Majd egy évvel később újratelepítéssel frissítem a Fedora 33-at.
EXT4 esetén formáznám a /boot és / partíciókat, de mi a scenario BTRFSsel?
Ha jól értem Size / data min_size 3/2 értékénél 3 lemez 3 osd esetén 1 lemeznyi szabad helyem lesz a poolban?
És a 33% legjobb érték, a többi "értelmes" érték ennél kevesebb.
Építettem egy NAS-t egy Banana Pi single board computer és egy darab SATA hdd használatával.
A hdd-n jelenleg a korábbi dLink NAS által létrehozott ext4 fájlrendszer van, ami egyébként jól működik.
A dLink eszköz több olyan partíciót is létrehozott, amit most senki semmire nem használ, ezért az egész hdd-t újra akarom építeni. Lesz egy nagy partíció és titkosítás.
Az merült fel bennem, hogy ha már úgyis mindent újraépítek, akkor esetleg az ext4 helyett is lehetne más.
A hdd eléggé tele van, viszont elég sok a duplikáció is. Ha jól emlékszem, a btrfs és a zfs is tud blokkszintű deduplikációt. Ennek örülnék.
Nem tudom, más előnye lenne-e zfs-nek vagy btrfs-nek (van más fs még esetleg, ami szóba jöhet?). Snapshot-ot RAID-et meg ilyesmiket nem tervezek használni, ez a NAS leginkább backup célra szolgál, illetve mesefilmeket szoktak a gyerekek nézni róla a TV-n.
A kérdésem igazából az, hogy a BPi szűkös erőforrásai elegendőek lehetnek-e egy zfs vagy btrfs számára. Úgy emlékszem azt olvastam, a zfs-nek sok memória kell. Az nem zavar, ha a deduplikációs keresgélés sokáig tart, ha később, amikor már nem kell a deduplikációval szüttyögni, akkor normális (vagyis kb. a mostani) sebességgel tudja az olvasásokat és írásokat kiszolgálni.
Ilyen eszközt vettem: http://wiki.banana-pi.org/Banana_Pi_BPI-M1%2B
2 magos ARM Cortex-A7 processzor 1GHz órajellel, 1G RAM
Sziasztok! Egy kisméretű céghez szeretnék distributed file system -et telepíteni, két darab Linux-os gépre. Az lenne az ötlet, hogy egy sima tükrözött merevlemez helyett két darab webdav kiszolgálót csinálnék. Ennek az lenne az előnye, hogy ha tönkremegy az egyik gépen BÁRMI akkor még a másikon keresztül el lehet érni az állományokat. Ezt azért szeretném így, mert sajnos már előfordult hogy táp hiba miatt leállt az egész és ki kellett mennem. Az szeretném elérni, hogy 100%-os redundancia legyen. Tehát ha az egyik gépben tönkremegy bármi, a szolgáltatás akkor is elérhető maradjon, és ne kelljen azonnal rohannom a céghez.
A következő kérdések merültek föl bennem:
* Ha a DNS nevére round robin van, akkor a Windows 10 webdav-os mount azt jól kezeli? (Tehát pl. elszáll az egyik gép akkor a HTTP request átmegy a másik gépre automatikusan?)
* Milyen DFS-t használjak? Semmi tapasztalatom nincs ebben, ezt olvasgattam: https://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems ez alapján a sok zöld cellás megoldások érdekelnek. Melyik az ami hibatűrő, és nem igényel nagyon sok konfigurálást? Előnyt jelentene ha lehetne snapshot-okat csinálni, de enélkül se rossz.
* Extra webdav-os kérdés: eddig még mindig Samba-t használtam, de nagyon eljárt fölötte az idő. Ha áttérek WebDav-ra akkor milyen szintű kompatibilitási problémákra számítsak? (Azt tudom hogy logon script nem lehet webdav meghajtón, de erre nincs is szükségem, nincs domain controller a cégnél.)
Ja és bocsánat ha rossz kategóriába írtam, nem találtam jobbat.
Köszönöm!
Sziasztok!
Most hogy nagy ZFS lázban ég a fórum, a kérdésem az hogy ha az extra képességek nem kellenek, mindössze a snapshot képesség esetleg tömörített fáljtárolás és persze mindez stabilan, akkor milyen hátrányt jelent ha nem a nagyágyút (ZFS) vetem be, pusztán Btrfs-t?
Érdekelnek az előnyök, hátrányok. Például előny, hogy a Btrfs teljesértélű része Linux kernelnek, ez a ZFS és Linux kernel viszonyáról közel sem mondható el. De mi szól a Btrfs mellett és milyen esetben használjunk inkább ZFS-t Linux esetén?
Sziasztok!
Éppen egy varázslatos "apt install zfs-dkms" parancsot futtatok Debianon.
Valaki meg tudja mondani, miért van a Makefile teli sleep-pel a fent említett kernelmodul fordításakor?
root 522 0.0 0.0 9792 3460 pts/0 S 23:08 0:00 | \_ su -
root 523 0.0 0.0 7796 4740 pts/0 S 23:08 0:00 | \_ -bash
root 1055 0.7 0.3 65416 55864 pts/0 S+ 23:10 0:01 | \_ apt install zfs-dkms
root 1892 0.0 0.0 12368 6240 pts/1 Ss+ 23:11 0:00 | \_ /usr/bin/dpkg --status-fd 23 --configure --pending
root 1896 0.1 0.1 24904 18996 pts/1 S+ 23:11 0:00 | \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/zfs-dkms.postinst configure
root 1907 0.0 0.0 2388 756 pts/1 S+ 23:11 0:00 | \_ /bin/sh /var/lib/dpkg/info/zfs-dkms.postinst configure
root 1912 0.0 0.0 2388 1644 pts/1 S+ 23:11 0:00 | \_ /bin/sh /usr/lib/dkms/common.postinst zfs 0.7.12 /usr/share/zfs-dkms
root 2034 0.0 0.0 8504 5324 pts/1 S+ 23:11 0:00 | \_ /bin/bash /usr/sbin/dkms build -m zfs -v 0.7.12 -k 4.19.0-6-amd64
root 2053 0.0 0.0 8636 4664 pts/1 S+ 23:11 0:00 | \_ /bin/bash /usr/sbin/dkms build -m zfs -v 0.7.12 -k 4.19.0-6-amd64
root 2146 0.4 0.0 11332 10604 pts/1 S+ 23:11 0:00 | \_ /bin/bash /var/lib/dkms/zfs/0.7.12/build/configure --prefix=/usr --with-config=kernel --w
root 3283 0.0 0.0 2296 752 pts/1 S+ 23:13 0:00 | \_ sleep 1
Üdv!
Mappánként sok apró fájllal kéne dolgoznom. A sok alatt 1-2 millió fájl értendő, az apró alatt meg 100byte - 10kbyte. Arra már rájöttem, hogy az ext4 erre nem alkalmas. A sima ls parancs is kifekszik, kb. 10-15 percig semmi életjel, azután kezdi el köpködni a fileneveket, de az is hatalmas idő lenne, míg a végére érne. (fél óra után is írja a fájlokat).
Amivel létrehozom ezeket a fájlokat, eleinte gyorsan jönnek létre a fájlok, de ahogy egyre több van, egyre lassabb.
Nekem úgy tűnik, hogy a szűk keresztmetszet nem csak a hardverben keresendő. Az ls parancsnál pl. a processzor volt 100%-on, a lemez nem nagyon kerregett.
Mielőtt nekiállok kísérletezni, kíváncsi volnék, van-e valakinek tapasztalata/megoldása ilyen problémára?