Naplózó filerendszerek (journaling)

Sziasztok,

Haver akar offline mentésre/archiválásra összerakni egy gépet: HP Microserverbe (N36L) pakolna pár giga memóriát és 4 nagyobb vinyót valamilyen RAID megoldással. Ez a gép szinte folyamatosan ki lenne kapcsolva, annyi időre lenne csak bekapcsolva, ami alatt hálón rámásolja azt, amit rá akar másolni (Samba).

A srác erre a feladatra kinézte a FreeNAS-t, mert a ZFS-ről jókat olvasott, és tetszik neki az egyszerűen "összekattingatható" rendszer is. De ez nekem nagyon nem tetszik: semmilyen ZFS feature-t nem használna (snapshot, copy on write, ssd cache, stb.), de megnyerne egy elég érzékeny FS-t, amihez legalább nem is ért. (Sose üzemeltetett, nincs komoly linux/unix tapasztalata.)

Én inkább azt javasoltam neki, hogy fogjon egy CentOS-t vagy Ubuntu 18.04-et, a vinyókat tegye raid5-be (softraid) és tegyen rá ext4-et, erre a feladatra a ZFS overkill.

Érdekelne, hogy mi erről a véleményetek.

Sziasztok,

van egy szoftveres raid-es Ubuntu szerverem. Szeretnék egy olyan biztonsági mentést készíteni, ami tartalmazza azokat a config fileokat, ami ahhoz kell, hogy ha egy teljesen új gépre telepíteném fel a rendszert, akkor a ki vett winyók működjenek (elérhessem rajtuk az adatokat), azaz komplett mentésem legyen a teljes lemez struktúrámról is.
Kérdésem, hogy ehhez melyik filokat kellene lementenem? Esetleg van-e valami trükkje a dolgoknak?

Üdv.

Kalmi

Sziasztok,

hogyan lehetne a lenti ext4fs lv device-t írható módon felmountolni (Debian 9.7)? Read-only módban sikerült, fsck is volt...

mount: mount /dev/mapper/datavg-homelv on /media failed: Structure needs cleaning

Azt sajnos nem tudom megoldani, hogy felmountolom ro módban és egy másik device-re átmásolom.

Köszönöm

UPDATE: csak ez segített: read-only mountolás és külső diszkre adatmentés (2 példányban), majd lv törlés, lv készítés, formázás és másolás.

Nagyjából 2-3 kernel release óta nem tud mit kezdeni az OpenWrt/LEDE routere-em az USB portján lógó hub-ba dugott 60 GB-os pendrive-ommal. Az eszköz egyetlen partícióját f2fs-re formáztam.Ilyeneket beszél a router dmesg-je:

[ 2501.957319] F2FS-fs (sda1): Wrong segment_count / block_count (30071 > 0)
[ 2501.964545] F2FS-fs (sda1): Can't find valid F2FS filesystem in 1th superblock
[ 2501.972054] F2FS-fs (sda1): Wrong segment_count / block_count (30071 > 0)
[ 2501.979114] F2FS-fs (sda1): Can't find valid F2FS filesystem in 2th superblock

Illetve mount-ra:

mount: mounting /dev/sda1 on /mnt/pen failed: Invalid argument

111-es hibakóddal tér vissza. Ugyanakkor a pendrive-on lévő filerendszert Fedora 29-en simán felcsatoltam, semmi sem sérült. Umount után csináltam fsck.f2fs-t, hibátlan, a releváns rész:

Info: total FS sectors = 123172864 (60143 MB)
Info: CKPT version = 12356d42
Info: checkpoint state = 45 :  crc compacted_summary unmount


[FSCK] Unreachable nat entries                        [Ok..] [0x0]
[FSCK] SIT valid block bitmap checking                [Ok..]
[FSCK] Hard link checking for regular file            [Ok..] [0x0]
[FSCK] valid_block_count matching with CP             [Ok..] [0xbb33]
[FSCK] valid_node_count matcing with CP (de lookup)   [Ok..] [0x3ae]
[FSCK] valid_node_count matcing with CP (nat lookup)  [Ok..] [0x3ae]
[FSCK] valid_inode_count matched with CP              [Ok..] [0x38c]
[FSCK] free segment_count matched with CP             [Ok..] [0x7460]
[FSCK] next block offset is free                      [Ok..]
[FSCK] fixing SIT types
[FSCK] other corrupted bugs                           [Ok..]

Done.

Mit szúrtak el az OpenWrt/LEDE-ben? Amúgy 4.14.89-et futtat a TL-WR842N-v3 hardware.

Sziasztok,

Van valakinek frissebb infója hogy mi folyik BtrFS fejlesztői ágában? Wiki és hasonló offical források még mindig nem írnak semmit a titkosításról. Telnek múlnak 5 évek és semmi.

Miért? Komolyan ilyen nehéz betolni egy crypt layer-t block szinten? Nem akarom elhinni hogy ez az ok.

Vélemény?

Sziasztok!

Adott egy tavoli (tengerentuli) gep aminek a filerendszeret readonly sshfs-en probalom elerni. A savszelesseg jo, a latency viszont nagy (a ping round-trip delay time az olyan 110 millisec korul van). Egy 10 megas file atmasolasa (scp-vel) kb 5 masodpercig tart (de a latency + tcp/ip tulajdonsagai miatt elegge "lassan indul be"). Ha egy ugyanekkora file-ra kiadok egy `time cat /sshfsmount/tavoli/file > /dev/null` parancsot, akkor az is 5 masodpercig tart eloszor, masodszor pedig par tized masodpercig[*] mert ugye a rendszer szepen betette a cache-ba. Ez is szuper.

Ellenben: ha ugyanezt a file-t egy konkret alkalmazason keresztul nyitom meg, akkor az kb 4-5 percig is eltart, fuggetlenul attol hogy mar benne van-e a cache-ban (azaz megnyitottam-e korabban) vagy nem. Nyilvan az alkalmazas nagyon szuboptimalis modon olvassa be a file-t. Kerdes, hogy van-e valami finomhangolasi lehetoseg a fuse/sshfs vonalon, hogy ilyen "hulye kliensprogram" esetekben is hatekony legyen ez az sshfs-alapu atvitel? Valami olyasmirol lehet szo a hatterben hogy ez az alkalmazas kicsi (mondjuk 10k-s) blokkokban olvassa be a file-t es akkor a fuse+sshfs valahogy garantalja hogy kvazi-konzisztens legyen az atvitel. Mert a readonly mount ellenere persze _elvileg_ lehet hogy a hatterben a szerver filerendszeren valaki megvaltoztatja a file-t. Ilyesmi persze nem tortenik a gyakorlatban.

thx, A.

Van egy eléggé idegesítő hibája a szebb napokat is látott Nokianak. ExFat sd kártyára nagyobb méretű videókat úgy írja ki, hogy azokat nem lehet olvasni. A nagyobb méret miatti hiba 2GB feletti mp4 videóknál jelentkezik.
Hogyan lehet lementeni az ilyen videókat?

Sziasztok!

Egy cifs-el folcsatolt NAS adatait rsync -a val athuztam egy Btrfs-re formazott USB3-as kulso vinyora.

Minden ok, az egyetlen gond az, hogy a Deluge letolteskor letrehozza a mar letezo konyvtarat ujra(??) "deluge" owner-el. tehat van egy "root" es egy "deluge" tulaju konyvatam, ugyanazzal a nevvel...

Eddig igy volt a cifs felcsatolva:

//192.168.31.5/download/adat /home/vamp/adat cifs _netdev,user,username=****,file_mode=0777,nounix,dir_mode=0777,password==******** 0 0

Az uj kulso vinyo igy van:

UUID=********* /home/vamp/adat btrfs defaults,compress=lzo 0 1

Eddig minden konyvar a share-en "root" tulaju volt. Eredekes, ha egy masik userrel akarok letrehozni egy konyvtarat, ami mar letezik az nem engedi, de a deluge valahogy megis meg tudja csinalni...

Sziasztok!

Most tervezek osszeepiteni/felujitani egy Home servert, amihez a storage-et egy Btrfs-re formazott kulso vinyo (USB3) adja a "data" -hoz. (a rendszer egy belso 120-as SSD)

A kerdesem, hogy Windows(10) iranyba Samba vagy NFS a jobb megosztas? (teljesitmeny, stb szempontjabol)

Debian+OpenZFS van a gépemen. Mi lenne, ha egy update elrontana valamit, vagy meghibásodás miatt nem bootolna a rendszer? Vannak snapshotok, de nem vagyok biztos benne, hogy initrd-ből sok mindenre jutnék vele, vagy akár maga az initrd is lehet döglött.

Jó lenne egy live disztró, amin van OpenZFS támogatás, viszonylag aktuális. Ki ismer ilyet? A kedvencem a SystemRescueCD, de az nem tudja. Inkább gyári megoldás kellene, de ha egyszerűen rá lehet faragni egy ZFS-t egy már kész live image-re, tehetek avval is egy próbát. Telepíthetnék egy full rendszert is pendrive-ra VM-ből, de az már végképp túl sok meló.