Hirdetés

  2. Fórumok
  3. OS, alkalmazások
  4. Linux haladóknak
  5. (kiemelt téma)
Legfrissebb anyagok
  • Téma összefoglaló
    Utoljára frissítve: 2013-09-30 15:51

    LOGOUT

    Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.

Új hozzászólás Aktív témák

  • #23561 janos666 nagyúr
    Új Válasz #23561
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    janos666

    nagyúr

    Próba-szerencse alapú hibakeresés céljából próbáltam letiltani az összes lehetséges file/folder locking mechanizmust Samba 4.3.4-ben azzal, hogy bepakoltam ezeket az smb.conf-ba (némelyiknél már ez volt az alapértelmezés a manual szerint, de kigyűjtöttem belőle mindent, ami szóba jöhet):

    kernel share modes = no
    #locking = no
    strict locking = no
    oplocks = no
    kernel oplocks = no
    fake oplocks = no
    blocking locks = no
    level2 oplocks = no
    durable handles = no
    posix locking = no

    A locking-ot azért tettem kommentbe, mert a manual alapján a no azt eredményezi, hogy bár semmit nem lock-ol a Samba szerver, de a klienseknek azt hazudja, hogy mindent lock-olt (ami látszólag ugyan az, mint a fake oplock, csak nem a lock-olás oppurtunistic változatával). De már próbáltam ezt yes-re is állítani, az eredmény akkor is hasonló.

    A testparm szerint minden OK, de aztán:

    F17a_NAS ~ # smbstatus

    Samba version 4.3.4
    PID Username Group Machine Protocol Version
    ------------------------------------------------------------------------------
    12759 root root 192.168.1.111 (ipv4:192.168.1.111:55744) Unknown (0x0311)

    Service pid machine Connected at
    -------------------------------------------------------
    data 12759 192.168.1.111 Thu Feb 11 20:00:24 2016

    Locked files:
    Pid Uid DenyMode Access R/W Oplock SharePath Name Time
    --------------------------------------------------------------------------------------------------
    12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:24 2016
    12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:49 2016
    12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance/B1 Thu Feb 11 20:01:24 2016
    12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance Thu Feb 11 20:01:24 2016
    12759 0 DENY_NONE 0x100081 RDONLY NONE /data movies Thu Feb 11 20:01:49 2016

    Vagy a fenti smbstatus ellenére lehetséges, hogy sikerült letiltanom a lock-olást, és itt csak azt látom, hogy mit kért a kliens, sem pedig azt, hogy valójában mit tett a szerver?
    Vagyis lényében a "fake" mód van érvényben és nem tudom elérni, hogy nemet merjen mondani a Samba a Windows-nak egy lock request-re? Ezt nem hajlandó elfogadni a Windows, vagy mi...? :U

    Abból a szempontból lenne érdekes a dolog, hogy vannak olyan file-ok ezen a tárhelyen, amiket gyakorlatilag 24/7 ír folyamatosan egy folyamat a Linux-os gépen, amin a Samba is fut (pontosabban nem mindig ugyan azt a file-t írja, hanem óránként újat kezd és egy cronjob törli időnként a régebbieket, de létrehozástól lezárásig apránként növekszik egy-egy file --- valós időben stream-el videótartalom megy bele), közben pedig egy Win10-es gép is használja ezt a tárhelyet és néha egész konkrétan ezeket, az épp gyarapodó file-okat is megnyitom vele.

    Az a fura, hogy azt tapasztaltam hosszabb időn át, hogy akkor kezd problémázni a kérdéses file-okat kezelő program, amikor be van kapcsolva a Windows-os gép. Például este 17-től másnap 10-ig folyamatosan sorakoznak fel azonos méretű, pontosan 1 óra anyagot tartalmazó file-ok, de 10-től, amikor aznap felébredtem és rutinból bekapcsoltam a gépet, onnantól 20-30 percenként megszakad és újraindul, rövidebbek a file-ok és így ki is maradozik pár perc (de ilyenkor általában még semmit nem csinálok vele, a kijelzőt még be sem kapcsolom határozatlan ideig, nem hogy a hálózati meghajtót tallózgatnám, főleg nem ezeket a file-okat piszkálom...). Viszont ha szándékosan megnyitom a félkész file-okat és direkt nyitva hagyom a Windows-on a mappatallózót, hogy frissítgesse a fileméretet, attól még nem lesz feltétlenül zavaros a működés, van hogy ilyenkor is egész nap zavartalanul működik, hiába babrálom kézzel is szándékosan.

    Szóval nem egyértelmű az összefüggés, de mégis gyanús, hogy talán a Windows lock-ol egyet, mikor felcsatolja a hálózati meghajtót és emiatt a Linux-os program néha (még ha nem is kiszámítható módon) félbehagyja a fileműveleteit. Szóval csak teória, de szerettem volna tesztelni azzal, hogy mindenféle lock-olást letiltok. Illetve ha kiderülne, hogy tényleg van köze a lock-okhoz, akkor is próbálnék később olyan beállítást keresni, ami jól működik, de nem tiltja teljesen a lock-ot...

Új hozzászólás Aktív témák