sshfs + readonly + nagy latency

Naplózó filerendszerek (journaling)

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.

  • 1348 megtekintés

( bAndie9100 | 2018. 08. 10., p – 10:02 )

sub, érdekel, mi is van a háttérben.

én azzal kezdenék kísérletezni, h az sshfs elé húzok egy másik fs layert, ami lekezeli az olvasást sshfs-ről és felfelé viszont a helyben cache-elt másolatot szolgáltatja (nem az OS szintű fs cache-ből, amiről te írsz – ahhoz nem tudom hogy lehetne hozzáférni).
- ehhez ezt a toolt ismerem: https://github.com/vi/execfuse
- csinálnék egy 'open' scriptet, ami elkezdi átmásolni a remote fájlt local-ba
- ha elég (vagy az egész) átjött belőle, visszaadni a shadow fájlt path-ját
- az app onnastól localból fogja olvasni.
- ne tévesszen meg a "slow by design" kijelentés a doksiban, az azokra az fs hívásokra vonatkozik, amikre kezelő szkriptet állítottál be. ebben az esetben csak a megnyitasra triggerelőne az 'open' script, további olvasások noha átfolynak az execfuse-on, de minimális overheaddel.

másik ötlet a gyorsításra, ha az ssh connection mondjuk már egy titkosított csatornán megy (pl. vpn), akkor bevállalhatod, hogy 

-o directport

-tal közvetlen kapcsolódsz egy remote-ben futó sftp daemonra, kihagyva az ssh overhead-jét. 

strace

jó szolgálatot tehet h kiderísd, ha valamilyen felesleges syscall miatt lassul be az application.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

strace jó szolgálatot tehet h kiderísd, ha valamilyen felesleges syscall miatt lassul be az application.
á, koszi, ezt mindenkepp megnezem, ez jo otlet!

Nagyon hekkelni nem akarok, marmint persze tul az esszeruseg hatarain belul ;) Egy plusz proxy-cache-stb filerendszer pont hatareset. Ezzel kapcsolatosan pl lehet hogy azt is megnezem hogy "loopback" modon felmountolom (akar ugyanarra a gepre) az sshfs-t szinten sshfs-sel. Es akkor a masodik szinten levo sshfs mar egy readonly filerendszert lat, es akkor szepen feltetelezi hogy "ami ott van az allando" es akkor nem lesz ilyen. Na, ez is egy kis hekkeles nyilvan, de nem annyria bonyolult hogy egy probat ne erjen meg... hatha :) koszi az otlet-magot!

Mielott nekiesnel egy samba-nak vagy barminel az strace-elesenel a -ff opcioval, hogy lasd a forkolt processeket is, en javaslom inkabb az "strace -c"-t futtatni a pidre, igy latod, ha valamilyen sys hivas sok-sok errort produkal.

De meg ezelott megneznek egy top-ot, vagy dstat-ot, hogy usr-ben, sys-ben, io-ban porog e. Mert ha io, akkor felesleges az strace.

Igen, kozben kiderult az hogy:
- ez az alkalmazas egy ~200k-s file megnyitasaval is ugyanugy perceket vacakol,
- es ezzel egybevagoan az `strace` alapjan ugy nez ki hogy valami tmpfile-t(?) probalna letrehozni az aktualis konyvtarban(!) es ott azon egy csomo lstat() meg access() hivast csinal (de hogy miert...?)
- es ez a loopback-trukk sajnos nem segit.
- egy jol megirt program eseten (pl egy kepnezegetovel megnezek egy ~1 megas png-t vagy jpeg-et) persze minden jol megy (azaz 1-2 masodpercen belul szepen megnyitja)

Szoval nem sokkal vagyok elorebb, vsz ez a cel-program az ami elegge vacak...:/ Az mas kerdes hogy hasznalnom kene :)

A "-c" opcio azert jo mert latod, hogy a sok hivasbol mennyi a hiba. Utana meg le tudod szurni az strace-t "-c" nelkul csak arra a hivasra, hogy last miert hasal el. Legtobbszor rogton kibukik, hogy mi a baj, hiszen a hivas kiirja a hibat. Utana mar csak egy man-t kell megnyitni, hogy mi is okozhatja ezt (ha sian nem jon ra az ember azonnal).

Lehet hogy a celprogram vacak, de az is lehet, hogy csak valamit elakell rakni, ami igy rogton latszik. Szoval en azert megprobalnam a fentieket.