Klien Windows tidak akan me-refresh file samba Linux secara lokal jika membaca file pada interval <= 10 detik


8

Jika saya memiliki klien windows membaca file pada Linux smb berbagi pada interval <= 10 detik, klien windows akan menunjukkan informasi yang salah (di-cache?) File tersebut.

Saya telah mereproduksi ini di banyak sistem.

Contoh langkah untuk mereproduksi:

1) mengatur share linux samba - untuk contoh ini, menggunakan Debian dan menginstal samba. contoh:

sudo mkdir /test
sudo chmod 777 /test

tambahan smb.conf:

[test]    
read only = no    
locking = no    
path = /test/    
guest ok = yes

2) Petakan direktori ini sebagai drive di klien windows (tes ini akan menggunakan L :)

3) buat file dengan beberapa teks di server samba

nano /test/test.txt
ORIGINAL

4) buat file batch sederhana di mesin windows untuk melihat file setiap 5 detik:

copy con test.bat
@echo off
cls
:1
type L:\test.txt
timeout 5
goto 1

5) jalankan file batch, itu harus menunjukkan ASLI setiap 5 detik.

6) di server linux, ubah konten file

nano /test/test.txt
CHANGED

7) melihat file batch berjalan di windows, masih akan mengatakan "ASLI" setiap lima detik, dan tidak "DIUBAH" seperti file aslinya.

8) menghentikan file batch dan tunggu ~ 15 detik, ATAU ubah batas waktu menjadi sesuatu> 10 detik, dan itu akan diperbarui dengan benar.

Semoga saya sudah menjelaskan dan menjabarkan cara mengujinya dengan cukup.

Adakah yang bisa mereproduksi perilaku ini dan / atau menyarankan cara memperbaikinya?

.

.

.

CATATAN:

Klien Linux> Linux SMB Host menunjukkan konten file yang tepat.

Klien Windows> Windows SMB Host menunjukkan konten file yang tepat.

Khususnya Klien Windows> Linux SMB Host yang tidak menampilkan konten file yang tepat pada interval penyegaran <= 10 detik.

Semua rasa Windows yang telah saya uji dengan (Win7, Win10, Server2016) menunjukkan perilaku yang sama.

Saya juga telah menguji protokol yang berbeda pada share samba saya 'NT1, SMB2, SMB3', dan mereka tidak mengubah perilaku.

CATATAN: Saya yakin ini kemungkinan besar merupakan masalah Windows, tetapi saya belum menerima tanggapan tentang teknologi atau superuser dalam seminggu. Ini seharusnya cukup mudah untuk diuji, adakah yang bisa mengkonfirmasi perilaku atau keadaan ini sebaliknya?


Hai! Mungkin klien windows caching file. Sudahkah Anda mencoba menyiapkan server file windows untuk melihat apakah berperilaku sama. Saya tahu Anda perlu windows, tetapi saya hanya bercanda. Solusi terbaik yang pernah ada: uninstall windows.
ncomputers

Saya telah menguji ini pada Server 2016 dengan peran File Server diinstal. Perilaku yang sama terjadi.
R. StackUser

Oke, mungkin langkah selanjutnya adalah menguji penonaktifan caching di sisi server dan di sisi klien ...
ncomputers

Jawaban:


8

Nilai default untuk pengaturan yang relevan adalah:

  • oplocks = yes
  • kernel oplocks = no

(Lihat dokumentasi Samba smb.conf )


Anda dapat menonaktifkan kunci pembuka, sesuai jawaban lain .

Atau, jika Anda menjalankan Linux O / S dengan kernel modern (2.4 atau lebih baru), Anda dapat meninggalkan oplocks = yesdan sebagai gantinya menambahkan baris smb.confuntuk mengaktifkan kunci pembuka kernel. Sesuai bagian kernel oplocks (S) dalam dokumentasi:

Kernel oplocks support memungkinkan Samba oplocks untuk diputus setiap kali proses UNIX lokal atau operasi NFS mengakses file yang smbd (8) telah terkunci. Ini memungkinkan konsistensi data lengkap antara SMB / CIFS, NFS dan akses file lokal

Ketika oplocksdan kernel oplockskeduanya diaktifkan, Anda harus mendapatkan kinerja yang baik (dari caching) dan pembatalan cache ketika file diperbarui.

Untuk mengaktifkan kunci pembuka kernel, tambahkan baris ini ke file konfigurasi Samba Anda:

kernel oplocks = yes

1
Di bagian pertama dari jawaban Anda, Anda menekankan bahwa oplocksharus dinonaktifkan. Pada bagian kedua kutipan mengatakan memungkinkan mereka bersama kernel oplocks. Apakah benar untuk menyarankan contoh terakhir Anda seharusnya tidak hanya kernel oplocks = yestetapi juga oplocks = yes?
roaima

@roaima, konfigurasi default adalah: oplocks = yesdan kernel oplocks = no. Jadi tidak perlu menambahkan oplocks = yes; kita hanya perlu menentukan kernel oplocksnilainya.
Serge

2
Saya hanya berpikir bahwa mungkin karena bagian pertama dari pertanyaan Anda menyarankan untuk menonaktifkannya, ada baiknya menghubungkannya dengan proposal akhir Anda.
roaima

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.