Dotaz: digiKam - jak vam funguje? RYCHLOST nacitani fotek

[petrfm]

Ahoj, chtel bych si roztridit archiv fotek a videi pomoci digikamu. Moje predstava je takova, ze budu mit fotky ulozeny na mem domacim serveru s bananaPi a sambou a pomoci SMB4K si je mountuju do /home

Potom si na notebooku ten adresar s fotkami na sambe pridam mezi alba v digikamu a budu tridit a pracovat s nimi.

Soucasne se k fotkam dostanu i z televize, kde mam multimedialni centrum a mam pristupny ten samba share - kdyz prijde navsteva atd.

Vsechno funguje, jenom mne docela zarazi, jak dlouho si digikam nacita info o fotkach. Po spusteni to trva i dele, jak deset minut. Je tam asi 350GB fotek ve 20 000 souborech. Presto si myslim, ze prece neni nutne, pokazde je nacitat znovu, takze jsem to chapal pri prvnim pridani, ale ne po dalsim spusteni.

Jak Vam to funguje s vetsim mnozstvim fotek? A jak to resit? Rozdelit si alba na roky a pracovat jen s jednim rokem, aby tam toho bylo mene?

Muze byt na vine pomala samba? Da se nejak odzkouset, jak rychly je prenos v pripade, ze pristupuji k velkemu mnozstvi souboru? Mam totiz podezreni, ze prenos jednoho velkeho souboru je docela OK, ale prenos vetsiho mnozstvi malych souboru uz je prusvih - fotky jsou totiz na serveru ulozene v sifrovane slozce, kvuli pripadne kradezi disku.

Odpovědi

[Sten]

DigiKam pouze projde seznam souborů, aby věděl, které jsou nové či změněné, a teprve ty indexuje. Mám přes NFS „jen“ 8 000 fotek, ale DigiKam se spouští asi 10 sekund (na notebookovém disku se šifrováním) a synchronizaci databáze věnuje něco kolem sekundy.

Problémů je tam víc:

1. BananaPi není zrovna výkonný a šifrování ho bude dost ubíjet
2. SATA na BananaPi je bez DMA, což je další zabiják výkonu
3. Samba nepatří mezi výkonově nenáročné protokoly
4. (Samba možná hlásí špatné údaje o času souborů, takže DigiKam celou databázi vždy reindexuje)

Já bych to řešil výměnou serveru za něco výkonnějšího a pro připojení toho disku k Linuxu bych použil NFS.

[petrfm]

Diky za rychlou odpoved. Asi na tom neco bude. Pri kopirovani velkych souboru ten banan nema problem, ale i pri zobrazeni nahledu fotek se mi zda, ze se to dost louda.

Druhy problem, ktery jsem zaznamenal, ze kdyz si dam pres dolphina zobrazit velikost slozky, tak jednou mi ukaze 100MB, potom 101, pak zase 99 atd. Vubec nechapu proc? Meni se i pocet souboru. Dost mne to prekvapilo.

Asi se hecnu a objednam v lednu konecne x86 desku a vykaslu se na ty experimenty se zeleninou

[petrfm]

Jinak NFS jsem jednou zkousel a vubec se mi nepodarilo primountovat ten disk. Nerozchodil jsem to proste. Navic pouzivam v siti i androidy a tam pokud se nepletu, NFS nerozbeham.

Druhy duvod, proc NFS ne, je naprosto tristni zabezpeceni, zadny ucet, zadne heslo, jakekoliv zarizeni s rootem v siti se mi prohrabe ve vsech slozkach na serveru, ne diky.

[Sten]

Samba není šifrovaná, takže to zabezpečení je také dost na pytel.

NFS umí autorizaci i šifrování, ale používá se Kerberos a není moc jednoduché to rozběhat. Lézt jen do těch složek, které exportujete.

Pokud chcete snadné nasazení, zabezpečení a podporu na Androidu, tak HTTPS/WebDAV funguje dobře snad na všem.

[petrfm]

Tak ze neni sifrovana mi v lokalni siti jaksi nevadi, nepredpokladam, ze by mi tu nekdo nasadil nejaky sniffer. Co mi vadi je fakt, ze mi kdejake udelatko vleze do vsech slozek.

Rozbehavat Kerberos? ne, diky. A proc pouzivat webdav, kdyz mam sambu ? Mimo jine, myslim, ze webdav na tom bude s vykonem mnohem hure. Webdav pouzivam pro pristup k firemnimu ulozisti z mobilu - abych se nemusel pripojovat k VPN, atd. Beha mi pres https. Ale doma to nechci ani videt.

Samba je super, je skoda, ze na linuxu neni nejaky klon, treba s lepsim vykonem a kompatibilitou vuci MS klientum - NB s widlema se clovek obcas nevyhne.

[Josef Kufner]

Samba je super, je skoda, ze na linuxu neni nejaky klon [...]

Ehm. A co myslíš, že je Samba?

[petrfm]

Jezisi, tak takovou blbost jsem dlouho nevyplodil )) Samo, samba je prece linuxova portace MS sdileni souboru

[Sten]

Obdoba Samby na Linuxu je právě NFS.

WebDAV je na tom s výkonem podobně jako Samba (resp. ten protokol všechno potřebné umí, navíc umí i další věci jako kompresi). Pokud se nebojíte sniffování, tak můžete vypnout šifrování. Tipuju, že váš mobilní klient asi nebude zrovna dobře implementovaný, s davfs2 dosahuju dobrých rychlostí (cca 300 Mbps při kopírování všech fotografií).

[Sten]

Změna počtu souborů ve složce je dost divná. Možná tam je nějaký problém se zámky nebo něco ta data mění?

[petrfm]

Prave ze ne. Taky jsem na to cumel, jak puk, kdyz jsem zalohoval na externi disk a chtel jsem zkontrolovat, zda jsou ve slozce vsechny soubory. Pokazde se jejich pocet na te sambe menil.

Ta samba sdili adresar, ktery je sifrovany pomoci encfs. Mozna je zrada v tom. Mam tam i adresare, ktere sifrovane nejsou (filmy) tak to zkusim ze srandy jeste na nich, jestli to dela opravdu jen u tech fotek, ktere jsou sifrovane.

Prusvih je, ze jsem nenasel neco pro CLI, co by delalo neco jako prave tlacitko / vlastnosti

Je docela vtipne, jak slozite je v CLI zjistit pocet souboru v adresari Skriptovat kvuli takove banalite...

[Josef Kufner]

find -type f | wc -l

du -chs

[lertimir]

Myslím si, že zásadní problém je ten banan s śifrováním, na pracovní album fotek je to naprostý nesmysl. digikam sice soubory nenačítá celé, ale metainformace z nich načte, protože pokud obrázky se zařadí jiným způsobem do adresářové struktury než přes digikam, tak je správně přijme. Stejně tak, že pokud do obrázku zasáhnu, a nechám jméno, tak se objeví náhled skutečného obrázku.

Ten banám musí soubory otevřít a tím pádem dešifrovat.

Mě najede digikam do cca 15 vteřin s cca 80 000 fotkami a velikost databáze je cca 750 GB. Album je na normálním disku.

[petrfm]

Hmm, nabízí se tedy nešifrovat, nebo druhá možnost, dát si do NB druhý, 1TB disk a fotky mít na něm. Pak je jen zálohovat na ten banán.

Otázkou je, jak si se šifrováním poradí C2D? Šifrování se nechci vzdát. Nejde o to, že by tam bylo nějaké domácí porno (to se dá uložit extra), ale není mi příjemné, že v případě, že mi někdo ukradne disk, získá můj archiv deset let dozadu... Kompletně všechno.

Takže musím vymyslet nějaký workflow na zpracování, ukládání, zálohování a prezentaci fotek, co bude uspokojivě fungovat.

[petrfm]

Ja se z toho podelam. Tak tedka jsem zkousel prohlizet archiv fotek z nesifrovane casti disku - fotky pres sambu, ulozene na bananu.

Zarazi mne, ze kdyz ve gwenview oteviram fotky v okne, tak kdyz klikam mezi fotkama, skace to blik, blik, blik

Kdyz jedu ve fullscreenu, tak prechod na dalsi fotku trva i 3-5 vterin. Jakto? Co to brzdi? Kdyz otevru fullscreen, kontrolka na bananu mi blika jak strhana, takze probiha nejaky prenos - to si neco prednacita, nebo si vytvari thumbnaily? Ale proc to nedela v okne, kdyz se take nacitaji nahledy?

Ja uznavam, ze ten banan nebude zadna vykonova pecka, ale myslim si, ze problem je nekde jinde, treba na prehravani filmu, ukladani, zalohy apod. mi perfektne vyhovuje. Ale vadi mi, ze kdyz prohlizim fotky a chci preskakovat, cekam u toho jak vul.

P.

[petrfm]

OK, nainstaloval jsem si gPicView - "prohlizec obrazku" a prechod na dalsi fotku trva tak pul vteriny. Neobsahuje ale generator nahledu, ktere mi stejne generuje dolphin, takze neni potreba.

Takze za ho*no stoji gwenview, neco proste dela aktivne dopredu a tim zahlcuje banan pro normalni prohlizeni. A nebezi pomalu jen z bananu, ale i fotek tahanych z SSD ma problem s rychlosti.

[nobody]

a uz jsi zkusil pripojit to sdileni pres mount.cifs ? :)

[petrfm]

Ne, podle mne to bude uplne stejne. Vzdyt smb4k neni nic jineho, nez klikatko na mount.cifs, jine kouzlo to asi nedela Ten rozdil v rychlosti mezi SMB a mountovanym bodem byl asi jen autosugesce. V tom gwenview to chodilo stejne naprd. Pouzivam tedka jiny prohlizec fotek a ten jenom lita, i kdyz to sosam z sifrovaneho adresare

Ale delal jsem test pristupu k souborum sifrovanym a nesifrovanym. Nekolik stovek giga fotek a filmu, udelal jsem na vsechny MD5. Takze sifrovany trval 3 hodiny 40 minut, nesifrovany 40 minut Takze presouvam fotky mimo sifrovany adresar a uvidime

Myslim, ze to, ze si digiKam na ty fotky potreboval sahnout, znamenalo, ze je musel sifrator zase desifrovat, takze to trva ohromne dlouho. Uvidime, jestli se to ted zrychli. Kdyz ne, poleti banan z domu a objednam x86 desku