távoli fájl másolás stat() nélkül

Segédprogramok

Sziasztok!

A következő problémám van: van egy fájlrendszer ami rengeteg fájlt és könyvtárat tartalmaz, ezt szinkronizálni kellene a helyi rendszerrel az SSH porton. A probléma az, hogy olyan összetett, hogy ha a stat()-ot hívok akkor lényegében elfogadhatatlan hosszúra nyúlik az átvitel. A probléma gyökere a fájlrendszer rossz megválasztása, de belátható időn belül ez nem lesz megváltoztatva, szóval kellene valami workaround.

Ugye rsync játszik mivel ha jól tudom az mindig meghívja a stat()-ot.

Arra gondoltam, hogy készítek két egyszerű fájllistat a két oldalon és egyszerűen scp-val átmásolom az új fájlokat (nincs fájl frissítés a távoli oldalon csak új fájlok generálása ). De ahogy nézem a libssh és a libssh2 szintén használja a stat()-ot

Van valakinek egyéb ötlete?

  • 1668 megtekintés

( wachag | 2015. 10. 29., cs – 10:15 )

Gány, de működhet: LD_PRELOAD-olt shared lib-bel kiütöd a stat()-ot.

??? Mármint a read(2) és write(2)-ről beszélsz? Mert nem nagyon látom, hogy egy minimal-cat nem lenne megoldható így:

#include < fcntl.h >
main() {
int in, count;
char buf[10240]
in = open("masolando.zip", O_RDONLY );
while ( ( count = read( in, buf, sizeof(buf) ) ) > 0 ) {
write( 1, buf, count );
}
close( in );
}

Úgy nagyvonalakban (fejből írtam, nincs hibakezelés, stb). Ezt aztán úgy vezeted bele egy netcat-ba, ahogy gondolod. Az ssh-val pedig VPN-ezel :-)

( wauf | 2015. 10. 29., cs – 10:44 )

Az a gond, hogy a legtobb tool a stat()-al kerdezi le a file meretet (mivel ugye ez a standard modja ennek).

Talan ha letrehozol egy 

tmpfs

-t, es oda 

cp

-vel atmasolod a file-t elotte, majd onnan 

scp

mukodhet.
Vagy irni sajat scriptet ami nem hivja a stat()-ot :)

En is ugy nezem, hogy a stat()-ot hasznalja a fajlmeret lekerdezesere es lefoglalasara, pl:

open("/root/rpmbuild/SPECS/xindy.spec", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1697, ...}) = 0
fcntl64(3, F_GETFL) = 0x8800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE)
fcntl64(3, F_SETFL, O_RDONLY|O_LARGEFILE) = 0
write(6, "C0644 1697 xindy.spec\n", 22) = 22
read(7, "\0", 1) = 1
fstat64(3, {st_mode=S_IFREG|0644, st_size=1697, ...}) = 0
fcntl64(6, F_GETFL) = 0x1 (flags O_WRONLY)
fcntl64(6, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
read(3, "Name: xindy\nVersion: "..., 1697) = 1697
write(6, "Name: xindy\nVersion: "..., 1697) = 1697

A gond a tmpfs-el, hogy a masik oldal egy kulso cege, szoval nem nagyon akarok meg tudok semmit se csinalni rajt kiveve olvasni.

( bAndie9100 | 2015. 10. 29., cs – 15:51 )

uhh, úgy látom még egy egyszerű `cat` is stat-ol. pontosasbban fstat - nem tudom ez változtat-e az esetedben.
1. vagy felülírod a stat, fstat, stat32, fstat64, stb. függvényeket
2. vagy magad implementálod libc szinten a fájlok begyűjtését.
ehhez egy egyszerű pszeudókód: 


fajlok kiszolgálása stdout-ra:

for filename in readdir:
  print "F", filename, LF
  fh = open filename
  while buf = read fh:
    print "B", buf, LF
  close fh

adatok fájllá alakítása stdin-ről:

while line = read:
  if line[0] == "F":
    close fh
    fh = open line[1:-1]
  if line[0] == "B":
    write fh, line[1:-1]

egy olyan soralapú adatfolyamot generál amiben a sorok elei prefix mondja meg h File név, vagy a lagutóbbi File-hoz tartozó Binary tartalom következik.
persze lehet tarkítani könyvtárak, path-ok átvitelével (fájl módhoz, timestamp-hoz ugye már statolni kéne).
és persze a bináris tartalomban található sorvégeket valahogy kieszképelni :)

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

( mrceeka v | 2015. 10. 29., cs – 16:20 )

Van egy érzésem, hogy ez a probléma az adott kötet tekintetében nem csak a távoli file-szinkronizációt gátolja. Jól érzem?
A backup hogy megy le például?

Üdv,
Marci